How do I set up proof of delivery before the busy fall season?
Set it up in the August slack, in three moves: route client work through the recording connection by default, write the delivery standard into your client materials (every deliverable arrives as a checkable handover), and run one rehearsal delivery end to end. Fall then produces records at volume without anyone remembering to make them.
Busy seasons do not create record problems; they reveal which parts of delivery depended on someone having time. The proof habit that survives September is the one installed in August, when a setup afternoon exists and a rehearsal delivery can fail cheaply in front of a friendly client.
The default route is the whole game at volume: when work flows through the connection automatically, the season's hundred deliverables mint their records the way its ten did in spring. The client-facing half matters just as much: tell clients in August that fall deliveries arrive as handovers they can check and accept in one place, framed as the service upgrade it is, so the first fall delivery is the second one a client has seen, the rehearsal being the first.
The rehearsal is the step that separates a setup from a hope: one real deliverable, start to acceptance, with the team watching for every friction (a step class that is always vague, a client question the delivery note does not answer). Fix the frictions in August. In October there is no August.
Checklist: the August delivery setup
1. Default route set: client work runs through the connection; the team's surfaces updated. 2. Delivery standard written: the client note and the delivery message template both say deliverables arrive as checkable handovers with a decision to record. 3. Rehearsal delivery: one real deliverable run end to end; frictions logged and fixed. 4. Acceptance chase rhythm: the weekly pending-decision check calendared for the season. 5. Index live: the season's deliverables will list themselves by client as they ship. 6. Pass planning: coverage bought for the season's pattern (daily work means the Pass; scattered days mean Day Passes), decided now, not mid-rush.
Worked example
The rehearsal's target shape is any accepted record, for example https://zambo.dev/handover/45434a17-4afc-486a-9646-e689bcee4297 : steps recorded during the work, the client's decision recorded on delivery. A rehearsal that ends in that shape, with the friction log written, means the setup is real; anything less is a plan to set up.
Frequently asked questions
It is already October. Is this page too late for me?
The setup still pays: volume continues into the holidays, and the rehearsal can be this week's friendliest delivery. What changes is only the comfort; the three moves are identical, and next August becomes a review instead of a rescue.
Should clients be told delivery is changing?
Yes, once, in August, as an upgrade with a reason: every deliverable checkable in one place, decisions recorded in one click. Clients who hear it as a service improvement behave accordingly; clients surprised by a new format mid-rush behave like people surprised mid-rush.
What breaks first at volume if we skip the setup?
Acceptance chasing. Deliveries continue (work must ship), decisions scatter across threads, and the season ends with a month of archaeology to learn what was approved. The weekly rhythm in item 4 is the cheapest insurance in this file.
By Brennan Zambo, founder of Zambo.
Last verified: 2026-10-17.
Try a handover
A handover gives your client one proof link with verifiable receipts to review, then Accept or Flag.
try it: say 'use zambo to hand this over to <client>' in your ai