The Client Who Wants 'Just One Small Change' for Free: How to Handle It Every Time

There's a specific message every freelance video editor has received at least once, and probably closer to fifty times if you've been doing this for more than a year, and it usually shows up right after you've delivered a final cut and marked the project closed in your head. It reads something like "hey this looks great, love it, can you just swap out that one clip around the 40 second mark, shouldn't take long right?" and there it is, the small change, the one that's somehow never actually small, and the one that arrives with just enough charm and just enough confidence that saying no feels awkward even though you both know this wasn't part of the original scope. We built a lot of what PlayPause does around exactly this moment, because we kept hearing from editors that the free small change wasn't really about one clip swap, it was about margin disappearing five minutes at a time across every single project they ran.

Why "Small" Almost Never Means Small

Here's the thing about a "quick" clip swap: it's rarely just the swap. Once you're back in the project file, you're re-syncing audio, you're checking whether the new clip changes the pacing of the cut around it, you're re-exporting, re-uploading, and then waiting to see if the client is actually happy with round two or if this opens the door to round three. What looks like a two-minute favor from the client's side is routinely a twenty to forty minute task on your side once you count reopening the project, making the edit, and handling the export and delivery again, and that math almost never gets communicated because the client genuinely doesn't know what happens on your end of the software.

Picture a typical Thursday: you've closed out three projects this week, you're finally caught up, and then two different "quick" requests land within an hour of each other from two different clients. Neither one feels like a big deal in isolation, so you say yes to both without thinking twice, and by the time you've reopened both project files, made the changes, re-exported, and delivered, you've quietly lost most of an hour you didn't budget for anywhere. Multiply that by even a couple of these a week, every week, across a full year of freelancing, and you start to see why editors who don't name this pattern out loud end up wondering where all their margin went despite staying busy the entire time.

Break the twenty-five to forty minutes down and it stops feeling abstract. Opening a Premiere Pro project that's been closed for a week and letting media relink usually eats three to five minutes on its own. Finding the right sequence and the right clip, then actually making the swap, is maybe five to eight minutes if nothing else shifted, but it rarely stays that clean, because pulling one clip out changes the cut point next to it and you end up nudging audio or a transition to match. Re-exporting at delivery quality is another five to ten minutes depending on length and your machine, and then uploading to whatever platform you deliver through and writing the "here's the updated version" message is another five. None of those individual steps sounds like much, which is exactly why clients underestimate the whole chain, they're only ever seeing the request, never the six or seven small tasks it actually triggers on your end.

Where This Habit Actually Comes From

Scope creep on small changes isn't usually malicious, and it's worth saying that plainly because it changes how you respond to it. Most clients aren't trying to get free labor out of you, they just genuinely don't experience editing as a series of discrete, billable steps, they experience it as "the video isn't quite right yet," and from their side a small ask feels small because they're not the one opening Premiere. The problem isn't the client's intent, it's that most freelance editors never set up a system that makes the boundary visible in the first place, so every request defaults to feeling like a favor rather than a line item.

The Four-Part Response Framework We Recommend

The framework works because it never puts you in the position of arguing in the moment. If you've already told a client up front that your project includes two rounds of revisions and this is round three, you're not making a judgment call under pressure, you're just pointing at something you both agreed to earlier. This is exactly why a documented revision trail matters so much, and it's a big part of why we built PlayPause around the Approval Workflow concept rather than treating every note as equal, because a note inside round one of an agreed scope and a request that shows up two weeks after final delivery are fundamentally different things, even if they arrive with the same casual tone.

Scripts You Can Actually Send

For the client who's genuinely still inside their revision allowance, the response is easy, you just confirm it and move on. The harder one is the client who's outside scope, and the trick there is to keep it short and non-defensive: something like "happy to make that change, this one falls outside the two revision rounds we scoped for this project, so it'll be a quick add-on at [your rate], want me to go ahead?" Notice that script doesn't apologize for having a boundary and it doesn't over-explain either, it just states the fact and hands the decision back to the client, which almost always resolves cleanly because most clients respect a number more than they respect a vague "well, technically..."

