Retainer Scope Creep: A Request Policy for ‘Quick Ones’

Most retainers don’t break on day one. They break around month three, when the “quick ones” start to outnumber the planned work.

A quick one is a request that is too small to quote, too frequent to ignore, and too vague to refuse. “Can you also look at this?” “Can we move that to Monday?” “Quick favour, can you jump on a call with the new vendor?” Each one takes twenty minutes to do and an hour to recover from, and none of them appears in the contract.

The standard advice is to write a tighter retainer agreement, and you should. But a contract only defines what is covered. It doesn’t decide what happens on a Tuesday afternoon when a client sends a one-line message and expects an answer. That takes an operating policy.

This guide gives you a six-part request policy for retainer-based businesses: fractional executives, social media managers, consultants, editors, bookkeepers and small studios. It works whether you run it from a spreadsheet or a purpose-built tool, and each part closes one specific leak.

Why Retainers Leak (And Why the Contract Alone Doesn’t Fix It)

Most retainer problems trace back to an expectation gap. You sold defined capacity: a number of days, a set of deliverables, a monthly package. The client bought availability: someone who handles things as they come up. Both readings of “monthly retainer” are reasonable, so the gap doesn’t close on its own.

Three leaks keep it open:

• No shared definition of a request. If a request can be anything from a typo fix to a quarterly strategy, you will either absorb everything or argue about everything.
• Too many doors. Requests arrive by email, Slack, WhatsApp, voice notes and calls. Some get lost, some get answered twice, and none can be counted when you need to show a client how much you actually did.
• Nothing limits what is in flight. Without a visible cap, every new ask starts immediately, and your plan loses to whoever messaged last.

The six parts below map onto those three leaks. Curious what the leak costs you? Try the scope creep calculator.

1. Define What a “Request” Is

Start by giving the word a precise meaning. A workable definition:

A request is one outcome, with a short description of what is needed and why, sent through the agreed channel.

“Review the Q3 campaign brief” is a request. “Help with marketing” is a conversation. “Can you also fix the footer, update the pricing page and rewrite the about section?” is three requests.

Two rules make the definition stick:

• One outcome per request. Bundles get split on intake. That is what makes it possible to order work and to approve it piece by piece later.
• Enough context to start. A title, a sentence or two on why it matters, and any files or links. If the request can’t be understood without a call, it isn’t ready yet.

Then size requests. You don’t need precise estimates, just three rough buckets expressed in your own time:

• Small: under an hour. A copy tweak, a quick review, a short written answer.
• Standard: a few hours. A first draft, a report, a reworked page.
• Large: anything bigger. This is a project, and it is quoted separately or scheduled across weeks.

What counts as small changes by role, so write your own examples:

• Fractional CMO: small is a pricing page sanity check, standard is a campaign brief, large is a full positioning rework.
• Social media manager: small is a caption swap, standard is a week of posts, large is a launch campaign.
• Bookkeeper: small is categorising a handful of transactions, standard is a month-end reconciliation, large is cleaning up a backlog.

2. Decide What the Retainer Covers

Once requests have a shape, sort them into three lists and put all three in writing.

• Included: work that happens inside the retainer at normal pace. Name specific deliverables rather than categories. “Up to eight posts a month” beats “social media support.”
• Included, but queued: small and standard requests beyond your planned work. They are covered, but they wait their turn behind what is already underway.
• Out of scope: large requests, new channels, new products, anything that needs a different skill set. These get a short quote instead of being squeezed in.

The middle list is the one most retainers lack, and it is where most of the margin disappears. Without it, every extra request is either free and immediate or a confrontation. With it, there is an honest third answer: yes, and here is where it sits in the queue.

Write one more distinction into this section: response time is not turnaround time. You can promise to acknowledge every request within one business day without promising to finish it that fast. Clients usually care most about knowing the request landed. Separating the two lets you be responsive without being on call.

3. Open One Door

Pick a single place where requests live, and make it the only place they count. Everything else is a conversation, not a request.

