How to Limit Client Requests Per Month Without Souring the Relationship

You run client work and want a monthly request limit that doesn't start an argument. This guide is for agencies, studios, consultancies, dev shops, productized services and freelancers. You'll finish with a written allowance policy, the exact wording for your agreement, and a plan for the overflow. It takes about 60 minutes and is beginner level.

Before you start

To limit client requests per month, count what a typical month takes, set a fixed allowance per client, write it into the agreement, decide whether extras trigger a warning or a queue, and tell the client up front. A monthly allowance works like a fixed-window quota: a set number of requests per period that resets on a set date. Merge describes fixed-window limits over a day or a month, and that is the same idea we're borrowing for client work.

Here is what to gather first:

• Three months of request history per client. Without real data the number is a guess.
• A written definition of one request. You can't count what you haven't defined.
• Your current agreements or retainer terms. You'll edit them in Step 3.
• Rough hours or cost per request. This tells you what an extra costs.
• Someone to send the up-front message. Decide now whether it's you, a producer or a project manager.

A request limit isn't a way to say no. It's a way to say yes with a price tag and a date. Clients accept limits they hear about on day one and resent the ones they hit by surprise.

Step 1: Count what a typical month takes

An allowance set without data is one you'll regret, or one the client will resent. Spend your first 25 minutes on the numbers.

Define what counts as one request

A request is one clear ask that leads to one deliverable. "Resize the banner for three platforms" is one request if you'd ship it as one piece. "Redo the whole campaign" is a project. Write your definition in one sentence and keep it.

Pull three months of numbers

For each client, go back through the last three months and list every ask. Check email, chat, DMs and your tracker. If asks come in through requests arriving in different channels, you'll need to dig in all of them. Good client request management means one place where every ask ends up, but if you don't have that yet, a spreadsheet works for this hour.

For each request, note:

1. The date it arrived
2. How many hours it took
3. Whether it was inside the agreed scope or a true extra

Find the average and the peak

Add up requests per month, then find the average and the busiest month. Capping work over a fixed period is the standard approach: Speakeasy's example is a fixed window such as 100 requests per minute, and the same logic works with a month as the window.

Example: A design studio checks one client's history. The client averaged 9 requests a month, with one 14-request month right before a product launch. That's the range you'll work from.

The usual mistake: counting only what's in the tracker. Requests that came through DMs and email are real work, so count them too.

Step 2: Set an allowance for each client

An allowance should belong to one client, the same way usage limits are tracked against an identifier. Gravitee notes that rate limiting counts requests by identifiers like API keys or user IDs. For you, the identifier is the client.

1. Start near the average, not the peak. If you set the number at the busiest month, you give away capacity most months. If a launch month needs more, that's what extras are for.
2. Check the price covers it. Run your hours per request through the retainer calculator and see if the retainer pays for the allowance.
3. Set a number per client. A big client and a small one shouldn't share a number.
4. Pick a reset date. The calendar month is simplest. Everyone knows when it resets.
5. Decide what rolls over. Usually nothing. Unused requests expire on the reset date, which keeps the count simple.

Example: A mid-sized retainer gets 8 requests a month. A larger one that averages 13 gets 15. Neither client is guessing what they have.

If you run a design subscription with a request queue, the same rule applies, just with a number that fits the plan. And if revisions are your sore spot, set a separate cap, as in our guide to how to limit design revisions without souring the relationship.

The usual mistake: one number for every client. It's easy to write, and it's unfair to both ends of your client list.

Step 3: Write the allowance into the agreement

A policy that isn't in writing is a favour you can't enforce. Put it in the agreement or retainer terms so both sides can point to the same page.

Keep the monthly allowance separate from any short-term limits, like response times. Moesif draws this same line: rate limits cap requests over short periods like a second or a minute, while quotas cover longer periods. Your monthly allowance is the quota. Your "we reply within one business day" promise is a different thing, so give each its own sentence.

The clause should cover five things:

1. The number
2. What counts as a request
3. The reset date
4. Rollover
5. What happens past the limit

Sample wording to paste

Request allowance. Your plan includes 8 requests per calendar month. A request is one clear ask that leads to one deliverable. The count resets on the first day of each month. Unused requests don't roll over. Extra requests are quoted separately and start once you approve the estimate.

