Six months after the build, the automation breaks, and your AI automation handover document becomes the difference between getting it fixed and being stuck. You open your email to find the person who built it, and the thread goes cold. Nobody on your team knows what the system does, where it lives, or which account it bills to. This is the moment that either saves you or reveals you never had one.
I see this constantly. A founder pays for a build, gets a working thing, and receives no record of how it works. The build is fine until it isn’t. Then the knowledge walks out the door with the vendor.
This post covers what belongs in that document, what to ask for before you sign anything, and how to test whether what you were handed is real.
Key Takeaways
- An AI automation handover document is the written record of what was built, where it runs, who owns each account, and what to do when it breaks.
- Ownership of accounts and API keys matters more than the code. If the build sits in the vendor’s account, you rented it, you did not buy it.
- Ask for the handover spec before the build starts, not after. Written into scope, it costs nothing. Requested at the end, it becomes a change request.
- A working automation with no documentation has a shelf life of roughly one staff change or one platform update, whichever comes first.
- The test of a good handover is simple: can a competent outsider maintain the system using only the document, with no calls to the original builder?
- Most handover failures are not malice. Vendors move on, staff leave, and nobody wrote anything down while the build was happening.
- Documentation is not the same as a brain for your business. The document records what exists; the system has to hold the context that keeps decisions moving.
What an AI Automation Handover Document Actually Is
It is not a user manual. It is not a pretty PDF with screenshots of a dashboard. It is the operational record of a system your business now depends on.
Think of it the way you would think of the paperwork on a commercial vehicle. You want the registration, the service history, the keys, and the name of the mechanic who worked on it. Not a brochure about how nice it drives.
The document answers four questions. What was built? Where does it run? Who owns the accounts? What happens when it stops?
Most handovers I have reviewed answer the first question and skip the other three. A founder shows me a Loom video walking through the automation, which is genuinely useful, and nothing else. No account list. No credentials record. No note of which third-party service the whole thing depends on.
That is the gap. The demo shows you the system working. The handover document is what lets you keep it working without the person who filmed the demo.
The difference between a demo and a handover
A demo proves the build exists. A handover proves you own it.
The two get confused because the demo happens at the end of the project, feels like a conclusion, and carries a lot of energy. Everyone is pleased. Nobody wants to be the one asking about offboarding at the moment the thing finally works.
Ask anyway. The best time to sort out what happens when the relationship ends is while the relationship is good.
The Seven Things That Belong In It
Here is the actual contents list. If a vendor hands you something missing three or more of these, push back before final payment.
1. A plain-English description of every automation. One paragraph per automation. What triggers it, what it does, what it produces, and what a normal run looks like. Written so a new operations hire understands it, not so a developer does.
2. The full account and tool inventory. Every platform the system touches. CRM, email sender, SMS provider, voice provider, database, hosting, scheduler, any middleware. For each one: the account name, who the account is registered to, what it costs, and what billing card is on it.
3. Ownership and access records. Which accounts are in your name and which are in the vendor’s. This is the single most important page and the one most often missing. If your lead-response automation runs through the vendor’s workflow account, you do not own your lead response. You are renting it, and the rent can change.
4. The credentials handover process. Not the passwords in a document. A written process for how API keys and logins transfer to your control, stored in a password manager you own. Keys emailed in plain text are a security problem you inherit.
5. Failure modes and what to do. What breaks most often, what the symptom looks like, and the first three things to check. Every build has known weak points. A vendor who has run the system for a few months knows what they are. Make them write it down.
6. The data map. Where customer data sits, what moves between systems, and what gets stored where. You need this for privacy obligations regardless of how the build went. The Office of the Privacy Commissioner sets out what New Zealand businesses have to be able to say about personal information they hold, and “the vendor knows” is not an answer.
7. The change log. What was built when, what changed, and why. Six months of small tweaks with no record is how a simple system becomes unmaintainable.
Ask For It Before The Build, Not After
This is the part that actually changes your outcome.
Every one of the seven items above is cheap to produce while the build happens and expensive to produce afterwards. The account list writes itself when the accounts are being created. Reconstructing it eight months later means someone digging through billing emails.
So put the handover spec in the scope. One paragraph in the agreement: “Delivery includes a written handover document covering system description, account inventory, ownership records, credential transfer, known failure modes, data map, and change log.”
Good vendors will not blink. They are already doing most of it internally. The ones who push back are telling you something useful about how they operate, and you found it out before you paid.
I do this on my own builds because I have been on the receiving end of the alternative. A client came to me with a lead system built by someone who had gone quiet. Three weeks of my time went to reverse-engineering what the previous build did, most of which was reading logs and guessing. That is billable work that buys the client nothing new. A two-page document at handover would have saved all of it.
If you are mid-build right now and this was not in scope, ask anyway. A reasonable vendor will produce it. If they want to bill for it, that is a fair conversation and still cheaper than the alternative.
How To Test The Handover You Were Given
A document that exists is not the same as a document that works. Here is the test.
Hand it to someone competent who was not involved in the build. Your ops person, a contractor, anyone who can follow written instructions. Ask them to answer three questions using only the document.
Where does the automation run, and can you log in? What breaks first, and how would you know? If we wanted to move this to a different provider tomorrow, what would we need?
If they can answer all three, the handover is real. If they come back with questions that only the original builder can answer, it is a brochure.
The offboarding rehearsal
The harder version of the test is a rehearsal. Pick a quiet week and have someone attempt a small change to the system using only the document. Update a message template, adjust a timing rule, add a field.
You will find the gaps fast. Every gap you find while the vendor is still reachable is a gap you can get filled.
This is the same logic as the disappear test I run with founders on their own operations. What happens if you step away for two weeks? Most people have never checked. The answer is always more uncomfortable than they expect, and always worth knowing early. The same applies to a vendor relationship: what happens if they step away, and have you actually checked?
What The Document Cannot Do For You
Here is the limit, and it matters.
A handover document records a system. It does not think. It sits in a folder, accurate on the day it was written, drifting slightly out of date every week after that. It is a snapshot, not a running brain.
This is the same problem founders hit with process documentation generally. You write the SOPs. Nobody opens them. A year later they describe a version of the business that no longer exists. The document was never the point. The point was capacity, and a document does not add capacity.
So treat the handover as the floor, not the ceiling. It is what stops a vendor departure from becoming a crisis. It is not what stops your business from running out of your head.
What actually does that is a system that holds the context itself: one that knows what you sell, how you operate, what your numbers are doing, and can act on that without waiting for you. The AI brain that holds the knowledge, and the AI workforce that does the recurring work. The handover document is one input into that. On its own, it is a filing cabinet.
The practical sequence is simple. Get the handover document for every automation you already own, because that is defensive and cheap. Then look at whether the automations themselves add up to anything, or whether you have a collection of disconnected parts that each solve one problem and none of them talks. For more on the second question, the 90-day AI automation checkpoint covers how to audit what you have running. If you have already had a build go wrong, recovering after a bad AI automation vendor walks through the salvage process.
Conclusion
An AI automation handover document is not paperwork for the sake of it. It is the difference between owning a system and borrowing one until the person who built it stops answering.
Seven things: the description, the account inventory, the ownership records, the credential process, the failure modes, the data map, the change log. Ask for it in scope, before the build starts, where it costs nothing. Test it with someone who was not there.
And be honest about what it is. A good handover protects you from a bad outcome. It does not, by itself, get you out of running the business from your own head. That takes a system that holds the knowledge and does the work, not a folder that describes one.
Start with the folder, though. Most businesses do not even have that.
Ready to find out what you actually own?
If you have automations running and no clear record of who owns what, that is worth 30 minutes. Book a discovery call, and we will go through what you have, what is missing, and what happens if your current vendor disappears tomorrow. No pitch, no prep required, just a straight look at where you stand.
Frequently Asked Questions
What should be included in an AI automation handover document?
Seven things: a plain-English description of each automation, a full inventory of every account and tool the system uses, records of who owns each account, a process for transferring credentials securely, known failure modes with first troubleshooting steps, a map of where customer data sits and moves, and a change log. Anything less and you cannot maintain the system without the original builder.
Who owns the automation if my vendor built it?
It depends entirely on whose accounts it runs in, and this is rarely stated clearly. If the workflows, API keys, and hosting sit in the vendor’s account, you have functional access but not ownership. Check the account registrations directly rather than assuming. Get ownership written into the agreement before the build starts, because renegotiating it after delivery is much harder.
Can I ask for documentation after the project is finished?
Yes, and you should if it was not in scope. Expect the vendor to quote for it, because reconstructing an account inventory and change log after the fact is genuine work. It is still far cheaper than reverse-engineering the system later. A vendor who refuses outright is worth noting, since you now know what offboarding will look like.
How do I know if the handover document is any good?
Give it to someone competent who was not involved in the build and ask them three questions: where does this run and can you log in, what breaks first and how would you spot it, and what would moving to another provider require. If the document answers all three, it works. If they have to ring the original builder, it is marketing material.
What happens if my automation vendor disappears?
With a proper handover document, you change the account passwords, review the failure modes, and carry on while you find someone new. Without one, you are paying a second person to work out what the first one built, which typically takes weeks and delivers nothing new. The gap between those two outcomes is a two-page document written during the build.
Is a Loom video walkthrough enough documentation?
A walkthrough is useful but not sufficient. It shows the system working on the day it was filmed. It does not tell you which accounts are in whose name, what the billing looks like, where customer data is stored, or what to check when the thing fails at 6 am. Keep the video, then ask for the written record as well.
Should I get a handover document for simple automations too?
Yes, and it is shorter. A single automation needs maybe half a page: what it does, which accounts it touches, who owns them, and what breaks. The effort scales with the build. What does not scale down is the risk, because a simple automation you cannot access is just as blocked as a complex one.
About Octavius
Titus Mulquiney is the founder of Octavius AI, where he builds AI brains and AI workforces for founder-led businesses stuck running everything out of their own head. Twenty years in marketing, ex-Sony product manager, ex-GM Zeal NZ. Based in Auckland, working with operators across NZ, Australia, and the US. Connect on LinkedIn.