What you should get when an automation is handed over to you
The build went well. It works, you have seen it work, and the developer is ready to invoice. This is the moment where most small businesses accidentally buy a dependency instead of an asset, and the difference will not be visible for about six months.
A useful definition, borrowed from software handovers generally: the handover is complete when a competent person who has never met the builder can set up, run and change the thing without contacting them. Anything short of that leaves you with a working automation and a permanent phone number you have to keep calling.
Why this goes wrong even with good developers
Not through malice - through the ordinary shape of the work.
Somebody who builds automations spends their day inside the tools. What they can see at a glance is invisible to you: which workflow feeds which, why that step has a two-minute delay, what the odd-looking filter on step four is protecting against. None of it is written down because none of it needed to be while one person held the whole picture.
Then the project ends. The knowledge leaves with them, and what remains is a system nobody in your business can read. Automation professionals discuss this among themselves in exactly these terms - inheriting a workflow with no owner, no documentation and no idea what it can break is a known and unloved genre of job.
The list
Ask for these before the final payment, not after. Every item is reasonable, and a builder who has done this properly will have most of them already.
1. Access in your name. Every account, platform and credential the automation uses, owned by your business rather than by the contractor. If it runs in their workspace, it is not yours - see whose accounts your automation runs on for why this is the item that most often turns into a hostage situation.
2. A plain-language description of what it does. Not a technical diagram. A paragraph per workflow: what starts it, what it does, what comes out, what it touches. Written so that you can read it.
3. What it costs to run. Which subscriptions, which per-use charges, what happens to the bill if volume doubles. This is the number that surprises people in month four.
4. How you know it is working. Where the alerts go, what a failure looks like, and who receives it. If the answer is "you would notice", the build is not finished - see why automations fail silently.
5. The failure list. What the builder knows can go wrong, and what to do about each one. Every honest builder has this list in their head. Getting it on paper takes them twenty minutes and saves you a week.
6. How to make the obvious changes. The three or four things you will certainly want to change - the text of a message, an email address, a threshold, a schedule - and the steps to change each without touching logic.
7. Where the switch is. How to turn it off. Immediately, safely, and without breaking anything else. You need this before you need it.
8. What it depends on. Which of your systems it talks to, and what happens when one of them changes. Software you rely on gets updated by other people on their timetable.
9. A named owner on your side. Not a document - a person. Someone in your business whose job includes knowing this exists. Automations decay because nobody owns them, and this is the item most often missing.
The test that settles it
Documentation is easy to produce and hard to judge. There is a much better check, and it takes an hour.
Have somebody from your team who did not build it perform a routine change, using only the handover pack, while the builder watches and says nothing.
Change the wording of a customer message. Add a recipient to an alert. Adjust a threshold. If your person can do it from the documentation, the handover is real. If they cannot, you have found the gap while the builder is still engaged and still being paid - which is the entire point of doing it now.
This one exercise finds more missing knowledge than reading the whole pack carefully. It also tells you something the documents cannot: whether the system is comprehensible to the people who will live with it.
What handover does not mean
It does not mean you now maintain it yourself, and it does not mean the relationship ends.
Plenty of small businesses sensibly keep the builder on for changes. The point of a handover is not independence for its own sake - it is that you are choosing to keep them because they are good, rather than because you have no alternative. Those are very different negotiating positions, and the difference shows up in what a change costs you two years later.
It also does not mean the documentation is finished forever. It should be updated when the automation changes materially. In practice that means whoever makes the change updates the page, and the named owner from item nine notices when they do not.
If you already have automations with no handover
Most businesses reading this are in this position, and the work is smaller than it looks. In order:
- List what you have. Every automation, what it does, roughly. You will almost certainly find one nobody remembers commissioning.
- Find out whose accounts each runs on. The most urgent item, because it is the one that fails hardest.
- Check what happens when each fails. Silence is the wrong answer.
- Write the paragraph for each. Half a day of work, done by whoever knows most.
- Name an owner.
Steps one to three are the audit; four and five are the fix. If you would rather not do it yourself, that is roughly the shape of the process audit - $299, three business days, a written map of what runs, on what, and what breaks when it stops.