Edit the number and the definition to match your own. If you chose to queue extras (Step 4), swap the last sentence for "Extra requests join the queue for next month unless you approve an estimate."

The usual mistake: vague words. "Reasonable number of requests" and "small tweaks" mean something different to you and the client. Use numbers and a plain definition.

Step 4: Decide what happens past the limit

The overflow is where relationships get tested, so decide before it happens. You have two good options. Pick one per client and write it down.

Warn: keep going, with an estimate

You keep working, but you flag the client the moment they hit the limit and send the extra work as an estimate. They approve it in one click, and you start. A one-click approval keeps this fast, so the client doesn't have to dig through email threads to say yes.

Example: At request 9, the client gets a friendly note: "That's number 9 of 8 this month. Here's the price and date for this one. Approve and we'll start tomorrow."

Queue: hold extras for later

Extra requests wait until next month, or until the client approves an estimate. This works for clients who push the edges of the plan. One practitioner on the r/ExperiencedDevs forum suggests a queue with limited concurrency and retries when a limit is hit. That's an engineer's opinion about software, not a rule, but the instinct carries over: hold the overflow instead of dropping it.

There's another lesson in the engineering world. One developer on Stack Overflow describes a provider getting annoyed by excess requests, contacting them and possibly banning them. It's a single anecdote, but it makes the point: ignoring limits has consequences, whichever side of the limit you're on.

Choose by client

Warn for strategic clients you want to keep sweet. Queue for the ones who push. Either way, the rule is the same for that client every month.

The usual mistake: saying yes silently, just once. That one quiet exception becomes the new normal. In Dora, you set a monthly allowance per client and choose whether extra requests open with a warning or queue for next month. Clients see their count when they make a request and are told when one is over, and your team sees it flagged on the request, so you aren't the one writing the awkward note.

Step 5: Tell the client up front

Clients take limits well when they hear them first. This step takes about ten minutes, and it does the most to protect the relationship.

1. Say it in the proposal. One line: how many requests the plan includes.
2. Say it again at kickoff. Walk through the definition of a request with an example.
3. Put it in the welcome message. Add it to your client onboarding checklist so it's never skipped.
4. Show the running count. A client portal is the natural place for the client to see where they stand. In Dora, it reads "3 of 8 requests used" with a bar, and each month's recap says how much of the allowance was used. If you're doing it by hand, put the count in your weekly update so it's never a surprise.

Don't hide the limit and enforce it quietly when a client crosses it. A visible number feels fair. A surprise "no" feels like a bait and switch, and that's what damages retainers.

Sample message

Each month includes 8 requests. We'll tell you at 6 so there are no surprises, and extras are a quick estimate away.

The usual mistake: announcing the limit only when the client hits it. By then it sounds like a penalty.

Common mistakes

These are the problems that come up most, with the fix for each.

• Guessing the number. Go back to Step 1 and pull real data, even if it takes an extra hour.
• Counting only some channels. Check email, chat and DMs, not just the tracker.
• Using the same limit for everyone. Set the allowance per client.
• Making silent exceptions. If you bend the rule, say so and offer the estimate anyway. Otherwise the exception becomes the policy.
• Keeping the policy in your head. Put it in the agreement, with the sample wording from Step 3.
• Leaving the monthly count invisible. Share the count at the halfway point so the client isn't surprised. Per-client pricing helps here too: with Dora, your first client is free forever and each client after that is $10 a month, so tracking allowances per client doesn't add seat costs.

Checklist

1. Define one request in a sentence, then count three months of requests per client across every channel.
2. Set a monthly allowance per client near the average, with a reset date and a rollover rule.
3. Write the number, the definition, the reset date, rollover and the overflow rule into the agreement.
4. Choose warn or queue for each client, and decide how extras become approved estimates.
5. Tell the client in the proposal, at kickoff and in the welcome message, and share the running count.

Or let Dora track each client's allowance, warn or queue the overflow and send extras as one-click estimates: try Dora free, your first client is free, forever.

Frequently asked questions

What is a request allowance?

A request allowance is a set number of requests a client can make per month under their plan. It resets on a fixed date, usually the first of the month. It gives both sides a clear number to plan around.

How do I say no to extra requests without upsetting the client?

Point to the allowance you both agreed to, then offer a way forward: a quick estimate they can approve, or a slot next month. Keep the tone friendly and specific, with a price and a date. If they heard the limit on day one, the conversation is short.