Revision caps for design studios that clients actually respect

Design studios rarely lose margin on the first concept. They lose it in round five of the homepage, when a stakeholder who missed the first three reviews joins and asks to "explore a warmer direction". Every individual request is reasonable. Together they turn a two-week deliverable into a six-week one, priced as two.

In our onboarding data, revision beyond cap is the third largest category of out-of-scope work overall and the largest for design and UX studios. The usual cause is not a missing cap. Most design SOWs say something like "includes two rounds of revisions". The cause is that nobody defined what a round is, so the cap cannot be enforced without an argument.

There is also an emotional asymmetry. Designers want the work to be loved, so they are inclined to keep iterating until the client is delighted, and clients rarely say "stop, that is enough". A cap protects the studio's margin, but it also protects the work itself: endless rounds tend to sand a strong concept down into something safe. A clear limit forces both sides to give sharper feedback earlier.

A revision round needs four properties written into the SOW. Without them, "two rounds" means whatever the most senior person in the room wants it to mean.

1. Consolidated: the client delivers feedback as one document or one set of comments, not a stream across Slack, email and calls.
2. Approved: one named approver on the client side signs off on the feedback before it is sent. Their colleagues can contribute, but they consolidate.
3. Time-boxed: feedback arrives within a fixed window, typically five business days. Late feedback rolls into the next round.
4. Bounded: a round refines the agreed direction. Requests that change the concept, the audience or the information architecture are new direction, not revisions.

A project-wide cap ("up to eight rounds across the engagement") sounds generous and gets spent early, usually on the first deliverable the senior stakeholders care about. Then every later deliverable is either uncapped in practice or becomes a fight. Cap each deliverable separately and set the number according to how subjective it is.

Put the changes where they are cheap. Two rounds on wireframes and one on high-fidelity components pushes structural feedback to the stage where it costs hours rather than days.

Most revision loops are really stakeholder problems. The person who approves the work is not the person who gives feedback, or a new executive arrives in month two. You cannot prevent that, but you can make it a known event with a known cost.

• Name the approver in the SOW and ask the client to name a deputy.
• Run a stakeholder map at kickoff. Anyone who can veto the work should see the first concept, not the fourth.
• Add a clause stating that feedback introducing new decision makers after concept approval is treated as new direction.
• Record who attended each review. When late feedback arrives, the attendance log turns an argument into a fact.

The hardest conversations are about requests that feel like revisions but are really new work. "Can we see it in dark mode" on a light design, "what if it were more playful" after a corporate concept was approved, or "let's try a version for the US market". These are not round three. They are new deliverables.

A useful internal test: would the change require revisiting a decision that the client already approved in writing? If yes, it is new direction. Write it up as an option with its own estimate, link back to the approval, and let the client decide. Most clients accept the distinction quickly when the approval is quoted back to them, because they remember making it.

Put the price of an additional round in the SOW, per deliverable type. When the number is already agreed, going past the cap is an administrative event, not a negotiation. Some studios offer a bundle of three extra rounds at a discount, which clients often buy at kickoff as insurance. Either approach is better than inventing a price under deadline pressure.

Then track rounds visibly. A simple counter in the review deck ("Homepage, round 2 of 2") does more than any clause, because everyone sees the cap approaching. TWINJAM reads review threads in Slack and Figma-linked tickets in Jira or Linear and counts rounds against the cap automatically, alerting the PM privately when a deliverable reaches its last included round.

Clients respect caps that are clear, fair and visible. They resent caps that appear for the first time in an invoice. The difference is almost entirely in the drafting and in how early the count is shared.