The pattern is consistent enough that we build around it from day one. A team runs a sharp proof-of-concept. The output looks great in the demo. Sign-off is fast. The vendor or consultant ships, hands over a slack channel and a Loom video, and disappears. Six weeks later the system is technically still on, but nobody is using it. Three months after that, the next reorg or budget cycle quietly buries it.
Month four. Not week one, not month twelve. The pilot doesn't fail loudly, it just stops mattering.
Why the failure clusters there
The PoC succeeds because the consultant is doing the work. They know the prompt, the edge cases, the workaround for the brittle integration. They are the system. When they leave, the system leaves with them.
The team that's supposed to inherit it has its own quarterly goals, none of which are "operate the AI tool the consultancy left behind." The new tool is an additional thing to do, not a replacement for the work they were already doing. So the workflow drifts back. The drafts get rewritten manually. The triage gets done in the inbox again. The dashboard nobody looks at quietly stops being updated.
By month four the original sponsor is asking for the impact numbers. Nobody has them. The system is in a state nobody trusts enough to point to. The next reorg uses that uncertainty as cover.
What we do differently
The handover isn't a milestone at the end. It's the architecture of the engagement.
- Name an owner before kickoff. Not the sponsor, the operator. Whoever is going to run the workflow in month four needs to be on the calls in week one. If you can't name them, we don't ship.
- Build the SOP in parallel. Every workflow we ship has a written runbook the operator can follow without us. Drafting it forces us to surface every undocumented assumption.
- Run evals the team can read. Not benchmark scores, sample outputs scored on a rubric the operator agreed to. They know what "good" looks like and can tell when it stops being good.
- Ship the off-switch on day one. A documented path to turn the system off and revert to the manual workflow without losing data. If pulling the plug is risky, the team won't trust the system enough to operate it.
- Schedule the month-four review. Before the engagement starts. We come back, look at the metrics, and decide together whether to extend, adjust, or sunset.
The frame that survives the reorg
Pilots that stall do so because they live as projects, not as workflows. Projects end. Workflows get owned by a department, get measured against an SLA, get budgeted as a line item. The transition from "interesting AI experiment" to "the way we do intake now" is the actual work.
That transition is what the Implement engagement is built around. The audit picks the workflow, the build ships the system, but the handover is what makes month four boring.
If your AI rollout is a project, it has an end date. If it's a workflow, it has an owner. We design for the second one.
None of this is novel. It's the same lesson services teams learn after getting burned by a consultant deliverable nobody can run. We just decided to put it in the contract, not the post-mortem.
