Designing an AI Program That Ships

The usual first move in a company AI program is to write the strategy. It's also the move most likely to waste the first year.

You've probably seen how it goes. A team spends a quarter on a strategy document, procurement buys chat-assistant licenses for everyone, and three or four departments run pilots. A year later the document is out of date, most people use the assistant to write emails, and the pilots produced good demos and no change in how orders, invoices or customer cases are handled. Everyone worked hard. The company runs exactly as before.

The alternative is simple to state: run the program as a sequence of business processes. Change each one from start to finish, measure it against how it ran before, and make sure it leaves behind pieces the next process can reuse. Done that way, the first measured result arrives within a quarter, and each one after arrives faster than the last. The strategy still exists. It fits on two pages.

Why the usual three moves fail

The strategy guesses facts nobody has yet. A good AI plan depends on things you only learn by doing the work: which processes can be checked cheaply, where data access will stall in a security review, which exceptions eat a team's week, how often the model misreads a field on your own documents. A strategy written first ranks forty use cases by invented returns. The paralysis has a structural cause: the open questions are empirical, and the process only allows thinking.

Licenses speed up people, and the company doesn't move. Someone who drafts an email in two minutes instead of ten has saved eight minutes. The order still waits in the same queue, and the invoice still needs the same approval, because a process moves at the pace of its slowest step (Where the Saved Time Goes). An MIT study of enterprise AI in 2025 found workers at over 90 percent of companies using personal AI tools, which mostly improved individual productivity, not the profit-and-loss account.

Pilots prove the technology works, which it usually does. What a pilot rarely does is change the process around it. It runs on a clean extract of data, with an enthusiastic volunteer, and with nobody responsible for running it afterwards. When it ends, the hard parts are still waiting: integration, permissions, exceptions, training, ownership.

Surveys point the same way. In McKinsey's 2025 survey, the roughly 6 percent of companies getting real financial value from AI were nearly three times as likely as the rest to have fundamentally redesigned how individual workflows run. A survey can't prove the redesign caused the value, since well-run companies may simply do both, but the pattern is consistent.

A strategy can't contain facts nobody has measured yet. Licenses speed up people, and pilots speed up steps. Neither changes a process.

The unit: one process, end to end

Each process in the program must meet four conditions before money goes in.

It runs end to end, from the event that starts the work to the result someone outside the team would notice. For order intake at a distributor, the trigger is a customer's email with a purchase order, and the result is a confirmed order that ships on the promised day. Typing the order in is one step; measure only that and you'll report a big improvement the customer never sees.

It has an owner, whose own targets include the outcome and who can change how the work runs: usually a team lead, rarely the IT sponsor. Without one, the team drifts back to the old way in the first busy week.

It has a baseline: lead time, error rate, volume and cost, measured for two to four weeks before anything changes. It's the cheapest insurance a program can buy. Without it, every later result becomes an argument, and the loudest anecdote wins.

Its outcome is cheap to check. Someone can tell quickly whether a single case was done right. An order line matches the purchase order or it doesn't. Whether a sales email "sounds better" is something two reasonable people will dispute forever.

Why cheap checking comes first

In the first weeks of any AI process change, the system makes mistakes and people find them. Each mistake found becomes a case in an evaluation set: a collection of real past cases with known correct answers, which you run the system against every time anything changes, whether the instructions, the model or the data source. It tells you whether a change helped, and when the system is ready for more responsibility.

If a mistake takes thirty seconds to spot, a clerk can review hundreds of cases and the evaluation set grows fast. If it takes a lawyer an hour, the same learning costs a hundred times more.

Cheap checking also makes a safe rollout possible. The system starts in shadow mode: it produces its answer alongside the people doing the work, nobody uses that answer, and you only compare. Then assisted mode: its draft appears pre-filled, a person confirms or corrects it, and every correction joins the evaluation set. Only then does it act alone, on the cases where it has proven itself, with a sample audited and a switch that sends everything back to manual handling in minutes. Without a cheap way to tell right from wrong, you never earn the next stage.

The other condition for a first process is data access, and it rarely depends on the model. Reading a mailbox or the ERP (the core system that holds orders, stock and accounts), and later writing to it, each need a security review and an owner's consent (Data Access Is the Real Integration Project). Start where access can be read-only and granted within weeks. Ask for write access after the system has proven itself reading. Those two conditions, cheap checking and quick access, decide whether the first result arrives in two months or in nine.

How the program compounds

This is the part that turns a list of projects into a program. A first process leaves much more behind than its result: a working connector to the ERP, a security approval for a pattern of access, a document reader tested on the company's own paperwork, a method for evaluation sets, a review screen, a list of exceptions, and a few people who have been through the change once. Each took weeks.

So split the effort of any process into two kinds of work. Specific work belongs to that process alone: its evaluation set, its exceptions, its owner's decisions, its training. Shared work can be reused: connectors, access approvals, document handling, the review screen, monitoring. Time to a first result is roughly the specific work plus whatever shared work doesn't exist yet.

Assume four weeks of specific work for every process, and six weeks of shared work that the first one pays in full. The first takes about ten weeks. The second reuses half the shared work and takes about seven. The third takes about five. The fourth takes about four, almost nothing but its own specific work.

Scroll sideways to see the whole figure

The numbers are assumptions. The shape holds whenever shared work is large compared with specific work, which is typical: the first integration with a core system usually takes longer than any single use case. It also gives you the rule for choosing what comes second: pick the next process for what it can reuse, next to what it's worth. If each process sits on a different system with different documents, the shared work never shrinks.

This is also the answer to the tool that dies in one department, built around its quirks and impossible to extend. The catch is that reuse only happens if someone packages each asset for the next team; otherwise the second team quietly rebuilds what the first one built (When Work Starts to Compound).

