Direct answer

Endless revisions end when the rounds become countable.

A revision loop rarely survives being counted. It lives in the gaps: nobody wrote down how many rounds were included, feedback arrives one message at a time, and no version was ever formally approved, so every new request feels like part of the same endless round. Close the gaps and the loop closes with them. Here is the whole method, including the exact reply to send when the included rounds run out.

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

Updated October 18, 2026. The delivery record quoted below is real and public, with its client decision state read back from the live service on publication day.

Why the loop never closes on its own

Four gaps keep it open. The agreement never defined a round, so the client experiences every message as a small continuation rather than a new round starting. Feedback trickles in across days, so work you already revised gets revised again underneath you. New requests quietly change the scope while wearing the word revision. And no version was ever accepted in a way either side can point to, so there is no agreed finish line to defend. Each gap is a missing record, and each one closes the same way: write it down where both sides can see it.

Step 1. Sort every request: fix or change

Before counting anything, split the pile. A fix corrects work that does not match the agreement: a wrong figure, a missed requirement, a defect. Fixes are yours, at your cost, and doing them promptly is what makes the rest of this page credible. A change asks for something the agreement did not call for: a new section, a different direction, a preference reversed. Changes are new work. Most revision fights are really one unsorted pile: the client treats changes as fixes, you treat fixes as changes, and both of you feel cheated. Sort in the open, request by request, against the written scope.

Step 2. Count the rounds out loud

Reply to feedback with the count in the first line: this is round two of the two rounds included. Ask for one consolidated list per round, after the client has reviewed the whole delivery, and start revising only when the list is complete. The count does two jobs. It tells the client the meter exists before it runs out, which changes how carefully they spend a round. And it creates the dated trail that settles the later argument about how many rounds already happened.

Step 3. Price the next round before it starts

When the included rounds are used, the next round is a small purchase, not a favor and not a refusal. Name the price, name what it covers, and get a short written yes before starting. Clients who genuinely need another round usually pay without drama once the boundary is factual. Clients who were spending your time because it was free usually discover the current version is fine. Either way the loop ends, which was the point.

Step 4. Close each version with a decision

The deepest cause of endless revisions is that no version ever becomes final. Email attachments cannot fix that: version seven looks exactly like version six, and approval in a chat thread dissolves on contact with a dispute. Deliver each version as a record instead. When work runs through Zambo, the delivery arrives as one handover link the client checks step by step and then accepts or flags. A real example, read back from the live service on publication day:

Accepted: this version is the finish line

The contrast state matters just as much: a handover still pending, decision hold, is a version nobody has approved yet, and revision requests against it are still inside the current round. Accepted versus pending is the whole argument, settled by the state of the record instead of by memory.

What a record does not settle

A delivery record proves the saved result was not changed since it was saved, and it shows which version the client accepted and when. It does not prove the work is good, and it cannot make a client like a design. Taste arguments are settled by the agreement and the acceptance test you wrote into it. What the record removes is the procedural fog around the taste argument: how many rounds happened, what each round asked for, and which version was approved. Most loops live in the fog, not in the taste.

The four lines to add to your next agreement

How many rounds are included. What counts as one round: one consolidated list, answered in one version. What an additional round costs. And how a version becomes final: the client accepts the delivery record, or flags a specific step within an agreed number of days. With those four lines in place, this page becomes a process you run once, briefly, instead of a negotiation you repeat on every job. The contract page in the related links carries copy-ready clauses in the same spirit.

Frequently asked questions

My client keeps asking for more revisions. How do I stop endless revisions?

Sort every request into one of two piles first. A fix corrects work that does not match what was agreed, and it is yours to do. A change asks for something new or different from the agreement, and it is new work with a price. Then count the rounds out loud: name the round number in every reply, and ask for one consolidated list per round instead of a trickle of messages. When the included rounds run out, the next round gets a price and a short written yes before it starts. Deliver each version as a record the client accepts or flags, so the approved version is a fact neither side has to reconstruct later. Most loops end at the counting step, because the client can finally see the meter running.

What counts as one round of revisions?

One round is one consolidated list of changes, sent after the client has reviewed the whole delivery, answered in one new version. Ten messages across two days about the same delivery are still one round if they arrive before you start revising, and a single message asking for a new section, a new format, or a different direction is not a revision at all: it is a change of scope. Write that definition into the agreement before work starts, because defining a round after round four is an argument, and defining it before round one is a process.

What do I say when the included rounds run out?

Say the count, say the price, and offer the choice. For example: we have completed the two rounds included in the agreement, and the current version is the one you accepted on Tuesday. I can do a third round for a stated amount, or we can close with the accepted version. Which would you like? The sentence works because every part of it points at a record: the agreement that set the rounds, the versions that used them, and the acceptance that closed the last one. It is a process speaking, not a person refusing.

How do I tell a fix from a change when the client calls everything a revision?

Hold the request up against the written agreement and the last accepted version. If the delivered work fails to match what was agreed, it is a fix and the cost is yours. If the work matches the agreement and the client now wants it different, it is a change and the cost is theirs. When the agreement is vague, the honest move is to split the difference once, in writing, and then tighten the wording for everything after. What you cannot do is relitigate the boundary from memory: the version history and the acceptance state are what make the boundary visible.

How do I set the next project up so revisions stay bounded?

Put four lines in the agreement: how many rounds are included, what counts as a round, what a further round costs, and how a version becomes final. Then deliver every version through Zambo as a handover the client checks and accepts or flags, so each round closes with a recorded decision instead of drifting into the next one. For $0.99, close the current loop with a record the client has to decide on, instead of another open-ended draft: get the Day Pass. A Day Pass covers 24 hours, no subscription. Ongoing use is the Zambo Pass at $29 a month or $290 a year, and $19 a month for $ZAMBO holders, which adds private handover links, your branding, and the approval record as PDF and JSON files.

Related