The pattern is consistent
Week one: genuine excitement. The team runs a few prompts, compresses an hour of work into ten minutes, and shares the result in Slack.
Week four: the founder is still using it. Two or three other people dip in occasionally. Most of the team has quietly returned to the old process.
Week twelve: the rollout is described internally as "ongoing." What that means, operationally, is that it stalled.
We have seen this play out enough times to recognise the shape. It is not a motivation problem. It is not a technology problem. The tools are capable. The team is willing. The breakdown is structural — specifically, in how the rollout was handed over. Or wasn't.
What week 12 actually looks like
The tell is what happens when the founder leaves the room.
In a conference company running 75 events a year, the AI workflow existed almost entirely in one person's head. The agenda drafting process — researching topics, drafting session titles, structuring a two-day programme — had been accelerated significantly. But the prompts were saved in no system anyone else could find. The context files that made the output accurate lived in a folder only one person knew about. When that person was unavailable, the team reverted to ChatGPT and a blank page.
Same pattern in a sales operation. Outreach sequences had been rewritten with AI assistance. Open rates improved. But when a new team member joined and needed to draft a sequence for a new event, there was no documented process, no prompt library, no starting point. They guessed. The quality dropped. The team concluded AI wasn't reliable for this and stopped using it.
The rollout didn't fail. The handover failed.
The four moves that fix it
These are not theoretical. They are the specific things we work through with clients when a rollout has stalled.
1. Audit the workflow, not the tool
Before touching anything in the AI setup, map what the team actually does — step by step — for the three or four tasks where AI was supposed to help.
Most rollouts start with the tool and work backwards to the workflow. That produces prompts that work for one person's mental model of the task but break when someone else attempts it. The audit reverses this. You document the real process first, then build the AI layer on top of it. The output of this step is a list of specific tasks, with inputs and expected outputs defined precisely enough that anyone on the team could brief the AI correctly.
For an event production team, this looks like: "Given last year's agenda PDF and a topic research brief, produce a draft session plan for a two-day conference in this format." That is a documentable, repeatable task. "Help me write the agenda" is not.
2. Document the prompts as operational assets
A prompt that lives in someone's browser history is not a business asset. It is a personal workaround.
Every prompt that produces reliable output needs to be written down, labelled, and filed somewhere the team can find it. Not in a personal notes app. Not in a shared Google Doc that nobody maintains. In the same place the team keeps other operational documents — the equivalent of a process wiki or a template library.
This sounds mundane. It is the single most common failure point. We have worked with teams where six months of AI usage had produced zero documented prompts. Every session started from scratch. Every person reinvented the same approach independently. The organisation had captured none of the institutional knowledge the AI work had generated.
3. Train a champion, not a team
The most durable rollouts we have seen share one structural feature: one person on the team owns the AI layer.
Not a technology person. Not necessarily the most senior person. The person who is most curious about the workflow, most interested in making it stick, and most willing to be the internal point of contact when something breaks or a use case is unclear.
That person gets trained properly — not a 90-minute overview session, but the kind of working-alongside that produces actual competence. They know how to update the context files. They know how to write a new prompt from scratch. They know what to do when the output is wrong.
After that, they are the internal trainer. They onboard new team members. They maintain the prompt library. They surface new use cases and bring them to us when the task is non-trivial. The organisation is not dependent on one vendor for every small workflow question.
4. Build the fallback path before you need it
Every AI-assisted workflow needs a defined fallback for when the AI fails, halts, or produces output that cannot be used.
This is not pessimism. It is operational design. The fallback should be documented alongside the AI workflow itself — same document, same level of specificity. If the AI-assisted agenda draft is unusable, here is the manual process that produces an acceptable output in the time available. If the AI-assisted outreach sequence fails a quality check, here is how a team member rewrites it without starting from scratch.
Teams that have not built the fallback path respond to AI failure by abandoning the workflow entirely and concluding that AI is unreliable. Teams that have built it treat it as a normal operational exception, fix the underlying issue, and continue.
The frame we work from
We are not trying to make clients dependent on us to run their AI stack. That would be a bad outcome for everyone.
The goal of every AI engagement we run is to hand it over. We set up the system, run it alongside the team for long enough that it works reliably, document everything, train the champion, and leave. After that you do not need us for the prompts, the context files, or the daily operation. Call us when something genuinely new comes up — a new workflow, a new use case, a non-trivial integration.
The rollout that stalls at three months is usually one that was never designed to be handed over. The four moves above are all, at their core, handover preparation. Run them from week one and week twelve looks different.