Setting the Expectation Before the First Request Ever Lands

The scripts above handle the moment a small-change request actually arrives, but the easier version of this problem is preventing the ambiguity in the first place, back at intake, before a single frame has been cut. If your kickoff process already states plainly that the project includes two revision rounds and defines what counts as one, a client asking for "just one small change" three weeks after delivery already knows, at least in theory, that they're outside what was agreed, which makes your response feel like a fact you're stating rather than a boundary you're inventing on the spot. This is a big part of why we point editors toward the client onboarding checklist that prevents scope creep, because the checklist itself becomes the thing doing the explaining later, not you. An editor who sets this expectation at intake finds that maybe one client in ten still tests it, versus an editor with no documented policy, who ends up litigating scope on nearly every project because nothing was ever written down for either side to point back to.

The Repeat Offenders Are Easier to Spot Than You Think

If you've been freelancing for a while, you've probably noticed that the "just one small change" request doesn't come from every client equally, it clusters around a handful of specific ones, and once you start actually tracking it, the pattern becomes obvious fast. We've talked to editors who assumed the free-change problem was spread evenly across their client list, and then the moment they logged every request for a month, discovered that two clients out of six were responsible for almost all of it. That's useful information, because it changes the conversation from "how do I say no to everyone" into "how do I set clearer expectations with these two specific people," which is a much smaller and more solvable problem.

• Log every unscoped request as it comes in, even the ones you say yes to for free
• Note which clients generate repeat "small change" asks versus one-off ones
• Bring the pattern into your next scope conversation with that specific client, not the whole roster
• Adjust the included-revisions language in future contracts with repeat offenders specifically

This is also where a documented history pays for itself in a completely different way than just protecting a single invoice, because after a month or two you have real data on which client relationships need a scope conversation and which ones are genuinely fine as they are, and that's a far more useful signal than going on gut feeling or, worse, on how annoyed you happened to feel on any given Tuesday.

How Having Everything Timecoded Changes the Conversation

One thing that quietly makes this whole framework easier is having every round of feedback logged with timestamps in one place instead of scattered across texts and emails, because "this is round three" is a much easier thing to say when you can literally scroll up and show it. This is one of the reasons editors move their client feedback into a proper Video Feedback system instead of relying on screenshots and DMs, the Timecoded comment history basically becomes your paper trail without you having to keep a separate log of who asked for what and when. If pricing structure itself is the part you're still figuring out, we go deeper on that in our breakdown of flat fee versus hourly pricing for revision rounds, which pairs well with this framework since scope and pricing really are the same conversation wearing two different hats.

When Saying Yes for Free Actually Makes Sense

None of this means every unscoped request deserves a quote. If a client has been reliable, pays on time, sends you repeat work, and asks for something that genuinely takes ninety seconds, like swapping a logo file or fixing a typo in a lower third, eating that cost is often the right relationship move and honestly the cost of doing business with good clients. The distinction we'd draw is between a true ninety-second fix and the "just one small change" that's actually a re-edit wearing a small costume, and the freelance editors who protect their time best are the ones who can tell those two apart quickly instead of treating every request with the same amount of guilt or the same automatic yes. The Motion Picture Editors Guild has made similar points about how undefined scope on professional creative work tends to erode rates industry-wide over time, not just on any one project, which is exactly the dynamic a clear revision framework is designed to prevent.

Protect Your Margin Without Damaging the Relationship

The goal here was never to make you less generous with clients you like, it's to give you a repeatable, low-drama way to tell the difference between a favor and a scope change before your margin quietly evaporates one small ask at a time. Keep every round of feedback timecoded and logged in one place, know exactly which revision round you're in for every active project, and the conversation about "just one small change" stops being awkward because the facts are already sitting right there in the thread. If tracking every open request across every client is still the missing piece, our guide to tracking revisions and deadlines across every client is the natural next read. See how PlayPause pricing works and start logging every client's revisions in one place so scope creep has nowhere left to hide.