Why AI pilots stall: map the whole workflow, not the first task

In an illustrative accounts-receivable diagram from a working paper, the “before” picture is not a dramatic failure of intelligence. It is four ordinary manual bridges between systems. The sequence moves from Excel to an AR clerk pulling data, to QuickBooks, to an AR clerk entering data, to a bank portal, to an AR clerk matching payments, to Gmail, and finally to an AR clerk sending an email.

The “after” picture reorganizes the chain. AI pulls and reconciles data; QuickBooks is updated; AI matches payments and sends emails. An AR specialist resolves flagged exceptions. This is a workshop case used to explain a mechanism, not a proven customer outcome. But it makes a production problem unusually visible: the value is not in making one clerk type faster. It is in removing a series of dependent waits between systems while preserving a place for someone to handle the cases that do not fit.

That distinction explains a familiar disappointment. A team deploys an AI feature that makes a task startlingly fast, then finds that throughput, customer response, or delivery speed barely changes. The pilot may work. The workflow around it may still be arranged for the old pace.

The useful question is therefore not only, “Where can a model help?” It is: what becomes the constraint immediately after it helps?

A fast step can leave a slow chain

Every operational process has a trigger, a set of decisions and handoffs, an output, and usually a feedback loop. The constraint can sit almost anywhere: in collecting the input, checking it, moving it between systems, obtaining approval, waiting for a customer response, or correcting an error downstream.

Consider a product team that can generate a requirements document or a prototype much faster than before. That can be genuinely useful. But if the team still lacks a reliable way to learn what customers need, test an idea, interpret feedback, and revise its direction, it may now build the wrong thing faster. The bottleneck has shifted rather than disappeared.

This is why isolated pilots often produce a strange combination of local excitement and organizational indifference. The person running the task sees a gain. The wider system sees the same queue, the same rework, or a new queue one step later.

The accounts-receivable diagram offers a practical way to see the issue. Imagine automating only the first transfer from Excel. The next manual entry into the accounting system becomes the limiting handoff. Automate that, and payment matching may become the constraint. Automate matching, and follow-up communications or exception investigation may dominate. The full illustrated sequence connects the bridges: Excel to AI reconciliation, an updated accounting record, AI payment matching around the bank portal, AI email sending, and specialist review for what is flagged.

That does not mean every process should be automated end to end. A connected workflow may carry too much risk, variability, or regulatory exposure for that. It does mean a team should map the whole sequence before celebrating a local speedup—and decide deliberately where automation should stop.

The narrower question of whether a particular component calls for model judgment or deterministic execution remains important. It belongs in the existing judgment-versus-deterministic-steps article. Before making that component-level choice, however, map the connected bottlenecks. Otherwise, a carefully engineered component can be optimized inside a workflow that cannot yet benefit from it.

Map handoffs, not just tasks

A workflow map should be more than a row of boxes labeled “research,” “draft,” and “approve.” Those labels hide the work that causes delays: copying fields, checking formats, interpreting incomplete requests, chasing a reply, and deciding when an unusual case deserves attention.

Start with an actual work item and trace its path from trigger to completed outcome. At each stage, record the system involved, the person or service that acts, the input it needs, the decision it makes, and what happens if the input is missing or uncertain. Then add the return paths: corrections, customer feedback, failures, and escalations.

The aim is not a beautiful process diagram. It is a falsifiable picture of where work waits and why. A prototype can reveal that a model performs a task adequately; a workflow map reveals what must change for that adequacy to matter.

Here is a compact checklist for doing that work:

• Trace one real item end to end. Mark the trigger, every system and human handoff, each decision, the output, and the feedback loop.
• Name the likely next constraint. If the first task became instantaneous, what would wait next: discovery, validation, approval, matching, quality control, or customer response?
• Test the adjacent steps. Ask which upstream inputs and downstream actions must change with the first task for cycle time, rework, or throughput to improve.
• Draw the exception boundary. Define what counts as uncertain, how it is flagged, who receives it, what context they need, and how corrections feed back into the process.
• Measure the workflow, not the demo. Track outcomes such as elapsed time, backlog, rework, exception rate, completed work, and the result for the customer or business.
• Map again after deployment. New capabilities and changed routines create new constraints; the map is a recurring operating tool, not a one-time discovery exercise.

A key design choice follows from the fourth item. Exception handling is not an embarrassing leftover after “real” automation. It is often the control surface that permits broader automation safely. In the diagram, the AR specialist no longer serves as routine glue between software systems. The specialist investigates the cases the automated flow has explicitly identified as abnormal.

