Template · Loop: per client delivery

Deliver the build. Freeze the record.

A copy-paste run card for handing an automation to a client: baseline, checks, delivery note, and the client's own acceptance, bound in one chain your client can check long after the engagement ends.

You delivered the automation, the client paid, everyone moved on. Six weeks later the message lands: it stopped working, and anyway, why did we approve this version? Your only evidence is a chat thread, a call you half remember, and a workflow that has been edited eleven times since delivery. Nothing you say can settle it, because nothing was frozen when it could have been.

This template freezes the delivery at the moment of delivery: the config as handed over, the acceptance checks as they ran, and the client's own acceptance, recorded on the record. The twist has a name: the record outlives the engagement. Your client holds a link they can check next month or next year, without you, your account, or your tools.

The run card

Copy it, swap the brackets, run it on your next delivery.

JOB: Deliver [THE DELIVERABLE] to [YOUR CLIENT]
GOAL: [WHAT THE DELIVERABLE DOES, IN ONE SENTENCE]
RECIPIENT: [CLIENT NAME]

Connect your AI to Zambo at https://zambo.dev/mcp (setup guides for your AI client: https://zambo.dev/add/), then run:

1. Snapshot what you are delivering. Pull the live config of [THE WORKFLOW OR BUILD] and log it as the delivery baseline with journal_log: the version, the config's hash, and where the full config is stored, so the entry's receipt binds those exact bytes. (1 call)
2. Run the acceptance checks you agreed at kickoff: [CHECK 1: IT STARTS], [CHECK 2: IT HANDLES THE MAIN CASE], [CHECK 3: IT FAILS SAFELY]. Log each result with journal_log as you run it. (3 calls)
3. Save the delivery note with memory_remember: what shipped, which version, and what the client owns from today. (1 call)
4. Close the job with workflow_close, so steps 1 to 3 bind into one chain. (1 call)
5. Create the handover with handover. Summary: [ONE LINE: WHAT WAS DELIVERED]. Goal: [THE GOAL ABOVE]. Recipient: [YOUR CLIENT]. Next steps: [WHAT THE CLIENT DOES NEXT, FOR EXAMPLE: OPEN THE LINK, CHECK THE BASELINE, RECORD ACCEPTANCE]. The result gives you two links: send your client the client link, the one they accept or flag from. The public link is the read-only record anyone can check. (1 call: the day's free wrap-up handover)
6. Client side: your client opens the client link, checks the baseline and the check results, and taps Accept or Flag. Their decision lands on the record with its own receipt. Pickup is always free, checking costs them nothing, and the public link stays read-only for anyone else.

The budget, counted

What your client receives

The handover link. On it they can check: the delivery baseline (the config exactly as handed over, not as it looks after later edits), the three acceptance check results as saved, your delivery note, and the acceptance step, which they reach from the client link you sent (the public page itself is read-only). If the automation later stops or changes, the baseline is what everyone compares against, so "what changed" becomes a diff instead of an argument. The record stays readable after the engagement ends, which is the whole point. One boundary, stated plainly: the delivery note is a saved note, kept 7 days on the free tier and through a pass plus 30 days. The handover record, its receipts, and the baseline and check entries do not expire.

Related

• All handover templates
• Client sign-off for AI work: acceptance on the record
• The $0.99 Day Pass

Frequently asked questions