There is a particular kind of stall that happens after a successful pilot. The technology worked. The people who saw it agreed it was valuable. A rollout was discussed in general terms. And then nothing, for months, with no decision to point to.
This is not indecision. It is usually a set of unowned questions that nobody raised during the pilot because the pilot did not require answers to them.
Nobody agreed whose budget it comes out of
A pilot is cheap enough to fund from a discretionary line. A rollout is not, and it typically delivers savings in one part of the business while costing money in another.
The operations team benefits. The technology budget pays. If those are different cost centres with different owners and different targets, the project needs a decision at whatever level those two report into — and that decision has not been asked for, because everyone assumed somebody else was asking.
This is worth surfacing during the pilot rather than after. The question is not "was it good", it is "if this works, whose line does it land on".
The pilot avoided the integration
Almost every pilot runs on an export. Somebody produced a file, or stood up a copy, and the system worked against that.
Production means reading from the system of record, writing back to it, and doing so within whatever change process governs that system. If the system of record is an ERP with a quarterly release train and a change advisory board, the integration is not a sprint — it is a queue, and the queue is owned by a team with its own commitments.
Nobody hid this. It simply was not in scope, and so the estimate everyone is carrying in their heads is the pilot's, which is wrong by an order of magnitude for reasons that have nothing to do with AI.
No one decided what happens to the work that disappears
If the system handles a large share of a task, the people who did that task have capacity freed. What happens next is a management question that the project cannot answer for itself, and it is uncomfortable enough to defer.
Left unanswered, it gets answered informally by the people affected, who conclude — reasonably — that cooperating with the rollout is not in their interest. Adoption problems that look like usability problems are frequently this.
The projects that move are the ones where the answer is stated early and is credible: this capacity goes to the backlog we never get to, or to the quality checks we currently skip, or this team shrinks by attrition and here is the timeline. Any of those can be worked with. Silence cannot.
The success criteria were never written down
A pilot is judged by whether people are impressed. A rollout has to be justified against a number, and if nobody agreed the number in advance it gets invented afterwards by whoever is most sceptical.
Agree before the pilot what would constitute success, in units the business already tracks: time per case, cases per person per day, error rate, backlog age. Measure the current value first. Without a baseline there is no argument, only impressions, and impressions do not survive a budget round.
It has no owner in the business
Most stalled projects have a technical owner and no operational one. The engineering team can build it and cannot decide that a process changes, that a team is retrained, or that a policy is amended.
Until somebody who owns the process owns the outcome, there is nobody whose job is to unblock it — so it waits, politely, behind things that do have owners.
What to do while it is stalled
The instinct is to build more, on the theory that a more complete system will be more persuasive. It rarely is, because none of the blockers above are about the system.
More productive: write down what a rollout actually requires — the integration path and who owns it, the cost and whose budget, the baseline and the target, what happens to the freed capacity, and the name of the person in the business accountable for the outcome. Take that to whoever can decide.
It is a less satisfying document than a demo. It is also the thing that either moves the project or reveals honestly that it is not going to move, which is worth knowing sooner than eighteen months from now.
Thinking about this for your own business?
We have been building and running enterprise systems since 2011. Talk to a solutions lead about where agents pay off first.
Talk to a solutions lead