The client asks for one more little thing. It is already the third week.

The order is almost ready. All that remains is to hand over the result, get approval, and finally close the tab that has become a member of the family.

Then the client writes: “Could you do one more little thing?”

You can. You are a decent person, after all. Then one more. Then “since the file is already open.” Then it turns out this little thing needs new copy, a different photo, and a quick call. The quick call lasts forty minutes because the little thing has brought along a colleague with their own vision.

The client may genuinely not realise how long it takes. And you may genuinely want to help. The problem starts when those two good intentions become a way of planning the work.

The way out starts with a simple question: what exactly is the person asking for now—fixing the agreed result, or adding something new?

Imagine a hypothetical studio preparing a menu for a café. They agreed on the list of items, two language versions, and a print-ready file.

The studio made a pricing mistake in the finished layout. Correcting it is part of bringing the agreed result up to standard. Sending a separate invoice for your own mistake would be a peculiar way to demonstrate a personal touch.

If the client brings a new menu section, asks for a third language, and wants separate screens for a TV, that is different. Those are results that were not part of the previous agreement.

There is a grey area between these cases. For example, the client changes an item’s name after approving the copy. Is that included in the revisions? It depends on what you agreed. If you did not define the limits, clarify them first instead of telling the person after the fact that they owe you.

Before replying, compare the request with the agreed brief, the terms of your cooperation, and the work already completed. In our article about turnkey services, we discussed why a package name does not explain its boundaries. Those boundaries are exactly what you need here.

“Sure, no problem” sounds friendly. But sometimes you have not even opened the file yet, so you do not know what the request involves.

There may be one button on the screen. Behind it are a different user flow, data checks, and message settings. The client sees the button because that is what they want. You need to see the work behind it.

That is why a useful first reply makes no promise to do the work:

This is not a refusal. It is a pause between a request and a commitment. It gives you room to estimate the task before you start. In the menu example, first we clarify: do they need a correction to the finished layout, or a new format for the screens?

It is especially important to pass this rule on to everyone who talks to the client. If a manager promises “we’ll finish it today” and the person doing the work hears about it an hour later, the boundaries of the order exist only in that person’s head.

In our hypothetical example, the studio planned four hours to adapt the finished menu. During the work, twelve extra requests came in, each taking about ten minutes.

That is another two hours. This does not include the time spent getting back into the task, finding the right version, and checking the result again. The figures here are invented for the example; measure them in your own work.

The problem stays hidden when each request is considered on its own. Ten minutes are easy to give away. Two hours are already competing with other paid work.

Start recording extra requests in one place: what was requested, when, whether the work was approved, and how long it took. You do not need a big system. A record visible to the people responsible, which lets you reconstruct what was agreed, is enough.

It is also important to record your own rework caused by mistakes separately from new requests. Otherwise, you can hide process problems behind a story about a “difficult client.”

When a new task appears, the client needs to know what can be done about it.

Back to the menu. If the TV screens are needed for the opening, you could add them to the current work and review the timeline. If the opening is tomorrow, you could first finish the approved print version and prepare the screens as a later stage. Sometimes the new material can replace a less important part—if both sides agree to the change.

Say which options are actually available. Do not promise to keep the original deadline only because it feels awkward to discuss moving it.

The template leaves fields to fill in. Add the amount and date after estimating the work, not instead of estimating it. You need to account for the team’s availability, dependencies, and time for review.

In its article on managing changes to project scope, PMI discusses changes alongside their impact on expectations, budget, schedule, and risk. For a small order, the principle is useful: explain the consequences first, then agree on the work. You can keep the approval process short and practical for your relationship.

Suppose our café chose the extra stage for the screens. Now the manager and owner send changes separately whenever they notice something in the layout. It is hard to know whether you have the full list. You close the task, reopen it, and gradually become the dispatcher of your own file.

Suggest putting the complete list together by an agreed time. For example: “Let’s collect the changes in one list. I’ll review them together and come back with an estimate.” This is especially useful when several people are reviewing the material.

But the batch needs to be concrete. “All changes by Friday” will not help if the client does not know who on their team should collect them. Agree on who sends the final list and confirms the decision.

Once the list is approved, save it with the result and date. It is easier to return to than sixteen voice messages. We have a separate article on chat agreements and keeping one order record.

Do not turn a “batch of revisions” into a way to delay an obvious mistake that needs to be fixed now. The goal is to gather requests, not to make the client wait until they have accumulated enough reasons to contact you.

It is an uncomfortable conversation, but it is better to have it calmly. Do not start with an invoice the client was not expecting. Explain what happened, show the additional scope, and return to the terms of your cooperation.

You could write:

This does not mean the earlier extra work is automatically free or automatically payable. Resolve that according to your agreement and the circumstances; if there is a dispute, handle it separately with an appropriate professional. The message sets a clear process for the next steps.

If unpaid additions have become routine, it is useful to look at the broader issue too: how to stop working for clients for free. Explain boundaries before the work begins, while they still sound like a process rather than a complaint.

For the next order, it is enough to agree on three things: what result you will deliver and how you will know it is ready; which revisions are included; and how you will approve additions that go beyond those limits.

Then give the team permission to say, “Let’s check first.” If every pause is treated as bad service, all the lists will remain decorative.

You can keep good service while talking about extra payment. Explain the task, offer options, and do what you agreed. That is much easier than quietly making changes for three weeks and suddenly hating the client in week four for requests you kept agreeing to yourself.

Open one active order today. Count how many extra requests you have already completed and how long they took. Then record the process for the next changes. One example may be enough to show the team where the workday is going.

the impact of changes on expectations, budget, and schedule. The everyday examples, message templates, and suggested workflow are an editorial adaptation for small businesses; they do not replace the terms you have agreed.