# The handover document that survives the builder Source: https://getstartedwithai.net/blog/the-handover-document-that-survives-the-builder Site: Get Started With AI Tagline: Build AI automations that actually run your business. Audience: solo professionals, freelancers, consultants and AI implementers in training Contact: hello@getstartedwithai.co.uk This Markdown companion is generated from the prerendered page for AI crawlers. # The handover document that survives the builder An AI implementation handover document is the written artefact that turns a working build into infrastructure the client team can run after the consultant has gone home. The format I use, after 120+ implementations, has converged on six items on a single page. Six is the number; everything else has been cut as ceremony. A build that runs for three months and then quietly stops has not finished. The handover is what stops that pattern. This post is the six items, what gets cut and why, the three named killers of a handover, the role of the document in the Embed step of the WIRE Method, and a story about a handover that failed and what it cost. ## The six items the document keeps - What the build does, in one paragraph the owner could read in a meeting without rehearsing. - The trigger that fires it, including where the trigger lives, who can change it, and what happens if it does not fire. - The success metric and the baseline it was set against, with the date the baseline was measured. - The Four Breaks to watch for, and how to spot each one before the team has to chase it. - The named owner and the review cadence, including the named successor under the Bus Test. - The escalation path: what the owner does, in order, if the build is producing the wrong output. ## What gets cut from the handover Diagrams of the data flow that nobody opens after week two. Long appendices listing every tool used in the build. A change-log that sits empty for ten months and then collects three updates in a panic. Long-form context about why decisions were made; the owner needs to know what to do, not why the consultant did what they did. Screenshots that go stale within a month of the next interface update. The handover keeps the parts that survive routine use. Everything that does not survive routine use is ceremony, and ceremony is what most consultants overproduce because it makes the deliverable feel substantial. The deliverable that feels substantial is rarely the one that gets used. ## Why one named owner, not a team Owners take care of things; teams hope someone else has. The owner does not have to do all the work. They have to know the answer when something breaks, the name of the successor if they leave the role, and the cadence of the review. Every build with a named owner I have shipped is still running. Most of the unowned ones are not. Naming a team rather than an individual has a 50 to 70 percent failure rate at month six in the engagements I have audited; naming an individual has a 10 percent failure rate over the same period. The difference is structural, not motivational. ## Three named killers of a handover document - Tribal knowledge that lives in the consultants head and never gets written down. The fix is a paid 90-minute handover session with the owner reading the document out loud and asking questions. - Undocumented prompts. The model behaviour depends on the exact prompt; if the prompt is in someones private workspace, the build dies with that workspace. The fix is the prompt living in the team Notion or Google Drive with version control. - Expired API keys, billing accounts and SaaS logins owned by the original configurer. When the configurer leaves, the build stops. The fix is account ownership held by the team, not the individual, before the engagement closes. ## The handover as the Wrap step in the WIRE Method Inside the WIRE Method, the handover is the artefact at the end of the Embed step. The four steps run as Audit, Identify, Run, Embed. The handover document closes the Embed step in writing. Without it, the engagement has produced a working build but no infrastructure: the build will run while the consultant is reachable and drift the moment they are not. With it, the build becomes part of the operational layer of the business and survives turnover, leadership change and platform change. The Wrap word is the underlying job: wrap the build in the documentation that lets it survive without the original builder. ## A handover that failed and what it cost A 30-person recruitment firm in late 2024. We shipped a CV summarisation build that saved each consultant about an hour a day. The handover document was three pages long and covered the prompt, the trigger and the success metric. What it did not cover: the fact that the API key was on the founders personal OpenAI account. When the founder swapped to a Workspace account in March 2025, the API key rotated, the build stopped and nobody noticed for two weeks. Cost of those two weeks: 30 consultants times 5 hours of manual CV summarisation, at an effective rate of £45 an hour. Total cost: about £6,750. The fix on the handover was a single line: API key held in the team Workspace account, with the IT admin as the named successor under the Bus Test. That single line would have saved the £6,750. ## Comparison: my handover format vs the consultancy default Most enterprise consultancy handovers run to 30 to 60 pages and cover stakeholder lists, technology rationale, vendor comparisons, future state architecture, change management plans, training schedules and risk registers. My handover runs to six items on one page. The longer document looks more substantial and gets read less. The shorter document looks slighter and gets used. The honest test: a year after the engagement, ask the named owner which document they have actually opened. In the engagements I have audited, the longer documents are opened roughly twice in 12 months; the six-item documents are opened roughly weekly. Length is not the measure of value; survival under routine use is. ## A monthly review on top of the handover The handover is not enough on its own. The monthly review is the pattern that keeps the document alive. Once a month, the named owner reviews the build, samples 20 outputs against the success metric, updates the prompt or trigger if drift has appeared, and dates the review on the document. Total time: about 30 minutes per build per month. Across a typical 5-build SMB AI implementation that adds up to two and a half hours a month, which is small relative to the time the builds save. The review cadence is what stops the slow drift between the fortnight of output review at launch and the moment a year later when the build has quietly become unreliable. ## Build your first AI system live with Richard A 60-minute live build with Richard Batt. Bring one repeatable task. Leave with a mapped automation, success metrics and a deploy plan you can test the next morning. Free seat, no upsell. ### Live build session The next live session covers the WIRE Method end to end on a real audience build. [Join the next session](/webinar) ## Questions people ask before they start ### undefined undefined ### undefined undefined ### undefined undefined ### undefined undefined ### undefined undefined ### undefined undefined