How to stop scope creep without losing the client

Scope creep is usually not bad faith

Most clients who ask for more are not trying to take advantage. They see the work take shape, they understand their own needs better, and they want what they now picture. The problem is that the agency often has no simple way to answer except "yes, for free" or an awkward argument.

Fixing scope creep therefore has two parts: a scope written so it can be checked, and a process for changes that feels normal to the client rather than like a penalty.

Write scope lines that can be checked

A scope line is good when both sides could look at the delivered work and agree whether it was done. "Modern, responsive website" fails that test. "Up to eight pages from the agreed sitemap, built for mobile and desktop, with one contact form sending to one email address" passes it.

Count things: pages, templates, screens, user roles, integrations, languages.
Name the inputs: who writes the content, who supplies the photos, which existing data is imported.
Name the outputs: what the client receives, in which format, and where.
Avoid adjectives that cannot be measured, such as "modern", "complete" or "advanced".

Add a "not included" list

Just as important as what is in the scope is what is not. Write a short list of the things clients often assume are included: content writing, translation, photography, data entry, paid advertising, third-party licences and subscriptions, ongoing maintenance after launch. An exclusion in writing at the start is a simple reminder later; an exclusion discovered mid-project is a dispute.

Anything not written in the scope is not in the scope. Say it at the start, kindly, so you never have to say it in anger.

Revision rounds, defined

Revisions are part of the work, and clients should feel free to use them. Fix how many rounds each stage includes, usually two, and say what a round is: one set of consolidated feedback on a deliverable, answered by one updated version.

Then draw the line between a revision and a change. Adjusting a colour, rewording a heading or moving a section on an approved page is a revision. Adding a page, a feature, a language or a new user role is a change, whatever stage it arrives at. Ask the client to name one person who collects feedback and sends it in one go; scattered comments from five people are how two rounds become ten.

A change request flow

When something new comes up, run it through the same four steps every time, and make sure the client sees each one:

Describe: write the change in a few lines, in the client's words if possible, and confirm you have understood it.
Price: give a fixed price for the change, based on your packages or your rate, and say how it will be invoiced.
New date: say how many days the change adds and which milestone moves.
Approve: the client approves the description, the price and the new date before any work starts.

The last step is the one that matters most. Work started before approval is work the client has not agreed to pay for, and it is the most common source of end-of-project disputes.

Log the small things too

Some changes are small enough that you are happy to do them without charge. That is fine, and often good for the relationship. Log them anyway, as a change marked "no charge". The client sees the goodwill, and if the small requests pile up, you have a record that makes the next conversation easy.

Saying yes the fair way

The aim is not to refuse more often. It is to say yes in a way that keeps scope, price and date connected. A few phrases help:

"Good idea. It is outside the current scope, so I will send you a short change request with the price and the new date."
"We can add it now and move launch by a week, or keep the date and do it straight after launch."
"If we swap it for the blog page, it fits in the current scope at no extra cost."

Offering a choice, including the choice to swap something out, puts the client in control of the trade-off instead of asking them to accept a cost.

When the client pushes back

Sometimes a client will say the change was always meant to be included. Go back to the written scope together, calmly, and read the relevant lines. If the scope is genuinely ambiguous, that is partly the agency's responsibility: consider sharing the cost, and rewrite that kind of line for future projects. If the scope is clear, the change request stands, and most clients accept it once they see it in writing.

Keep it all where the project lives

Change requests lose their value when they live in email threads and chat messages. Keep them in the same place as the project: the description, the price, the approval, the new date and, once done, the task that delivered it. Anyone on the team, and the client, should be able to see what was added and why the date moved.

How we handle changes at Qafza

Every Qafza proposal lists the scope, two revision rounds per stage and what is not included. When a client asks for something new, it goes through a change request in Qafza OS: the client describes it, we send the price and the extra days, and nothing starts until the client approves. The approved change becomes a task the client can follow, the deadline moves by the agreed days and the price is added to the next invoice. We commit to scope, dates and quality, and we keep both sides' agreements in writing.