How to set revision limits

Why a limit helps everyone

Revisions without a limit don't produce a better result, they produce a slower, more scattered one. When feedback has no cost and no end, clients drip-feed it, change their minds, and revisit decisions that were settled. A limit changes the incentive: the client consolidates their thoughts and prioritises, because each round is a resource they're spending. You get sharper feedback and a project that actually finishes.

It also protects your margin. Revisions are one of the biggest sources of overrun on a fixed price, precisely because they feel small individually, which is why they're a core part of preventing scope creep.

How many rounds to offer

There's no universal number, but a sensible default for most web projects is two rounds of revisions per stage, design, then build. That's enough for genuine refinement (first pass, considered feedback, polished result) without opening the door to endless iteration.

• One round, fine for small, well-defined pieces where the brief is tight.
• Two rounds, the sensible default for most design and build stages.
• Three rounds, for larger projects, or where the client is a committee and you've priced the

extra cycles in.

Whatever you choose, tie it to a stage, not the whole project. "Two rounds per stage" is clear; "a few revisions" is a future argument.

Word the clause clearly

The clause needs to say three things: how many rounds, per what, and what happens beyond the limit.

Revisions: Each design and development stage includes up to two rounds of revisions. A round is one consolidated set of feedback returned within five working days. Further rounds, or feedback that reopens a signed-off stage, are billed at our standard rate of £[x]/hour, agreed in advance.

Two details do a lot of work here. "Consolidated" stops ten separate emails counting as one round in the client's mind and ten rounds in yours. And "reopens a signed-off stage" protects you from the classic "actually, can we change the whole homepage layout" after design was approved.

Define what counts as a revision

Not every request is a revision, and being clear about this prevents the argument.

• A revision is a change within the agreed direction: adjust spacing, swap an image, reword a

heading, tweak a colour.

• A change request is new scope: a page that wasn't in the brief, a feature nobody quoted, a

wholesale change of direction after sign-off. That goes through change control, priced separately.

Naming the difference up front means the conversation is "that's a change request, here's the price", not "I thought that was included".

Handle the round that goes over gracefully

When a client hits the limit, the goal isn't to down tools mid-sentence. It's to make the next round a visible, agreed decision. A calm "we're at the end of the included rounds for this stage, happy to do another, it'll be about two hours at £[x]" keeps goodwill and gets you paid. Because you set the expectation in the signed document, it lands as a reminder, not a surprise.

Keeping the revision terms attached to the live scope, rather than buried in a PDF nobody reopens, means both sides can see the agreement when it matters. That continuity is part of why ScopeDeck keeps the scope, terms and delivery on one document.