ZAMBO.

Direct answer

Their delay is real. Your deadline should move with it.

A project rarely slips because the work got harder. It slips because the photos, the logins, the approvals, or the content never arrived, and the delivery date quietly stayed where it was. The fix is not chasing harder. It is making the wait a dated fact the day it starts, so the schedule resets from the day the missing pieces land, not from the day everyone agreed before the wait existed.

See the instrument first: the live demo runs one real call and hands you its verifiable receipt, no signup.

Updated October 24, 2026. The two delivery records quoted below are real and public, with their client decision states read back from the live service on publication day.

Step 1. Name exactly what you are waiting for, in one list

Vague waiting protects nobody. Write the missing items as a short numbered list: each item, who sends it, and what stage it blocks. One list, in one message, beats six scattered asks across three threads, because a scattered ask can later be remembered as never asked. End the message with the plain consequence: work on the blocked stage starts when these arrive, and the delivery date moves by the length of the wait. Said once, early, and in writing, that sentence is professional. Said at the deadline, it sounds like an excuse, even when it is true.

Step 2. Open the waiting record the day the wait starts

The waiting state needs a date on it, or it never happened. The record format is AER-1, published as an IETF Internet-Draft (draft-zambo-aer1-26), and each step carries a verifiable receipt: a receipt proves the saved result was not changed since it was saved. The two public records below show the two states a job can sit in:

Accepted: the decision is on the record

Pending: checked, and still waiting on a decision

An accepted record, 4 of 4 steps checked, decided_by client, release_hint ok_to_release, is a job whose state nobody argues about. A pending record, 5 of 5 steps checked and release_hint hold, is the honest picture of a wait: the work is done and checked, and the next move belongs to someone else, with the state visible to both sides. Your waiting note works the same way at project level: the date you asked, the items outstanding, and the stages blocked, kept in one place the client can open. When the wait ends, that record is what the new schedule is counted from.

Step 3. Reset the schedule from the arrival date, in writing

The rule to state, and to hold: the delivery date shifts by the number of days the project waited on the client. Items arrive on the 10th after a six day wait, the delivery moves six days. Write the new date in the same thread the moment the items land, and restate it once in the next stage delivery. Do not absorb a client delay silently to be agreeable. Absorbed delays compound: your next client gets squeezed, your evenings pay for it, and at the end the late delivery is the only part anyone remembers. A moved date, confirmed in writing while the wait is fresh, is rarely disputed. A moved date announced at the old deadline almost always is.

Step 4. Keep working on what is not blocked, and say what is not

A wait on one input rarely blocks the whole job. Sort the remaining work into blocked and unblocked, do the unblocked part, and deliver it on the record while you wait. That does two things. It shortens the real delay, because the day the missing items arrive, only the blocked stage remains. And it changes the story from nothing happened for two weeks to everything that could move, moved, with dates. If genuinely nothing can move, say that in the waiting note too, with the reason, so the pause itself is a recorded decision and not a gap you will have to explain later.

Step 5. Chase on a rhythm, not on anxiety

Set the chase rhythm in the first waiting message: a short reminder every two or three working days, each one restating the list, the days waited so far, and the current moved delivery date. Short, factual, identical in shape. The count does the persuading; a client watching the moved date tick later in their own inbox usually finds the missing file faster than any urgent tone could. If the wait passes a point where the job no longer fits your calendar, say so plainly and offer the two honest doors: a later restart date, or a clean pause with the completed stages invoiced and accepted now.

Step 6. Put the waiting clause in the next agreement

One sentence in the agreement prevents most of this: delivery dates count from the day all client inputs for a stage are received, and dates move day for day with client side waits. Clients sign it without blinking, because it is obviously fair in both directions. Pair it with an inputs list per stage, written before work starts, so nobody discovers mid project that a login, a file, or an approval was theirs to send. The clause will not make clients faster. It makes the consequence of slow automatic, which is the part that protects your schedule.

What a record does not settle

A verifiable receipt proves the saved result was not changed since it was saved; it does not make a client send what they owe the project, does not prove why they were slow, and cannot move a date a written agreement fixed absolutely. The waiting list, the dated record, and the reset message are what you would show anyone asked to judge where the time went. This page is general information, not legal advice.

Frequently asked questions

My client is delaying the project by not sending me what I need. How do I protect my schedule?

Protect it the day the wait starts, not at the deadline. Send one written list of the missing items, who sends each one, and the stages they block, and state the rule in that same message: the delivery date moves by the length of the wait. Keep a dated waiting record the client can open, do every unblocked piece of work in the meantime and deliver it on the record, and chase on a fixed rhythm of short reminders that restate the list, the days waited, and the current moved date. The moment the items arrive, confirm the new delivery date in writing in the same thread. A delay handled this way is a schedule fact both sides saw happening. A delay carried silently becomes your late delivery.

Should I pause the whole project while I wait for one missing item?

Usually not. Sort the work into what the missing item blocks and what it does not, and keep the unblocked part moving; when the item lands, only one stage remains and the real delay shrinks. Pause fully only when nothing meaningful can proceed, and then record the pause as a decision: the date it started, what it waits on, and the date the schedule restarts from when the wait clears. An unrecorded full stop is the worst shape, because weeks later neither side can show when the project was working and when it was waiting.

How do I tell a client the deadline moved without sounding like I am making excuses?

Tell them before the old deadline, in the same thread as the waiting list, with the arithmetic visible: items requested on this date, received on this date, six days waited, delivery moves six days to this new date. Numbers stated early read as project management. The same numbers stated after a missed deadline read as defense, even when they are identical and true. If the client pushes back, point at the waiting record rather than re-arguing from memory: the dates were visible to both sides the whole time.

What if the client says the delay was my fault for not asking clearly?

That is exactly the argument the written list prevents. One numbered message, naming each item and its owner, sent the day the need was known, is hard to describe as unclear. If your asks really were scattered across calls and threads, fix it now rather than defending it: send the consolidated list today, open the waiting record today, and let the schedule reset run from today forward. Going forward, every input request goes in writing in one place, so the question never has to be argued again.

How do I keep the waiting state on a record both sides can check?

Run each stage as a handover the client opens: the steps that ran, the saved results, and a place to accept or flag a step, so a stage waiting on the client shows as pending instead of vanishing into chat. When the work runs through Zambo, every step carries a verifiable receipt under AER-1, published as IETF Internet-Draft draft-zambo-aer1-26, and new users get 20 free calls per day, then they upgrade when the job needs more. For $0.99, run the next stage that way and let the record carry the waiting state: get the Day Pass. A Day Pass covers 24 hours, no subscription. Ongoing use is the Zambo Pass at $29 for 30 days (one payment) or $290 for 365 days, and $19 for 30 days for $ZAMBO holders, which adds private handover links, your branding, and the approval record as PDF and JSON files.

Related