My client keeps delaying approval of my work. What can I do?
Make approval cheap and safe: deliver one link where the steps sit against the brief, flag your own gaps before the client finds them, and ask for exactly one decision, accept, or hold and name the step. Review the receipt and actual deliverable before accepting a handover.
Approval delay has three common engines, and each has a counter. The first is effort: checking a delivery properly looks like an afternoon, so it waits for an afternoon that never comes. The counter is the readable record, steps against the brief, sampled in minutes. The second is risk: approving means owning the outcome internally, so the approver postpones ownership. The counter is your own flags on the record, unresolved sources and unchecked steps named by you, which show the approver the work was already reviewed by someone careful. The third is ambiguity: nobody is sure whose decision it is. The counter is naming the approver in the delivery message and asking them for the single decision.
Follow-up then becomes administrative rather than emotional. The record shows delivered, awaiting decision, with the date; your reminders cite the state and the item, not your feelings about the state. Terms set at the start complete the system: a review window after which the late steps begin (payment clock, work pause on the next phase), agreed while everyone was friendly.
If delays persist across a client relationship despite the system, read the pattern as information: approval delay is often budget delay or priority collapse wearing a process costume. The record cannot fix those, but it can stop them being charged to your work's quality, because the state, delivered and awaiting decision since a named date, is visible to anyone the client escalates to.
Checklist: the approval-delay counters
Counter 1, effort: delivery as one link, steps mapped to the brief, five-minute sample path. Counter 2, risk: your own gaps flagged on the record before the client looks. Counter 3, ambiguity: approver named in the delivery message; one decision requested (accept, or hold and name the step). System: review window in the terms, with the late step that follows it. Follow-up: reminders cite the record's state and date, one line each, no new arguments. Escalation: after the window, the open state itself is the exhibit in any internal escalation on the client's side.
Worked example
The open state that carries the follow-up is public in shape: https://zambo.dev/handover/bd7e5325-33fd-4c5e-b029-76b781fa2f51 shows a delivered job awaiting its decision, readable by anyone. A reminder that links this object argues by existing; it does not need adjectives.
Frequently asked questions
Is a deemed-approval clause (silence means yes) a good idea?
It is common in strong terms and it does move behaviour, because it reverses the default. If you use one, state it clearly in the agreement and remind once inside the window; the record supplies the delivery date the clause counts from.
The approver is waiting on their own boss. What helps?
Give the approver ammunition: the record link plus a three-line summary they can forward upward unchanged. Approvals stall in chains; equipping the middle link is the fastest intervention you control.
Should I start the next phase while approval is pending?
Only if the terms price that risk explicitly. The healthy default is that phases start on recorded acceptance; starting on hope converts the client's delay into your exposure.
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