This is the part clients resist most, so it helps to be clear about what it buys them. One door means nothing gets buried in a thread, nothing is answered twice, and they can see the state of everything they have asked for without writing to you. It also gives you something you rarely have on a retainer: an accurate record of how much was requested and what was done.

You will still get requests in the old channels, especially in the first few weeks. Don’t ignore them and don’t quietly do the work. Redirect them kindly:

Happy to take that on. Can you drop it into your request page so it lands in your queue? Here’s the link.

That one sentence, repeated every time, changes behaviour faster than any announcement. The first reply costs you thirty seconds. Skipping it costs you the system.

If your clients are busy and unlikely to learn another tool, the door has to be easy to walk through. A private link that opens straight to their queue, with no account to create and no password to forget, removes the most common reason clients drift back to email. We cover why in our guide to asynchronous client approvals.

4. Limit Work in Progress

This is the part that most people skip, and it does the most work.

Borrowed from kanban, a work-in-progress limit caps how many items can be active at once. For a retainer, apply it per client: only a set number of that client’s requests can be in progress at a time, and everything else waits in an ordered queue.

Why it matters on a retainer:

• Things finish. Four requests started on Monday tend to finish late on Friday, all together. One or two at a time means the first lands early in the week.
• Your plan survives. The scheduled work isn’t pushed aside by the newest message.
• The queue becomes the answer to “where are we on that?” When a client can see their request is second in line behind one that is in progress, they stop asking.

How to pick the number? Work backwards from what the client bought. For example, suppose a client buys about ten hours a month and a standard request takes two to three hours. That is roughly four standard requests in a month. Running all four at once means they all finish near the end. Running one or two at a time means they finish in sequence. If you’re a solo operator, start at one or two active items per client and adjust after a month.

The limit only works if it is visible. A cap that lives in your head is just an excuse. A cap the client can see is a shared rule.

5. Swap, Don’t Add

Even with a limit, urgent requests will arrive. The policy for them is simple: the queue is full, so something has to move.

Here is how that sounds in practice:

We can fit that in. Right now the queue is the campaign brief, the pricing page review and the messaging refresh. Which one should it replace, or would you like me to start it after the brief?

This does three things at once. It says yes. It makes the cost visible. And it hands the prioritisation decision back to the client, who is the only person who knows what actually matters most this week.

Most of the time, the answer is “oh, that can wait.” That isn’t a failure; it is the system working. When it isn’t, you have a clear, documented reason why the other work moved.

When there is genuinely more work than the retainer holds, you have three honest options, and you should offer them in this order:

1. Swap: the new request replaces something already queued.
2. Defer: the new request starts next month, ahead of nothing, behind everything.
3. Top up: the client buys extra capacity for this month at an agreed rate.

Put the top-up rate in the contract so it never has to be negotiated under pressure.

6. End Every Request With a Decision

A request isn’t finished when you deliver it. It’s finished when the client says it is.

The most expensive phrase on a retainer is “looks good, but could we tweak a few things?” It sounds like approval, behaves like a new brief, and can’t be found three weeks later when you need to show what was agreed. Fix this with three habits:

• Review each deliverable on its own. One piece, one note on what you need decided, one clear way to approve or ask for changes. Bundling five deliverables into one “can you review all of this?” email guarantees a vague answer.
• Ask for changes in writing, tied to the piece. “Request changes” should come with a note, so feedback stays attached to the thing it is about.
• Treat changes after approval as a new request. Once something is approved, further changes go to the back of the queue like any other ask. State this in your policy so it never feels personal.

If you also set a number of revision rounds per deliverable, say so in the same place. Two or three rounds is common, but choose the number that matches how you actually work.

Put the Policy in Your Contract

The policy lives in practice, but the contract should back it up. Add or check these clauses:

