Handling change requests

A change request is a "yes", not a "no"

The instinct when a client asks for something new is to feel it as a threat to the budget. Flip it. A change request is a client asking to spend more money with you. Handled well, it's extra revenue and a happier client; handled badly, it's unpaid work and resentment. The process is what decides which.

The goal isn't to block change. It's to make every change a visible, priced, agreed decision, before the work happens, not after. That protects your margin and the relationship.

The four-step process

Keep it simple enough that you'll actually use it every time.

1. 1Capture. Get the request in writing, even if it started as a hallway comment or a call. A

one-line note against the relevant part of the scope is enough. Verbal requests are the ones that turn into "but I asked for that weeks ago".

1. 1Price. Estimate the change honestly against the agreed scope, hours, cost and any timeline

impact. Don't forget the knock-on effects; a "small" change to one section often ripples.

1. 1Approve. Send the client the change and its price, and get an explicit yes before any work

starts. No approval, no work. This one rule prevents almost all disputes.

1. 1Add. Once approved, fold the change into the scope and the total so the document stays the

single source of truth. The scope should always reflect what you're actually building.

Word a change so it can't be misread

A change request doesn't need to be a legal document, it needs to be clear. Capture what's changing, why, what it costs, and its effect on the timeline.

Change request CR-03, Add booking calendar Change: add a real-time booking calendar to the Services page, integrated with the client's scheduling tool. Reason: requested by client after design sign-off; not in the original scope. Cost: £1,200 (approx. 10 hours). Timeline: adds 4 working days. Approval: proceed on written client approval.

Numbered change requests give you a clean history, "as agreed in CR-03" is un-arguable in a way that "as we discussed" never is.

Distinguish a change from a revision

Not everything is a change request. A tweak within the agreed direction is a revision, covered by your revision limits. A genuinely new page, feature or a reversal of something already signed off is a change. Naming which one you're dealing with, out loud, stops the grey-area drift that becomes scope creep.

Say yes without losing money

The best change process makes "yes" the easy answer, because the price is transparent and agreed up front. When a client knows exactly what a new idea costs, they can decide clearly, and often they say yes, because they've seen the value. You're not the obstacle; the process is neutral, and you're the person helping them get what they want.

Keeping change requests attached to the live scope matters here. When a change is priced, approved and folded straight into the document, rather than tracked in a separate email thread, the scope, the total and the delivery plan all stay in sync. ScopeDeck keeps amendments and sign-off on the same document through its version history, so what was agreed, and when, is never in doubt.