Business · Agency Operations
Agency Retainer Models: Pricing Ongoing Work Without Burning Out
Retainer contracts promise stable revenue. In practice, they often create scope creep, pricing resentment, and capacity problems. Here is how to structure them so they actually work for both sides.
Anurag Verma
8 min read
Sponsored
The appeal of retainer contracts is obvious from the agency side: predictable monthly revenue, a client who is already sold on you, and work that compounds as you understand their business better. The reality is often a client who treats the retainer as an unlimited help desk, a monthly scope negotiation, and a relationship that slowly degrades because neither side is happy with the arrangement.
The problem is usually not the idea of retainers. It’s that most agencies structure them wrong.
The Three Retainer Models
Time-Based Retainers
The most common and most problematic structure. The client pays for a block of hours per month, and the agency delivers that many hours of work. Unused hours might roll over, or they might not.
The structural flaw: clients who aren’t fully utilizing their hours feel like they’re wasting money. They start inventing work to “use up the block” even when nothing needs doing. Clients who regularly exceed their block feel like they’re always being billed extra. The negotiation about hours consumed versus hours available becomes a monthly tax on the relationship.
Time-based retainers work when the work is genuinely variable and the client needs a predictable maximum cost for budgeting. If your agency does something like ongoing content production where the workload fluctuates, billing by the hour with a monthly cap is defensible. For most development or design work, it creates more friction than it solves.
Deliverable-Based Retainers
The client pays a fixed monthly fee for a defined set of deliverables: two design refreshes per month, one sprint of development work, monthly performance reporting, quarterly strategy sessions. The work is specific and scoped upfront.
This model is cleaner because the conversation shifts from “how many hours did we use” to “did we deliver what we said we would.” Both sides know what they’re getting. Scope creep is visible. When the client asks for something outside the defined deliverables, the answer is “that’s a separate engagement” or “we can swap it for one of the planned items this month.”
The risk: deliverables can vary in effort. A “design refresh” for a small component is different from one for the homepage. Define what counts carefully, or build in an effort cap per deliverable.
Capacity Retainers
The most honest model for ongoing development work. You’re selling a fraction of a developer’s (or team’s) time and attention for the month. The client gets first call on that capacity. What gets done with it is planned each month based on current priorities.
Standard example:
20 hours / month at $X/hr = $Y/month
Work is planned at the start of each month
Unused capacity does not roll over
The client can redirect the work at any time within the month
This works because it matches how teams actually function. A developer working on a retainer client isn’t doing exactly the same tasks every month — priorities shift, bugs emerge, new features become urgent. A capacity retainer gives the client flexibility while giving the agency clarity on what they’ve committed.
The pricing conversation becomes simpler: you’re not selling a specific outcome, you’re selling access to skill and attention. The client who needs more work in a given month can buy more. The client who has less going on uses less and pays a smaller invoice.
What to Define Upfront
Regardless of model, these need to be explicit in the contract:
What’s in scope and what isn’t. A web development retainer that doesn’t define whether copywriting, SEO research, social media graphics, and ad creation are included will be asked about all of them. Be specific about what the retainer covers.
Response time expectations. A retainer client often expects faster response than a project client. Decide what you’re committing to: same-day response for issues during business hours, 48-hour turnaround for new requests, one-week timelines for larger changes. Write these down.
How urgent work is handled. When something breaks on a Friday afternoon, who does the client call, and what does “urgent” cost? Define this before you need it, not during an incident.
What happens when work exceeds scope. Monthly overages handled as time and materials? A change order process? Flexibility that gets credited next month? This needs to be agreed on before the relationship starts, because after the first overage it becomes a negotiation where both sides have already decided they’re right.
The minimum term and exit terms. A retainer with no minimum term trains the client to cancel the moment they feel the value isn’t there. A 3-month or 6-month initial term with rolling monthly renewal after that is a reasonable baseline. Give both sides 30-day notice of cancellation.
Pricing Retainers
The common mistake is pricing a retainer at the same effective rate as project work, then wondering why retainer clients feel like they’re overpaying while the agency feels like it’s undercharging.
Retainers have a different value exchange. The client gets:
- Prioritized access to your team
- Continuity (no ramp-up time, you know their system)
- Flexibility to redirect work without a formal scoping process
- Predictability in what external development help costs
They should pay a premium for that. Not a huge premium — 10-20% above your standard rate is defensible. The “lock in reliability” argument is legitimate, and clients who understand the value will pay for it.
The agencies that price retainers too low do it because they’re afraid of losing the work to a competitor. That fear is usually less warranted than it feels. A client who would leave over a 15% premium for a retainer versus project pricing is a client who is already optimizing for cost over continuity, and that client will cause you problems regardless of how you price.
The Capacity Problem
Retainers fail most often not because of pricing or scope, but because of capacity planning. You commit to four retainer clients at 20 hours each, which is 80 hours of committed capacity per month, which leaves 40 hours for project work in a two-person team, which sounds manageable until three of the four retainer clients all have active months simultaneously.
Build in slack. A team of two with 120 billable hours per month should not commit more than 80 hours of retainer capacity. The remainder covers retainer overruns, project work, sales, and administrative time. This feels conservative until the first month where everything is busy and you understand exactly why the buffer exists.
If your retainer capacity is consistently at 100%, hire before you sign new retainers. Adding clients to an already-full plate means something slips, and what slips is usually quality or timeline, which damages the relationships you’re supposed to be deepening.
Signs a Retainer Is Working
The retainer relationship that works looks like this: the client knows what to expect each month, they’re not regularly asking “can you do this too?” about things clearly outside scope, invoices go out and get paid without debate, and the work compounds — each month you know the client’s system better and can do more in the same hours.
The client should feel like they have a team member, not a vendor they have to repeatedly re-onboard.
Signs a Retainer Is Failing
The retainer relationship that’s failing looks like this: you dread the check-in call because it always turns into a scope debate. The client is always asking what’s included. You’re consistently going over the agreed capacity and absorbing the difference rather than having the billing conversation. The relationship has become adversarial around invoices.
When a retainer fails, the conversation to have is about fit, not pricing. Did the retainer structure match what the client actually needed? Did the defined scope match how they actually work? Most failing retainers were the wrong product for the client, not just mispriced.
The Client Qualification Problem
Some clients are project clients who would rather engage when they have something specific to build than maintain an ongoing relationship. Pushing them into a retainer because retainers are better for your revenue doesn’t serve them. A well-managed project client who comes back twice a year is often more profitable and less operationally complex than a retainer client who’s the wrong fit.
The agencies that get retainers right qualify clients for the model as carefully as they qualify the work. Not every client who wants ongoing access to your team should get it on a retainer. The signals that a client is a good fit:
- They have recurring work without a defined endpoint (maintenance, feature iteration, content)
- Their priorities shift often enough that fixed-scope projects create constant change orders
- They value the continuity of working with a team that knows their system
- They’ve worked with the agency before and the relationship is already strong
The signals that they’re a poor fit:
- They have one specific thing they want built and then they’ll be done
- They’ve never worked with you before and there’s no trust established
- They consistently bring everything to you at the last minute
- Their internal team is volatile and the point of contact changes frequently
That judgment call — which clients to bring onto retainers and which to keep on project terms — is what separates retainers that strengthen the business from retainers that slowly drain it.
Sponsored
More from this category
More from Business
Open Source Licensing for Agencies: What MIT, Apache 2.0, and GPL Mean When You Ship Client Code
SaaS Pricing Models That Actually Retain Customers: Usage-Based, Seat-Based, and Hybrid
The Agency Client Onboarding Playbook: What We Do in the First 30 Days
Sponsored
The dispatch
Working notes from
the studio.
A short letter twice a month — what we shipped, what broke, and the AI tools earning their keep.
Discussion
Join the conversation.
Comments are powered by GitHub Discussions. Sign in with your GitHub account to leave a comment.
Sponsored