Direct answer
The deliverables checklist where every line carries its own evidence.
Most freelancer checklists are file lists: three attachments and a hope. For AI-assisted work that fails twice, once when the client asks how it was made, and again when they ask who approved it. Here is the ten-line checklist that answers both questions before they are asked, because every line points at a record instead of a memory.
Updated October 17, 2026.
The checklist
1. The brief as agreed. Scope, format, deadline, and the price they attach to, copied from the agreement, not restated from memory.
2. Each deliverable, named and versioned. The files themselves, with the version the client is being asked to accept marked as the version.
3. The record of how it was made. The per-step receipts written while the work ran: the calls, their results, and their times. This is the line that separates AI work you can defend from AI work you can only describe.
4. The sources, with their states. Every source the work leaned on, marked resolved, not resolved, or not checked. A source you could not verify is named as one, on the checklist, before the client finds it.
5. The human review state. Who read the output, what they changed, and what they let stand. AI drafted it is a fine answer when a named person reviewed it.
6. The approvals on the way. Outline approvals, draft sign-offs, spend approvals: each one an event with a decider and a time, not a vibe in a chat thread.
7. The delivery link. One link that opens the whole packet. If delivery takes four attachments and a folder invite, it is not a delivery, it is a scavenger hunt.
8. The client decision state. Pending, accepted, or flagged, with the decision itself recorded when it lands. The checklist is not closed until this line moves or is honestly shown as still waiting.
9. The invoice, tied to the same record. The amount, the terms, and the link to lines 1 to 8, so the person paying can check before they pay.
10. The exclusions line. What is not included, what was not checked, and what the record does not prove. Written by you, at delivery, while it is a courtesy, instead of discovered by the client later, when it reads as a confession.
Why the record lines do the heavy lifting
Lines 3, 4, and 8 are the ones file lists never have, and they are the three a dispute ever turns on. How was it made: the record answers with steps and times. What did it rely on: the source states answer, including the uncomfortable ones. Did the client accept it: the decision state answers, and a pending state is itself evidence that the work sat delivered and waiting. When those three lines exist, the checklist stops being your claim about the job and becomes a summary of a record the client can open and check line by line.
That is also why the checklist has to be built from a record written while the work ran. A checklist assembled at delivery time from chat scrollback is a reconstruction, and reconstructions inherit every gap in the scrollback. Work run through Zambo writes each step as a verifiable receipt at call time, so the checklist at delivery is a view over evidence that already exists, including the failed steps and the refused ones, which are the lines that make the whole list believable.
The delivery moment
Send one message: the checklist, the delivery link, and the invoice reference, in that order. Ask for the decision on the record, Accept or Flag, and say what each does: Accept closes the job and starts the payment clock; Flag names the step the client disputes, which turns a vague rejection into a specific fixable line. Then stop talking. A checklist this shape does the persuading, and every extra paragraph you add gives the client something new to argue with.
The honest part
A checklist proves delivery and process; it does not prove the work is good, and it cannot make a client pay. What it removes is the factual fog disputes feed on: what was agreed, what was made, what it relied on, who approved it, and when. A receipt proves the saved result was not changed since it was saved, never that the result was right. Keep line 10 honest and the other nine lines stay credible.
Frequently asked questions
What should a freelancer's deliverables checklist include for AI work?
Ten lines. One: the brief as agreed, scope, format, and deadline. Two: each deliverable, named and versioned. Three: the per-step record of how each deliverable was made, written while the work ran. Four: the sources used, with the check state of each. Five: the human review state, who read it and what changed. Six: the approvals and sign-offs collected on the way. Seven: the delivery link itself, one link the client opens. Eight: the client decision state, pending, accepted, or flagged, with the decision itself on record. Nine: the invoice, tied to the same record. Ten: the exclusions line, what is not included and what the record does not cover. A checklist missing lines three, eight, and ten is a file list, and a file list is where payment disputes start.
Do I need a checklist like this for small jobs?
The small jobs are where it pays. A two-hour job has no meeting notes, no project manager, and no paper trail, so when the client misremembers the scope, the checklist is the whole argument. The record lines cost nothing extra when the work runs through a recording connection: the steps write themselves as the work runs, and the checklist is a view over them at delivery time. What you skip on a small job is the ceremony, not the record.
What if my client will not open a delivery link?
Then the checklist still works as your side of the story. Send it as a plain summary in the delivery email, keep the link in the same message, and keep the record behind it. Most clients do open it when money is attached, because the link is where Accept lives. For the ones who never engage, the checklist plus the record shows exactly what was delivered and that the decision sat waiting on them, which is the strongest position a freelancer can document.
Does a deliverables checklist replace a contract?
No, and they do different jobs. The contract defines what delivery means before the work starts; the checklist proves what was delivered when it ends. They pair: the strongest setup is a contract that names the record and the acceptance test, and a checklist that closes against both. This hub carries a companion page with copy-paste contract clauses for exactly that pairing.
Where do I keep the checklist after delivery?
With the record, not in a chat thread. The checklist lines point at receipts, sources, and a decision, so keep the checklist where those live: the delivery link stays the single address for the whole packet, and the invoice references the same link. Months later, when a question arrives about the job, you send one link instead of reconstructing a folder. Storage you control beats a thread the platform can bury.
Your AI said "done." For $0.99, prove it: https://zambo.dev/day-pass/
Related
- How do I write a contract for AI work so delivery can be verified?
- How do I prove I delivered the work to a client?
- What should I send a client as proof the work is done?
- How do I get written sign-off from a client on finished work?
- What problem are you trying to solve? The problem directory
- My client keeps asking for more revisions. How do I stop endless revisions?
- How do I ask a client for a deposit before starting work?
- My client has not approved the final draft. Can I still send the final invoice?