The most common failure in enterprise AI is not a failed pilot. It is a successful training programme followed by nothing.
The pattern is consistent enough to predict. A company runs Claude training for two or three teams. Feedback scores are high. People leave with prompts they wrote themselves, genuinely impressed. Six weeks later, usage has settled into a handful of enthusiasts drafting emails faster, and the workflows that actually cost the business money run exactly as they did before.
Leadership reads this as a tooling problem and starts evaluating a different model. It is not a tooling problem. Training changes what individuals can do; it does not change what the organization does. Those are separate problems, and only one of them was addressed.
Three things that cause the stall
1. The tool has an owner. The workflow does not.
After training, someone owns "Claude" — usually whoever championed it. Nobody owns the claims triage process, or the vendor onboarding sequence, or the weekly reconciliation. Those belong to teams who were not in the room and who did not ask for a new tool.
So the enthusiast can demonstrate a better way to do a step, but cannot change the step. The improvement stays personal. It never becomes how the work is done, because no one with authority over the work was part of deciding it should change.
2. The wins are real but invisible
Someone saves forty minutes on a report. That time does not appear in any system. It is absorbed into the day, and by the following month nobody can prove it happened. When the CFO asks what the training returned, the honest answer is "people say it helps", which is not an answer that funds a second phase.
Invisible wins also cannot be prioritized against each other. If you cannot say which workflow returned the most, you cannot decide what to automate next, so the next decision gets made on enthusiasm instead of evidence.
3. The standard lives in people’s heads
Everyone leaves training with their own prompts. Nobody shares them. There is no agreed position on what may be sent to a model, what has to be checked before it goes to a customer, or who reviews output that touches money. Each person invents their own answer, which means the organization has as many AI policies as it has users.
This is usually the point at which a cautious manager quietly discourages use, because the downside of one bad output landing in front of a client outweighs a diffuse productivity gain nobody has measured.
The tell
If you cannot name the two workflows Claude changed and say what each was worth, adoption has stalled — regardless of how many people are using it.
What actually restarts it
The thing that moves an organization past this point is not more training. It is observation followed by a ranked list.
Someone has to sit with the teams and watch how the work actually runs — not how the process document says it runs. That distinction matters more than anything else in this article. Documented processes describe the intended path; the real one is full of the workarounds people built to survive it, and the workarounds are usually where the time goes.
Out of that observation comes a small, ordered set of candidates, each with a number against it: how often the workflow runs, how long it takes, what a mistake costs, and whether a human can verify the output quickly. Two or three of those will be obviously worth doing first. The rest can wait, and saying so out loud is part of the value.
Why the sequence has to be this way round
It is fair to ask why discovery does not come first, before any training at all. The answer is that discovery is much less accurate with a team that has never used the tool.
Ask people who have not used Claude which of their tasks it could take on, and they will describe what they imagine AI does — usually either far too little or something that does not exist. Ask the same people after a few weeks of real use and the answers become concrete and unglamorous: the handover note nobody writes properly, the four systems someone reconciles by eye every Friday.
So training first is not a warm-up. It is what makes the discovery worth doing.
What to do if you are already stalled
Start by writing down what you actually know. Which teams were trained, what they use it for now, and what evidence exists that anything changed. That document is usually short, and its shortness is the finding.
Then pick one workflow — not a portfolio, one — that runs often enough to matter and where a wrong answer is recoverable. Instrument it before you change it, so you have a baseline. Change it. Measure the same thing again. That single before-and-after does more to unlock the next phase of investment than any strategy document, because it converts an invisible win into a number somebody can defend.
Where Focus20 fits
We run training as the entry point rather than the product, which is why the same engineers who deliver the workshops go on to observe the workflows and build what the observation recommends. The audit produces the ranked list with ROI estimates and a 90-day sequence — a document you can act on with or without us.