Funding in gates

Annual budgets ask the company to predict a year ahead which use cases will work and what they'll cost, which nobody can do, and money once allocated tends to get spent. Stage gates fit better. The company sets an envelope, the most it will spend over, say, six months, and releases it in tranches. Each tranche buys specific evidence, and a gate at its end decides on measured results whether the next one is released, narrowed or stopped. The criteria are written before the tranche starts. Venture investors work this way for the same reason: early money buys information.

The number that makes gates work is cost per finished task: an order confirmed correctly, an invoice approved. It includes model and tool fees, the minutes people spend reviewing, the cases that fall back to manual handling and the rework when something slips through. Token prices are a small and misleading part of it.

Six months at a distributor

The company and its numbers are invented, chosen to be plausible. A 400-person industrial supplies distributor receives about 1,800 orders a week. Roughly 1,080 arrive as emails with PDF purchase orders that fourteen clerks type into the ERP. The board has asked for an AI strategy.

Month 0. Leadership writes two pages instead of a deck: the outcomes that matter (order lead time, errors reaching customers, cost to serve), the guardrails (nothing reaches a customer or the books without human approval until a gate changes that) and a six-month envelope of €205,000. Order intake becomes process one: high volume, cheap to check, a clear owner in the order-desk lead, and data that can be read without changing anything. The first gate releases €40,000.

Month 1. The baseline: about six minutes of typing per order, 2.5 percent of orders with a line error that costs forty minutes to fix later, and a median of four and a half hours from email to confirmed order. Two engineers sit at the order desk, build an evaluation set of 300 past orders and run the system in shadow mode.

Months 2 and 3. Drafts match the correct entries on at least 97 percent of fields, the next tranche is released, and clerks move to assisted mode. By month three the median time from email to confirmed order is about an hour and a half, mostly because orders no longer wait in a typing queue. Line errors fall to 1.2 percent. Cost per finished order falls from about €3.85 to about €1.74. Over 80 percent of clerks still use the assisted path when they could go back to typing, the signal that matters most. At the same gate, a proposal to generate personalized sales emails is deferred: it has no owner, and nobody can say how a good one would be checked.

Months 4 to 6. Repeat-customer orders that pass every check post automatically, with a weekly 5 percent sample audited. Supplier invoice matching, chosen second because it reuses the connector, the document reading and the review screen, cuts approval from about nine days to about four. Customer status queries follow. At month six, three processes run with named owners, and the next three are chosen partly by what they reuse.

Scroll sideways to see the whole figure

The first process doesn't pay for the program. Order intake saves about €110,000 a year in clerk time, against roughly €205,000 spent in six months. The case rests on lead time, on fewer errors reaching customers, and on each later process arriving faster and cheaper. An executive who judges the first process alone on headcount will cancel a program that's working.

Freed time needs a decision. The order desk freed about seventy hours a week, close to two full-time people. Absorb growth without hiring, call customers about stockouts, or let turnover shrink the team: left undecided, the time dissolves into the day, and the clerks reasonably wonder what the program is for.

Who does it, and what they build

The team is small: two or three engineers, someone part-time from IT for integration and security, a program lead who can unblock decisions, and for each process its owner and one or two people who do the work. The engineers sit with the work. Three days at the order desk teach what no requirements document contains, such as the large customer who sends photographed paper orders. The role has a name, forward-deployed engineer (What a Deployment Engineer Should Own, and Leave Behind).

The people who do the work today are the first critics of the solution, and the cheapest quality control you have. A clerk who has typed purchase orders for six years spots a wrong unit of measure in a second. When people feel the system makes them more useful, they improve it. When it's built around them, they find reasons it can't be trusted, and they're often right.

As for what to build: first ask whether the model provider or an existing vendor is likely to ship it within twelve months. Many companies built internal tools in 2023 to chat with their documents, and Microsoft 365 Copilot reached enterprises that November. Build what only your company can build: approved access to its own systems, evaluation sets from its own cases, a written record of its exceptions, review steps that fit its risk. Code that patches what today's model can't do is scaffolding, and the next model makes it dead weight. Permissions, checks and records are walls, and they hold whatever the model. A program that puts its effort into walls gets stronger with every release.

Build what only your company can build. The vendor will ship the rest, often sooner than the roadmap expects.

What to do

Write the two-page strategy, and stop there. Three or four outcomes in measurable terms, the guardrails, the budget envelope with its gate rules, and who owns what, including who can stop the program. That takes two or three weeks. Leave out the ranked use cases, the target architecture and the vendor selection: those are outputs of the program.

Pick the first process for cheap checking and quick read-only access, measure its baseline, and fund it in tranches judged on cost per finished task, lead time, quality, and how many people still use the new path when they could go back.

Ignore the numbers that rise whatever happens: pilots launched, licenses bought, people trained, hours saved according to a survey. They describe activity (Measuring AI Impact Without Fooling Yourself).

Choose the second process for what it reuses.

Work without direction does scatter. But a company that has changed six processes in a year has six owners who know how to run AI-assisted work, a library of approved patterns, evaluation sets from its own cases and a measured record of what works. It is in a far better position to decide on a big transformation than one that spent the year describing it.

Check yourself

Why does giving everyone a chat assistant rarely change how the company runs?

It speeds up people, but a process moves at the pace of its slowest step. The order still waits in the same queue and the invoice still needs the same approval.

Why choose the first process for cheap checking?

Each mistake found becomes a case in the evaluation set, and the system earns more responsibility only by proving itself. If a mistake takes a lawyer an hour to spot, the same learning costs far more.

What should decide which process comes second?

What it can reuse, next to what it is worth. Connectors, access approvals and the review screen cut the shared work, so later processes arrive faster.