What do I do when a client keeps adding to the project?

Don't refuse and don't silently absorb it. Check the new request against the agreed scope, then treat it as a normal priced addition: acknowledge it, note it sits outside the confirmed scope, and offer to quote it as a separate item with its own cost and time.

How do I write a change order?

A change order states the new request, references the agreed scope it falls outside of, and gives the added cost and added time — then asks the client to approve before work continues. Keep it short and matter-of-fact.

How do I price extra work without seeming greedy?

Anchor to the agreement, not to the relationship. 'This sits outside what we confirmed, so it's a separate piece' frames it as fairness, not upselling. You quote it; the client decides.

ScopeLinq · Guide

"Can you also…": handling a client who keeps adding work

The hardest part of freelancing isn't the work — it's the request three weeks in that wasn't in the deal. Saying no feels adversarial; saying yes eats your margin. The way out is a third option: treat every new ask as a priced change against what you agreed.

Don't refuse. Don't absorb. Reframe.

A "can you also add a booking calendar?" isn't a fight and it isn't a favor — it's a change. The move is to check it against the scope you both confirmed, then respond as a professional handling a normal addition:

"Great — I can absolutely add a booking calendar. As we noted in the scope, that sits outside what we confirmed for this project, so it's perfect to handle as a separate piece. I'll put together a quick quote for it and we can lock in the timeline and cost."

Nothing defensive. You're not saying no. You're saying "yes, and here's how it works" — anchored to the agreement, not to goodwill.

The change-order pattern

A change order doesn't need to be a formal document. Three parts:

The request — restate what they asked for, plainly.
The reference — note the agreed line it falls outside of ("the original scope covers 5 pages; a booking system wasn't included").
The impact — added cost and added time, then: "approve this and I'll proceed."

Example: "Booking calendar — not in the original scope. Adds $200 and ~3 days. Reply 'approved' and I'll start it once the current milestone ships."

Why the agreement does the heavy lifting

All of this only works if there's a scope both sides actually confirmed. Without it, every request is a negotiation from zero. With it, you're just pointing at what you already agreed — which is why the confirmation step up front is the whole game.

Catch the "can you also…" automatically

ScopeLinq checks each new request against your confirmed scope, flags whether it's covered or new, and drafts the reply for you — priced, if you want. You bill it your way; ScopeLinq just hands you exactly what to send.

Try the free demo →

FAQ

What if the client says it was "always implied"?

This is exactly why a confirmed scope matters. If it's genuinely ambiguous, that's a conversation; if the scope named it as excluded, you point to the line you both agreed to.

Do small additions need a change order?

Not every tiny thing — but the moment additions start adding up, run them through the same "covered or new?" check so goodwill doesn't quietly become the baseline.