The Handoff Checklist: What 100% Ownership of an Automation Should Include
Ownership isn't a promise from your vendor. It's a list of accounts, credentials, documents, and training sessions that you can verify on a checklist.
On this page
Most automation "ownership" claims fall apart the moment you try to test them. Ask your vendor to leave for 30 days and see what breaks. If the answer is "everything," you don't own the automation. You're renting it with extra steps.
Real ownership is a transferable artifact list. Every account, credential, workflow file, and decision should live in a place you control, in a format you can read without the person who built it. Below is the handoff standard we use at Catalyst, and the one you should demand from anyone building automations for your business.
Accounts must be in your name, on your billing#
The first failure mode is silent: your consultant builds your automation on their OpenAI account, their Make.com workspace, their Airtable. It runs fine. Then they get hit by a bus, raise prices, or simply stop responding, and your operations stop with them.
Before anything is built, every SaaS account in the stack should be created under your company email, paid by your company card, with you as the owner-level admin. Your builder gets invited as a collaborator or admin. Not the other way around.
A practical list for a typical small business automation:
- LLM provider (OpenAI, Anthropic, Google): your account, your API keys, your billing
- Workflow platform (n8n, Make, Zapier): your workspace, your seat as owner
- Database or knowledge store (Airtable, Supabase, Notion): your workspace
- Vector database if applicable (Pinecone, Weaviate): your project
- Email, calendar, CRM integrations: your existing accounts, OAuth granted to the workflow
- Hosting if self-hosted (Render, Railway, a VPS): your account, your card
Credentials live in a vault you control#
API keys, OAuth tokens, webhook secrets, database passwords. These should be stored in a password manager owned by your business: 1Password, Bitwarden, Dashlane, whatever you already use. Not in your builder's personal vault. Not in a shared Google Doc. Not in Slack DMs.
The handoff should include a single vault folder named after the project, containing every credential with these fields filled in: what service, what the key does, when it was created, when it expires (if applicable), and which workflow uses it. Rotate every credential the day the build is finished and again the day the consultant's engagement ends. Both rotations should be your job, with the documentation to do them yourself.
Workflow files exported and version-controlled#
This is where most handoffs quietly fail. The workflow runs in n8n or Make, but the only copy lives inside that platform's cloud. If your account gets locked, your workspace gets corrupted, or you want to move providers, you have nothing to recover from.
Your handoff should include exported JSON or YAML files for every workflow, committed to a Git repository (GitHub, GitLab, your choice) under your organization. Each export should be re-importable into a fresh workspace with documented steps. For each workflow, the repo should contain:
- The exported workflow file
- A README explaining what the workflow does, what triggers it, and what it outputs
- A list of every credential it references (by name, not value)
- A diagram or short loom showing the full path from trigger to result
Documentation written for the next person, not for you#
The person reading the documentation will not be you. It will be your operations lead in 18 months, or a new consultant you bring in, or you on a Tuesday morning when something broke and you have not looked at this system in six months.
Good handoff documentation has four parts:
A system overview of 1-2 pages. What this automation does in business terms. What inputs come in, what outputs go out, what humans are in the loop, and where the seams are.
A runbook for the three or four things that go wrong most often. "The Slack notification stopped firing" → check this, then this, then this. "The model is returning empty responses" → check API key, check rate limit, check prompt template. Written so a non-technical person can resolve 80% of incidents without calling anyone.
A change log of every modification since launch, with date, author, and reason. This is boring and feels like overhead until the first time someone asks why a prompt was changed and you can answer in 30 seconds.
A dependency map. Every external service this automation touches, what would break if it went down, and how much money you are spending on each per month.
If your documentation does not include all four, the engagement is not finished.
Training that ends with you running the system unassisted#
Documentation is not training. Training is the thing where your team operates the system while the builder watches and corrects them, not the other way around.
A proper training handoff has at least three sessions. The first is a walkthrough where the builder demos every workflow and your team takes notes. The second is reverse: your team operates the system, makes a small change, deploys it, and the builder only intervenes if something is about to break. The third happens two weeks later, after your team has lived with the system, and addresses the actual questions that came up in real use.
Record all three. Store the recordings in the same project folder as your documentation. The recordings often become more valuable than the docs because they show the system in motion.
A 30-day independence test#
The final piece of the handoff is a test, not a document. After the official handoff date, your builder goes silent for 30 days. No Slack, no email, no "quick questions." Your team runs the system, modifies it if needed, handles incidents, and pays the bills.
If you make it 30 days without needing the builder, you own the automation. If you don't, the handoff was incomplete and you need to identify exactly which artifact was missing: a credential you couldn't access, documentation that didn't cover the scenario, training that skipped a step. Then close that gap before declaring the engagement done.
This test is the only way to know the difference between ownership and dependency dressed up as ownership.
Common pitfalls#
A few patterns we see repeatedly when reviewing other people's handoffs:
- Credentials stored in the workflow platform's native secrets manager only, with no export. When you lose the platform, you lose the keys.
- Documentation written in the builder's Notion workspace. You can read it. You cannot edit it or take it with you.
- One "super admin" account shared between builder and client. Nobody can be removed without breaking access for both.
- No diagram of the system. Six months later, nobody remembers which workflow calls which.
- Training delivered as a single two-hour Zoom that everyone forgets within a week.
If you're scoping an automation project and want a handoff plan that actually transfers ownership instead of locking you in, see how we structure our engagements. Every Catalyst build ends with the artifact list above, in your accounts, with your team trained to run it.
Need help implementing this?
We build these systems for small businesses and hand you the keys. Book a free discovery call — no sales pressure.
Book a Discovery CallFrequently asked questions
What should be included in an automation handoff?
A complete handoff includes accounts under your name and billing, credentials in a vault you control, exported workflow files in a Git repository, written documentation covering system overview and runbook, recorded training sessions, and a documented dependency map of every external service the automation uses.
How do I avoid vendor lock-in with an AI automation consultant?
Require that every SaaS account is created in your name from day one, that workflow files are exported and stored in a Git repo you own, and that all credentials live in your password manager. The consultant should be a collaborator on your accounts, not the owner of them.
Who should own the API keys for my business automation?
You should. API keys for OpenAI, Anthropic, or any other service should be generated under your company account, paid by your company card, and stored in your password manager. Your builder gets temporary access during the build and that access is revoked at handoff.
What is a 30-day independence test for automation handoffs?
It's a test where your builder goes completely silent for 30 days after the official handoff. If your team can run, modify, and troubleshoot the system without their help during that window, the handoff was complete. If not, you've identified specific gaps that need to be closed.
Should automation workflows be stored in Git?
Yes. Most workflow platforms let you export workflows as JSON or YAML. Storing these in a Git repository under your organization gives you version history, a backup if the platform fails, and portability if you ever need to migrate to a different tool.
How much documentation does a small business automation actually need?
At minimum: a one-to-two page system overview, a runbook for the three or four most common failure modes, a change log of modifications, and a dependency map of external services and costs. This is enough for a non-technical operator to handle 80% of incidents without calling a developer.
