How do you hand an automation over to the client who has to live with it?

How do you hand an automation over to the client who has to live with it?

Give them four things. A plain description of what it does, a map of every account and credential it touches, the failure playbook, and a way to turn it off. If they cannot switch it off without you, you have not handed anything over.

I build automations that keep running after the project ends, and the difference between a build that survives and one that becomes a liability is almost entirely the handover. The code is rarely the problem. The problem is that only one person knows why it exists.

This is the handover I aim for, written from the perspective of the person who will get the call at a bad moment.

Why is handover the part everyone skips?

Because it produces nothing visible. The automation already works, the client is happy, and writing down how it works feels like paperwork rather than progress. Then six months later someone changes a field name and nobody knows what depends on it.

There is also an uncomfortable incentive. An undocumented automation makes the builder indispensable, and that can feel like job security. In my experience it is the opposite. Being the only person who understands something means you can never fully leave it, and it prices your future attention at zero.

The clients who get real value from automation are the ones who can reason about it without me. That makes them more likely to commission the next thing, not less, because the first thing did not become a burden.

What does the description need to contain?

What triggers it, what it reads, what it writes, what it will never do, and who it belongs to. Five lines in plain language, written for the person who inherits it, not for an engineer. If it takes more than a page, the automation is probably doing too much.

Write the trigger precisely, because most confusion starts there. A schedule, a webhook, a form submission, or a manual run all behave differently when something goes wrong, and knowing which one applies tells a person whether to wait or to act.

Name the boundaries explicitly. This automation never deletes records, never sends email to customers, never writes to the revenue field. Those sentences are what let a client rule things out during an incident, and they are also how you find out whether the client agrees with the boundaries you chose.

What has to be in the access map?

Every account, connection, and credential the automation depends on, who owns each one, and what happens when it expires. Connections created under a personal login are the single most common reason an automation dies quietly after someone leaves a company.

My rule is that anything long lived should be connected through an account the business owns rather than an individual's. That usually means a shared operational account with its own mailbox, and it is worth setting up before the build rather than during a panic.

Check each platform's own documentation for how its connections, roles, and permissions actually work before you promise anything specific, because these details differ by tool and change over time. What does not change is the principle. The business should be able to revoke and recreate every connection without asking a former contractor for help.

What goes in the failure playbook?

The three failures most likely to happen, how each one looks from the outside, and the first action for each. Not a theory of everything. A short document that turns a mysterious problem into a known one.

For most builds those three are the same. An upstream system changed shape, a credential expired, or a rate limit or outage interrupted a run. Each has a different signature, and writing that signature down is what stops a client from guessing.

Include what not to do as well. Do not rerun the whole job before checking what already went through, because a rerun without protection creates duplicates. If the automation is safe to rerun, say so explicitly, because that fact is enormously reassuring and it is invisible from the outside.

How do you prove it works at handover?

Run it together, in front of them, including a deliberate failure. A handover where everything succeeds teaches the client nothing about the moment they will actually need to understand it. Break it on purpose and let them watch the alert arrive.

I like doing this with a dry run mode first, so the client sees exactly what would have happened before anything is written. Then a real run on one record. Then a broken input, so they see where the error surfaces and who gets told.

That session is also the best time to find out whether the alerting goes somewhere a human actually reads. An alert into a channel nobody watches is the most common monitoring failure I see, and it is easier to fix in the handover call than after an incident.

Who owns it after you leave?

One named person, written down, with a named deputy. Ownership is not a shared responsibility, because shared responsibility means nobody checks the failed runs. The owner does not need to be technical. They need to know who to call and when to worry.

I ask for that name before the build finishes, because the answer often changes the design. If the owner is non technical, the automation needs clearer alerts and fewer decisions. If the owner is an engineer, it can expose more detail and more control.

An automation without an owner accumulates cost quietly and produces its worst outcomes at the worst time, which is the argument in the cost of an automation nobody owns. Naming someone at handover is the cheapest fix available.

Give that owner enough visibility to answer whether it ran and whether anything needs attention, without being able to break it. Read access to the run history and a plain summary on a schedule covers nearly every question a client actually asks, and it is a quiet business advantage too, since clients who can see an automation working understand what they are paying for. That is the case I made in giving clients read only visibility into automation.

What does a real handover look like in practice?

A short document, a recorded walkthrough, a live session, and a named owner. That is it. For the automations I keep running in production, including an Airtable and WhaleSync pipeline for Ajust and a HubSpot flow through Zapier for Kismet Health, the documentation is deliberately shorter than people expect and kept next to the thing it describes.

The recording matters more than the document for anything with a user interface, because watching someone navigate a tool is faster than reading about it. Five minutes of screen recording per automation, stored where the client can find it, answers most future questions.

And keep it current by making updates part of any change. If a change is worth making, it is worth a line in the document, and if nobody can be bothered to write that line, that tells you something about whether the change was worth making.

Does a good handover end the relationship?

Rarely. In my experience the clients who received a proper handover are the ones who come back, because the first build did not turn into a hostage situation. A clean exit is a better sales argument than any case study.

It also changes the shape of ongoing work in a healthier direction. Instead of paying me to remember things, a client pays me to improve things or to own the responsibility deliberately, which is a decision I described in how I decide whether a retainer makes sense.

The version I avoid is the accidental retainer, where nobody chose ongoing support but the automation quietly requires it. That arrangement makes everyone resentful, and it always starts with a handover that never happened.

What should you do next?

Pick the automation in your business that would cause the most trouble if it stopped, and write its five line description today. Then find out whose login its connections use. Those two steps will probably surface something you did not know.

If you have automations running that nobody documented, untangling and documenting them is work I do regularly, and it usually takes less time than people fear. Reach out if you want help making yours transferable.