TL;DR: A voice agent handover is a property transfer, not a demo. The deliverable is not a working agent, it is a working agent the client can still own if I disappear: five accounts in their name, a system map, a runbook for the four failures that actually happen, a short list of what they may edit and what they must not touch, and a saved scenario set so any change can be re-tested. I have shipped this handover across hospitals, vet clinics, car garages and real estate at Fortell AI, and for a US product at Tested Media. The agents differ. The handover pack barely changes.
Most voice agent projects end badly in the same quiet way. The agent works, everybody is happy, the invoice clears, and four months later the business owner needs one sentence changed and discovers that nobody at their company can log into anything. The build was fine. The handover never happened.
I have been on both sides of this: inheriting agents where the previous builder owned the phone number personally, and handing over systems clients later ran for a year without me. The difference is entirely in what gets transferred at the end, and almost none of it is the agent.
The handover is a property transfer
At the discovery call I am scoping what the agent does. At handover I am answering a different question: if this relationship ended today, what does the client still have?
The honest test is simple. Can the business, without me, change the opening line, see last week's calls, stop the agent entirely, and hand the whole thing to another engineer? If any of those four needs a message to me, the project is not delivered. It is leased.
That framing decides everything below.
The five accounts, and whose name is on them
This is the part that has to be right on day one, not at handover, because fixing it later is genuinely painful. Ownership is set up front and simply confirmed at the end.
The phone number. The client's. Always. I forward the client's existing number into the platform rather than buying a number on their behalf, which means the single most valuable asset in the system was never mine to hand back. Turning the agent off is a change to a forwarding rule they control.
The voice platform account. Billed to the client, with me added as a user. Not my account with their agent inside it. This is the one builders get wrong most often, usually for a good reason (it is faster to set up) and with a bad consequence (their whole call history lives under someone else's login).
The automation layer. Every booking write, CRM update, text and notification runs in n8n behind a webhook, on an instance the client pays for. Keeping the business logic out of the platform is how I avoid lock-in in the first place, and it doubles as the handover story: the expensive part is already in their infrastructure.
The CRM. Theirs by definition, usually before I arrive. At Tested Media, GoHighLevel is the system of record and the agent feeds it, so the leads were never in my custody.
The calendar and mailbox connections. Connected from the business's own Google or Microsoft account, not a service account I created. A booking integration authorised under my login is a time bomb set to my next password change.
At handover I screenshot the billing owner and user list for each of the five and put it in the pack. Five lines. It takes ten minutes and it is the most valuable page in the document.
What is actually in the handover pack
The system map
One page, plain language, showing the path a call takes: number rings, forwards to platform, agent answers, agent calls these three tools, call ends, webhook fires into n8n, n8n writes to the CRM and sends the confirmation text. Every box names the account it lives in.
I draw this for the client but write it for the next engineer. A system map is good enough when someone who has never seen the project can find the thing that broke from the map alone.
The runbook for the four failures that actually happen
Not a generic troubleshooting guide. The four real ones, in order of how often they occur:
- Calls are going to voicemail or ringing out. Almost always the forward, not the agent. Check the forwarding rule first, then whether the platform account is suspended for billing.
- The agent answers but nothing lands in the CRM. The call is fine and the back half is broken. This is the n8n execution log, and it is why post-call automation deserves its own error handling.
- The agent is confidently saying something wrong. Prices, hours, a service they no longer offer. This is the knowledge base, not the prompt, and it is the single most common real request.
- A caller needs a human right now and did not get one. Check who is actually on the other end of the transfer number today, because staff rotas change and nobody tells the agent.
Each one gets: the symptom in the words a business owner would use, where to look, what to do, and when to call me. Four failures, one page.
The edit list: green, amber, red
Clients will change things. Pretending otherwise just means they change things badly. So I hand over an explicit list.
Green, change freely: business hours, prices, services, addresses, staff names, anything in the knowledge base. This is information about their business, they know it better than I do, and it is where almost every real update lives.
Amber, change carefully and tell me: the opening line, the transfer number, the confirmation message wording. Safe in principle, but each one has a blast radius. A new opening line that runs six seconds instead of two changes how many callers hang up before the agent finishes.
Red, do not touch without me: the conversation flow structure, tool and function definitions, endpointing and interruption settings, and the n8n workflows. These are the parts where a small edit silently breaks a path that is only exercised by one caller in thirty. The tuning behind turn taking in particular looks like a set of harmless sliders and is not.
The saved scenario set
Whoever holds the agent next needs to be able to prove a change did not break anything. So the handover includes the scenario set I built during the project: the twelve to twenty calls that cover the paths that matter, including the awkward ones, with the expected outcome for each. This is the same regression set I run before any change goes live, handed over rather than kept.
Without it, every future edit is a leap of faith, and the client learns about the regression from a customer.
The numbers, and what they mean
A dashboard is useless if nobody agrees what a good week looks like. I hand over the five numbers I actually track with the baseline from the first month written next to each, so the client has something to compare against instead of a feeling. At Tested Media that view is the chat-dash client dashboard, deliberately simpler than the CRM, because the owner checks it on a phone between jobs.
The three things clients break in month one
From watching this play out repeatedly:
They edit the prompt to fix a knowledge problem. The agent quoted an old price, so they paste the new price list into the prompt. Now the prompt is three times longer, the agent is slower, and the knowledge base still says the wrong thing. This is why the green list exists and why it names the knowledge base specifically.
They change the transfer number without testing it. The most common outage I get called about is a transfer pointing at a phone nobody carries any more. It is a thirty second test that nobody performs.
They add a new service and expect the agent to know. Reasonable expectation, wrong mental model. The handover has to say plainly that the agent knows what it was told, and that new information is an edit somebody has to make.
None of these are the client being careless. They are all symptoms of a handover that explained the system instead of explaining the seams.
The support window, and saying what it is
I keep a named window after go-live, usually thirty days, and I say exactly what it covers: things that were working and stopped, plus one round of tuning from real call data. It does not cover new capability, because new capability is a new project and blurring that is how good relationships quietly go bad.
The first two weeks live are mine regardless. Handover paperwork on day one and silence afterwards is not a handover, it is an exit. The pack gets finalised at the end of that window, once the agent has met real callers and I actually know which four failures to write about.
If you are an agency handing over to your own clients
The same structure scales down. Agencies reselling voice agents face this at every client, not once, which is precisely the problem VoiceDash exists to solve: the client gets a branded portal on the agency's domain, and the agency keeps the platform relationship underneath. The ownership question moves up one level. The client owns their number and their CRM, the agency owns the platform account, and the handover pack becomes a template you fill in rather than a document you write.
The rule survives the change: whoever is left holding the system has to be able to see it, change the safe parts, and stop it.
The short version
A voice agent is not delivered when it answers the phone well. It is delivered when the client can run it without you.
Five accounts in their name. One page showing how a call flows. One page covering the four failures that actually happen. A three tier list of what they may edit. A scenario set so any change can be checked. A baseline for the numbers. A support window with a stated end.
It is maybe half a day of work at the end of a two to four week project, and it is the difference between a client who renews and a client who is quietly trapped. Nobody renews out of gratitude for being trapped.
I build production AI voice agents and the automation, CRM and telephony layer behind them for founders across the US, UK and Europe. More about my work here, or book a call.