The Handoff Checklist: What Every Built System Should Come With

Most automation engagements end with a Loom video and a Slack message. Three months later, something breaks, the consultant is on retainer in another country, and you discover the Zapier account is registered to their personal Gmail. This is the ownership trap, and it is almost always caused by a sloppy handoff rather than malice.

A handoff is not a meeting. It's a set of artifacts your team should be able to point at, audit, and use without the original builder in the room. Below is the literal checklist you should hand to any consultant — internal or external — before you wire the final payment. If they can't produce these, the engagement is incomplete, regardless of what the demo looked like.

1. Account and credential ownership transfer

Every third-party tool the system touches should be owned by an email address you control, on a domain you control. Not the consultant's @gmail.com. Not a shared team@ alias they set up. A real account on your domain, with billing tied to your card or your company's.

Ask for a written inventory: tool name, account email, plan tier, monthly cost, who has admin access, and the date ownership transferred to you. If the consultant used their own OpenAI key or Twilio number during build, you need a documented swap to yours before sign-off. Test it. Send a real message. Run a real workflow. "It should work" is not the same as "it worked at 2:47pm on Tuesday."

2. Credential rotation plan

Every API key, OAuth token, and service account in the system needs three things documented: where it lives, who has it, and how to rotate it. The rotation steps should be a numbered procedure, not a sentence like "regenerate in the dashboard."

A good rotation plan tells you which workflows depend on the key, the order to update them in to avoid downtime, and the rollback step if rotation breaks something. Aim to rotate every credential within 90 days of handoff. If you can't, the documentation isn't good enough.

3. The runbook

The runbook is the operating manual for the system. Not the build documentation. Not the architecture diagram. The thing a new employee reads at 9am Monday to understand what this automation does and how to keep it alive.

A usable runbook covers:

• What the system does, in two sentences, in plain English
• Inputs (what triggers it) and outputs (what it produces, where it lands)
• The full process flow, step by step, with screenshots of each tool involved
• Known edge cases and how the system handles them
• What "normal" looks like — typical run volumes, expected duration, success rates
• What "broken" looks like — the specific signals that something is wrong

If the runbook is shorter than the build was complex, it's incomplete.

4. Test cases with expected outputs

You need a set of inputs you can feed the system whenever you suspect something is off. Each test case should specify the input, the steps to run it, and the exact expected output. "Send a test webhook and verify it works" is not a test case. "POST this JSON payload to this endpoint, confirm row appears in Airtable table X with status = 'processed' within 30 seconds" is a test case.

Five to ten test cases covering the happy path and the most common failure modes is usually enough for a small business system. These are also your regression tests when you make changes later.

5. The change log

From day one of the build, every meaningful change should be logged with a date, a description, and the person who made it. At handoff, this log gets transferred to you and continues to be maintained by whoever inherits the system.

This sounds bureaucratic. It saves you when, eight months from now, a workflow starts behaving differently and nobody remembers what was modified in March. A change log is the single cheapest insurance policy in software, and most consultants skip it.

6. Error handling and alert routing

Where do failures go? If a Zap errors out at 3am, who knows? If an API call to your CRM fails silently, how long before someone notices? The handoff should include the alert routing map: which failures trigger which notifications, to which channel or person, with which severity.

This is also where you confirm there's a dead-letter queue, a retry policy, or at minimum a daily summary of any failed runs. Systems that fail silently are worse than systems that don't exist, because they erode trust in your data.

7. The data dictionary

For any system that creates, modifies, or reads structured data, you need a dictionary of the fields involved. Field name, data type, what it represents, where it comes from, what writes to it, what reads from it. This is tedious to produce and indispensable six months later when somebody asks "what's the difference between status and state in this table?"

8. Cost and usage baseline

Document what the system costs to run today and what drives that cost. If you process 500 records a month at $0.02 of OpenAI usage per record, that's $10. If volume triples next quarter, you should already know the bill is going to $30, not get surprised by a $400 charge.

Include every line item: tool subscriptions, API usage, storage, anything per-seat. This baseline is also how you'll evaluate whether the system is delivering ROI in twelve months.

9. The escalation path

When something breaks and the runbook doesn't solve it, what happens next? The handoff should name the support tier of every tool involved (free, pro, enterprise), the response time you can expect, and any escalation contacts the consultant has built up. If they have a back-channel Slack with someone at a vendor, that contact should transfer to you in writing.

Also document who internally owns the system. Not "operations." A name. With a backup name.

10. A working knowledge transfer session — recorded

Finally, a live session where the consultant walks your team through the system, makes a change in front of you, breaks something on purpose, and fixes it. Recorded. Indexed. Stored somewhere your team will actually find it.

This is the moment to ask every "what if" question you've been holding. What if this API goes down? What if we need to add a field? What if we want to swap tools? If the consultant can't answer those without hedging, the system isn't ready to be yours.

What to do with this list

Send it to your consultant before you sign the statement of work, not after. A serious operator will recognize most of it and tell you which items are overkill for your scope. A bad one will get defensive or vague. That signal alone is worth more than any portfolio.

If you've already inherited a system that came with none of this, it's not lost — it just needs an audit before the next thing gets built on top of it. We do these handoff audits as a standalone engagement, and they typically take a week. See how we structure the work.