• Definition of a request: one outcome, sent through the agreed channel.
• Intake channel: requests made anywhere else are conversations, not requests.
• Capacity: how many requests can be in progress at once, and how the rest are ordered.
• Response time versus turnaround: what you commit to acknowledging, and what you don’t.
• Out-of-scope work: how it is quoted, and who approves the quote.
• Top-up rate: the price of extra capacity within a month.
• Revisions: how many rounds, and that approved work is closed.
• Unused capacity: whether it rolls over, expires, or is credited.

This is general guidance, not legal advice. Have a lawyer review your final agreement, especially around termination, liability and payment terms.

Running the Policy: Spreadsheet or Tool?

You can run all six parts with a shared spreadsheet, a short email explaining the rules, and a lot of discipline. If you have two or three clients, that may be all you need.

It tends to break down in the same places: clients forget the sheet exists, request details end up in email anyway, and approvals live in reply threads. The common thread is that you are the one enforcing the system, which is the job you were trying to stop doing.

A purpose-built queue takes that enforcement out of your hands. Each client gets a private page where they send requests, see what is queued and in progress, and approve finished work. You set the order. Anything beyond the in-progress cap waits in a line the client can see.

Rolling It Out to Existing Clients

Introducing a policy to clients you already have is mostly a framing exercise. You aren’t adding restrictions. You are making their requests easier to track and faster to finish.

Pick a start date, ideally the beginning of a month or a renewal, and send a short note:

Subject: A small change to how we handle requests

Hi [Name], to keep your work moving in the right order, I’m moving all requests to one private page: [link]. Anything you send there goes into your queue, and you can see what’s in progress and what’s next at any time. No login needed. From [date], I’ll ask that new requests go there so nothing gets lost. If something is urgent, tell me and I’ll show you what it would replace.

Expect a testing period. In the first few weeks, some clients will send requests the old way to see what happens. That is normal. Use the redirect line from part three, every time, and the habit forms quickly.

See how this looks for different kinds of work on our pages for fractional CMOs and social media managers, or browse all of them.

Common Mistakes

• Enforcing it selectively. If you absorb the third quick one in silence, you have set the price for the fourth. Apply the policy the first time, kindly, rather than the fifth time, resentfully.
• Saying no instead of “next.” The queue exists so you rarely have to refuse. “Yes, after these two” is a better answer than “no.”
• Letting urgent skip the line. If urgent work bypasses the queue, everything becomes urgent. Make urgent mean “it replaces something,” and let the client choose what.
• Hiding the policy in the contract. If the rules are only on page six of the agreement, you will be the only person who remembers them. Put the working version where the client sees it every day.
• Too many categories. Three sizes and three coverage lists are enough. A policy that needs a flowchart won’t survive a busy week.

Frequently Asked Questions

How many requests should a retainer include?

There is no universal number. Work backwards from the capacity you sold: divide the monthly hours or days by the typical time for a standard request, then set the in-progress limit lower than that so work finishes in sequence. Review it after the first month using what actually happened.

Should I charge for small requests?

Not individually. Charging per small request creates the procurement friction that makes clients avoid asking. Cover small requests inside the retainer, queue them, and use the top-up option when volume exceeds capacity.

What if a client insists everything is urgent?

Show the queue and ask what the new request should replace. If everything really is urgent, the real issue is capacity, and that is a conversation about a larger retainer or a top-up, not about working faster for free.

Do I need software to run this?

No. A spreadsheet and clear rules can work for a few clients. Software helps when clients stop using the sheet, when approvals get lost in email, or when you are tired of enforcing the process yourself.

How do I handle clients who ignore the request page?

Redirect every off-channel request with the same short reply, with the link, and nothing else. Don’t complete work from DMs “just this once.” The first few weeks decide whether the system sticks.

Final Thoughts

You can’t wish away quick ones, and you shouldn’t want to. They are often a sign that the client trusts you. The goal of a request policy isn’t to turn them down. It is to give them a place to go, an order to be done in, and a clear moment when they are finished.

Define what a request is. Decide what the retainer covers. Open one door. Limit what is in progress. Swap instead of adding. End every request with a decision. Do those six things and the retainer stops depending on your willpower and starts running on structure.