What full-sequence redesign can look like

The working paper’s appendix includes anonymized, self-reported treatment-venture illustrations. They are useful as maps of possible sequences, not as audited case studies or proof that a workflow caused the outcomes reported.

One Field Services illustration described 19 AI use cases distributed across an operations chain. An intent classifier took the initial routing role; an address and VAT normalizer handled a bookkeeping-related step; a slot proposer supported scheduling; a multilingual adapter handled communications; and a payment-reminder engine supported collections. Crucially, the reported design included a confidence watchdog: uncertain cases were routed to humans, and operator corrections informed later handling.

The interesting feature is not the count of use cases. It is that the system was described as a chain with a human routing mechanism, rather than a pile of disconnected assistants. A customer request that begins ambiguously should not be treated as a clean input simply because a model can generate an answer. The workflow needs a defined way to recognize uncertainty, preserve context, and send the case to a person able to resolve it.

A separate anonymized Tender Matching illustration shows the same principle on a different path: classify tenders, match them to small and medium-sized businesses, email recommendations automatically, assist proposal drafting with retrieval-augmented generation, check compliance and flag missing ISO documents, score win probability, then support bid pricing predictions. Retrieval-augmented generation, or RAG, here means grounding a model’s drafting in retrieved documents rather than relying only on its general training.

The venture reported going from $0 to $40,000 in first revenue and from zero to four paying customers during the program. Those figures were not independently audited, and the workflow cannot be said to have caused them. Still, the sequence supplies a better design question than “Should we add RAG?” A team can ask: if proposal drafting gets faster, are tenders classified and matched well enough upstream? Is compliance checked before the proposal reaches a customer? Does pricing incorporate the information created earlier in the flow? Where must a person intervene when a document is missing or a recommendation is uncertain?

A connected design has trade-offs. Automating handoffs can make errors travel faster, especially when systems update records or contact customers. It also creates operational obligations: confidence thresholds, auditability, and an exception queue that does not bury the humans handling unusual cases. The correct boundary depends on the reliability required and the cost of a mistake. “Automate the sequence where reliability permits” is more useful than a slogan about agents replacing workflows.

Evidence that the obstacle may be discovery

Why emphasize mapping rather than merely providing more tools? A preregistered randomized study in an INSEAD working paper offers unusually relevant, though bounded, evidence.

The study involved 515 early-stage startups in a three-month virtual accelerator. Both treatment and control groups had access to the same tools, credits, and technical training. The treatment group additionally received examples and frameworks about reorganizing production around AI. The contrast was not between firms with AI access and firms without it; it was between shared access plus technical instruction, and that same foundation plus exposure to production-reorganization examples.

Over the study period, treated firms reported 2.686 additional AI use cases compared with a control-group mean of 6.054. They also reported 2.201 more internal tasks, compared with a control mean of 9.778. The paper interprets this pattern as consistent with a discovery problem: firms may need help finding where AI changes adjacent activities and how to reorganize around those changes, not simply access to models or credits.

That is not a universal claim about AI adoption. The setting matters. It was a three-month accelerator, with roughly a 10-week window after treatment began; the participants were early-stage AI startups rather than mature organizations; and the treatment was a bundle of cases, frameworks, workshops, and peer discussion rather than a single isolated lesson. Many measures were founder-reported, even though reported use cases and tasks received validation and deduplication. The research remains a working paper, not settled peer-reviewed evidence.

Those limits are reasons to avoid treating “full automation” as an architecture mandate. They are not reasons to ignore the study’s practical provocation. When groups already share tools and technical training, examples of how to redraw production may change what teams notice, attempt, and connect.

The pilot is a probe, not a destination

Return to the manual bridges between Excel, accounting records, a bank portal, and email. It is tempting to look at that diagram and see a simple substitution story: replace manual work with AI. The more useful reading is architectural. The old process was a chain of interfaces, waits, checks, and decisions. Its redesign joined the routine interfaces and made exception review explicit.

That is a different way to regard a pilot. A pilot is not merely a test of whether a model can perform a task. It is a probe for the surrounding system: what inputs become valuable, which handoff becomes newly painful, what feedback arrives too late, and which exceptions require someone who understands the stakes.

Once you see the workflow that way, the first successful automation stops looking like the finish line. It becomes a flashlight, illuminating the next bottleneck—and the connected sequence that may finally be worth redesigning.