Key takeaways
- A system handover should leave the client with the system itself, documentation of how it works, and trained people who can run it.
- Our handovers include the full system, Loom video documentation of how it works, and scheduled training. Everything we build belongs to the client.
- The documentation covers the steps that run automatically too, because someone needs to know that the work is being done, even when no person does it.
- Whether a system survives the handover depends mostly on change management inside the client’s team: a rollout plan, training, and buy-in.
Search for handover documentation and most of what comes back is written for an employee leaving a job, a project closing out, or a building being handed to its owner. A business taking over a system that an outside builder made for it has a narrower question: what exactly do I receive, and what happens when the builder is gone?
We build operating systems for service businesses on Airtable and Softr, connected through Make, n8n and Zapier. “What happens when you leave?” and “Can my team maintain this ourselves?” are two of the questions prospects ask us most often. This guide answers both, in the order a handover actually runs.
What is a handover document?
A handover document records what the next person needs to keep a piece of work running: what it is, how it works, where everything lives and who to ask when something breaks. For a custom-built business system it has to cover the data structure, every automation, the screens each role uses, and the accounts the whole thing runs on.
The general idea has a name in management writing, knowledge transfer: moving what one group knows to the people who will carry on without them. A handover document is the written part of it. Training is the rest.
What should a system handover include?
A complete system handover includes ownership of every account the system runs on, documentation of how each part works, a record of what runs automatically, and training for each role that will use it. If one of those is missing, the client depends on the builder for that part, whether anyone intended it or not.
| Part of the handover | What it covers | What goes wrong without it |
|---|---|---|
| Ownership | The bases, apps and automation accounts sit in the client’s name, with admin access | The client cannot change or move what it paid for |
| How the system works | Recorded walkthroughs and written notes on the data, the screens and the logic | Every question goes back to the builder |
| What runs on its own | A list of each automation: what triggers it, what it does, where it writes | Nobody notices when a step quietly stops |
| How the work flows | A process map of each department and the handoffs between them | New hires learn the tool but not the job |
| Training | Sessions for the people who use the system, by role | The team falls back on the old spreadsheet |
In our handovers the client gets the full system, documentation of how it works in Loom videos, and scheduled training. Everything we build is the client’s to keep and to run day to day.
The third row is the one most often skipped. Our rule is that automations get documented like any manual step. Whether something is written down is never the question. The only question is whether a person or an automation does it, and both get recorded, because someone has to know the work is being done.
How to do a proper handover?
A proper handover happens in order: the builder walks the people who will run the system through it, the documentation goes where the team can find it, training is scheduled for each role, and the builder keeps watching the system after it goes live. Skipping that last step is how small problems turn into surprises.
The walkthrough works best with the people who run each process day to day in the room, along with the owner who signed the contract. It should follow the real work, a new client from first contact to invoice, rather than touring the menus.
At Scenthound, the training covered how the new system works and the reasoning behind it, which is why the team adopted it quickly: they understood why each step was there, so they did not have to memorize clicks.
What happens when the consultant leaves?
When a consultant leaves, the system keeps running, and what matters is who notices when something changes. In our case the relationship does not end at launch: ongoing maintenance and support continue, and every client has a shared Slack channel where their team can ask us questions at any time. When we stay on, the automations are monitored as well.
Monitoring means an alert reaches us when an automation stops running the way it should, so the fix often starts before anyone on the client’s side notices a problem. That matters because automations rarely fail loudly. A connected app changes, a login expires, a form gets a new field, and a step stops quietly while everything else looks normal. The Slack channel covers the rest: a question about a screen, an edge case nobody planned for, a new request.
What clients want from that ongoing relationship varies:
- Some want assurance. The system does what they need, and they want to know that if something breaks, a team who knows it will fix it quickly.
- Some keep building. Ambitious, tech-forward teams keep adding new automations, new reports and new functions to the system once it is in use.
Both are normal. For the second kind of client we can stay on as system administrators, watching how the system runs day to day and improving it as the business grows and changes. Systems also change platforms as they grow. We have moved a lot of clients from Zapier to Make once they were running thousands of tasks, because Make costs less at that volume, and from Make to n8n when their workflows became more AI-heavy.
What is the difference between go-live and hypercare?
Go-live is the moment a new system starts running the real work. Hypercare is the period straight after it, when the people who built the system watch it closely and fix problems fast while users settle in. Large software rollouts, ERP projects especially, plan hypercare as a formal phase with its own team.
For a small business system the same job is done with lighter tools: alerts on the automations, a channel the client’s team actually uses, and a builder who still knows the system. The phase also has critics. Writing for the UK’s Association for Project Management, one project manager argues that no project should need intensive care after go-live, and that monitoring should catch risks before they become a crisis. We agree with the second half, which is the point of alerts that fire before the client calls.
Can my team maintain the system ourselves?
Yes, for the day-to-day work, if the system was designed for it: each role sees only what it needs, the logic is documented, and the people were trained. Changing the structure is a different job. Adding tables, rebuilding automations or connecting a new tool takes skills in data modelling and integrations that most teams do not keep in-house.
Designing for the team is a build decision. At Affinity Care, every role got dashboards and filtered views in Airtable that show what that role needs, and none of them requires technical knowledge to use or keep running. At Nomads Cast, an operator can switch a specific client’s onboarding on or off from a control panel at any point, which is what gave the team the confidence to hand the process to the system.
So the answer has two parts. Your team should be able to run the system without calling anyone. It will probably still want someone for the changes the business asks for next, whether that is the original builder or someone else who knows the platform.
Why do some systems fall apart after the handover?
Most systems that fall apart after a handover were never really adopted. What separates clients who keep a system running from those who let it decay is change management: a rollout plan, training for the people who use it, and buy-in. We recommend the rollout and run the training. The buy-in has to come from the team.
Software adoption in a small team covers that side in detail.
The other cause is the build itself. Airtable is easy enough that anyone can start a base and add a simple automation, and the gap between that and an expert build is wide, because data modelling, automation and interface design take a long time to learn well. People who come to us after a bad experience with an earlier builder tell a similar story: a base built like a spreadsheet, or a builder who knew Airtable but not the integration tools that connect it to everything else.
What should you ask a builder about handover before you sign?
Ask about the handover before the project starts, because the answers shape how the system gets built. Each of these is far easier to settle in the proposal than after launch, when the accounts already exist and the documentation has either been written along the way or has not:
- Whose name will the accounts and the base be in, and will we have admin access?
- What documentation do we get, and does it cover the automations as well as the screens?
- Is training scheduled, and for which roles?
- What gets monitored after launch, and how do we reach you when something breaks?
- What happens to the system and our data if we stop working together?
- Once ownership moves to us, will the passwords and connection keys be changed so that only our team holds them?
- Will we get a written list of anything unfinished or known to be fragile, with who is handling each item?
A builder who answers these in writing has already thought about the day they leave. That is also the work an operations consulting engagement plans for from the start.
Frequently asked questions
What is a knowledge transfer plan?
A knowledge transfer plan sets out what has to be passed on, to whom, and how: documents, recorded walkthroughs, training sessions and a period of supported use. In a system handover it is the schedule behind the handover document, so that each role learns the parts of the system it will run.
Who owns the system after the handover?
The client does. Everything we build is the client’s to keep: the bases, the automations and the documentation. If a builder keeps the accounts in their own name, the client owns a dependency rather than a system, so ask about it before you sign.
Do you stay involved after the handover?
Yes. Ongoing maintenance and support are part of how we work with clients, every client has a shared Slack channel with us, and when we stay on as system administrators the automations are monitored. How much a client needs varies, from occasional fixes to a steady stream of new features.