That's a change request. Every freelancer and agency deals with them. Very few handle them well.

Change requests are not the enemy. Clients change their minds, markets shift, and a project that looked simple in January looks different by March. The problem isn't that changes happen. The problem is that most of us absorb them silently and hope it works out. It doesn't.

What a change request actually is

A change request is any request that falls outside what you already agreed to do. New feature. Different design direction. A deadline moved up. A third round of revisions when the contract said two.

It's tempting to treat small asks as harmless. "It's just one extra page." But small asks stack up, and the cost isn't only the extra page. It's the context switching, the re-planning, and the quiet resentment that builds when you feel taken advantage of.

I've learned to treat every change, no matter how tiny, as something that needs a visible decision. Not because I'm difficult. Because invisible decisions are how good projects turn into bad ones.

Why freelancers ignore them

Freelancers are scared of saying no. It feels like biting the hand that feeds you. Early in my career I'd agree to almost anything because I thought pushing back would lose me the client.

Sometimes it did. But the clients I lost by pushing back were usually the ones who would have drained me anyway. The clients worth keeping understood that a change had a cost, and they respected me more when I said so plainly.

Agencies have the opposite problem. They have processes, sometimes too many. A change request becomes a form, a meeting, an estimate, and by the time everyone signs off the urgency is gone. Process protects margin but it can also kill the responsiveness that won small the client in the first place.

Put the scope in writing before you start

The single best thing you can do is define what's included clearly, in writing, before the work begins. Not a fifty page contract. A short scope document that lists what you'll deliver and, just as important, what you won't.

When a request comes in, you can point to the document. "That's outside the scope we agreed on page two." You're not being difficult. You're referring to a shared understanding you both signed.

Vague scopes are where the trouble starts. "Build a website" is not a scope. "Build a five page site with contact form, no CMS, two rounds of revisions" is. The more specific you are, the fewer arguments you'll have later, because there's less gray area to fight in.

Make the cost of change visible

When a client asks for something new, don't just say yes or no. Say what it costs.

"Adding the blog section means about three extra days and $600, and it pushes the launch by a week. Want to do it now or after launch?"

Now it's a real choice. The client can decide with full information. Most of the time they'll either approve it happily or drop it, because they didn't actually need it that badly. Either way you win. You either get paid for the work or you avoid doing free work.

The mistake is absorbing the cost yourself and hoping to make it up somewhere. You won't. And the client never learns that changes have a price, so they keep asking.

Use a simple change request template

You don't need software. A short email or a shared doc works. Each request should capture a few things:

What's being asked. Why. The impact on time and budget. The new total if approved. Who approved it.

I keep a running list in the project doc. Every approved change gets a line. When the client later says "I thought this was included," I show them the list. It ends most disputes in ten seconds.

Written records also protect you when the relationship sours. If a client refuses to pay for agreed changes, you have the paper trail. I've only needed it twice, but both times it saved me thousands.

Decide fast, or name the delay

Some change requests sit in limbo because nobody wants to make a call. That limbo is expensive. The developer is blocked, the designer is waiting, and the clock runs.

Set a rule: every request gets a response within one business day, even if the response is "I need to check with the team and will get back to you by Thursday." A slow maybe costs more than a fast no.

For agencies, this means giving someone the authority to approve small changes on the spot. If every tweak needs the account manager and the project lead and the developer, you'll frustrate clients who expect the speed of a freelancer.

Watch for the scope creep that doesn't look like a request

Not all creep arrives as a clear ask. Sometimes it's "while you're in there, can you also..." Sometimes it's a casual comment in a call that turns into an expectation. Sometimes the client just assumes the first thing you built was a draft and you'll redo it.

These are change requests too. The fix is to catch them in the moment. "That sounds like a new task, let me add it to the change list and price it out." Said lightly, with a smile, it keeps things friendly and honest at the same time.

The freelancers who burn out are usually the ones who let these slide. They tell themselves it's just one small thing, every single time, until the project is three times the size and they were paid for one.

Bill for changes the right way

Two models work. The first is a formal change order: new work, new price, signed before you start. Good for big additions. The second is a buffer: you quote with, say, ten percent slack and treat small changes as absorbed, but anything past the buffer gets billed.

I prefer a hybrid. Tiny tweaks inside the buffer are free, because arguing over an hour of work strains the relationship more than it's worth. Anything real gets a change order. Clients respect this because it's fair and predictable.

What doesn't work is retroactively arguing about what was included. Bill as you go, or get approval as you go. Surprise invoices at the end ruin trust faster than almost anything else.

When to say no

You can decline a change. Not often, but sometimes. Say the request breaks the original goal, or the timeline is impossible, or it would mean cutting something more important. A clear no with a reason beats a resentful yes every time.

"No, we can't add payments before launch, the integration alone is two weeks and we'd miss the date you care about. Let's ship the site first." That's a service to the client, not a refusal.

The trick is separating the request from the relationship. Most clients can hear no on the work without feeling rejected as a person, as long as you're straight with them and you're clearly on their side.

A short example

A design client asked for a fourth revision round after we'd agreed on two. Instead of groaning, I wrote back: "Two rounds were in scope, we're at two. A third round is about four hours, $350. A fourth would be another $350. Want both, or just the third?"

She picked the third, paid the $350 without a fuss, and we finished the next day. No argument, no free work, no hard feelings. That's what good change request management looks like in practice. It's not a system. It's a habit of making the tradeoff visible and letting the client choose.

Where to start

If you do nothing else, do this: write down what's included, write down every change as it comes, and tell the client what each change costs before you do it. That's most of the battle.

The freelancers and agencies that survive aren't the ones who never get change requests. They're the ones who handle them without surprise, without free labor, and without damaging the relationship. Get that right and the requests stop feeling like threats and start feeling like normal parts of the work, which is exactly what they are.