The retainer number most agencies quote is last year's number plus a bit. Here's how to derive it instead.
A retainer should be priced from the hours you actually deliver, not from what the client paid last year. The method is three steps: measure hours delivered per month over the last two or three periods, apply your loaded hourly cost plus target margin, then choose a model — hours-based, deliverable-based or access-based — that matches how the client actually consumes your time. Every step needs data you already have if your team logs daily work.
A retainer starts at a number that felt reasonable. Then the work grows — a bit more each month, none of it individually worth an argument — while the price stays fixed. Eighteen months later you are delivering 60 hours a month for a fee sized around 35, and everybody involved is mildly unhappy: you feel taken advantage of, the client feels you have become slower and less responsive, and neither party can point at a moment where it went wrong.
It went wrong because the retainer was never anchored to a measurable quantity. A retainer priced against hours has a natural conversation built into it — "we're consistently at 55 hours against 35 sold, let's resize" — that a retainer priced on vibes does not.
Pull hours logged against that client for each of the last three to six months. You want, per month:
Use the median month rather than the mean, then add a buffer for the reactive tail. A single campaign month can drag an average up by 40% and produce a retainer nobody can sustain in a normal month. This all depends on clients and projects being structured cleanly — if the client's work is spread across free-typed project names, the number you pull will be wrong.
Retainer price = expected monthly hours × loaded hourly cost × (1 + target margin).
Worked example. Median delivery is 42 hours a month across a designer (₹690/h) and a developer (₹810/h), roughly 60/40. Blended loaded cost ≈ ₹738/h. At 42 hours, cost ≈ ₹31,000. At a 40% target margin, price ≈ ₹43,400 — call it ₹45,000.
If that number is far above what the client currently pays, you have just quantified how much the retainer has drifted. That is uncomfortable and it is exactly the information you needed. How to build the loaded hourly cost is covered here — using unloaded salary rates at this step is what produces retainers that look profitable and are not.
| Hours-based | A block of hours per month at an agreed rate. Transparent, easy to resize, easy to police. Risks framing your value as time rather than outcomes, and invites hour-counting. |
|---|---|
| Deliverable-based | A fixed set of outputs per month — four articles, two campaigns, one report. Clear to the client and outcome-shaped. Requires you to know your delivery cost per output, or you carry all the estimation risk. |
| Access-based | Availability and response commitments rather than volume. Suits support and advisory work. Needs a fair-use boundary, or it becomes unlimited work for a fixed fee. |
Match the model to consumption. A client who sends unpredictable ad-hoc requests fits hours or access; a client who wants a predictable content cadence fits deliverables. Choosing the model that suits your internal accounting rather than their behaviour is what creates monthly friction.
Note that deliverable-based pricing still needs the hours data underneath it — you cannot price four articles a month without knowing what an article costs you, and knowing that requires estimates checked against actuals.
Three clauses, written at the start, prevent nearly all retainer disputes:
Scope creep is just what a missing overage clause looks like six months in. Nobody creeps deliberately — the boundary simply doesn't exist to notice crossing.
Track one number monthly: hours delivered ÷ hours sold.
At renewal, open with the data: here is what we delivered each month, here is what was sold, here is the proposed adjustment. A conversation grounded in measured delivery is a negotiation about facts. A conversation that begins "we need to increase the fee by 15%" is a negotiation about your costs, which is not the client's problem.
For agencies, a maintenance retainer has a second half: monitoring the client's site and sending a monthly SLA report — both are deliverables the retainer can price in.
| Retainer price formula | Expected monthly hours × loaded hourly cost × (1 + target margin) |
|---|---|
| Measurement window | 3–6 months of logged hours, using the median month |
| Worked example | 42h/month × ₹738 blended ≈ ₹31,000 cost → ~₹45,000 at 40% margin |
| Unlogged effort | Typically 10–20% — estimate it rather than ignore it |
| Three models | Hours-based · deliverable-based · access-based |
| Key metric | Hours delivered ÷ hours sold, reviewed monthly |
| Healthy utilisation | 85–110%; above 110% you're subsidising, below 70% they'll churn |
Measure the hours you actually delivered to that client over the last three to six months and take the median, add a buffer for reactive work, multiply by your loaded hourly cost, then add your target margin. Pricing from delivered hours rather than from last year's fee is what stops a retainer drifting into unprofitability.
It depends on how the client consumes your time. Unpredictable ad-hoc requests fit an hours-based or access-based model; a predictable output cadence fits deliverable-based pricing. Note that deliverable pricing still requires hours data underneath, because you cannot price four articles a month without knowing what one costs you to produce.
Between 85% and 110% of sold hours is healthy. Consistently above 110% means you are subsidising the client and should resize at renewal or sooner. Consistently below 70% means the client is not receiving value and is likely to cancel — proactively adding scope or reducing the fee is a strong retention move.
Write an overage clause, a rollover rule and a specific scope boundary into the agreement at the start. Scope creep is what a missing overage clause looks like several months in — nobody creeps deliberately, there is simply no boundary to notice crossing. Describe the scope in countable terms rather than in categories.
Capped rollover, typically one month, is a fair compromise. Unlimited rollover builds an accumulated liability the client can call on all at once, usually when you are busiest. No rollover at all is defensible if the retainer is genuinely about availability, but it should be stated clearly rather than discovered.
Lead with delivery data: hours delivered per month against hours sold, and the proposed adjustment that brings them back into line. That is a conversation about facts. Opening with a percentage increase makes it a conversation about your costs, which the client has no reason to accept.
The measurement this article depends on comes out of Merik's daily task log: entries carry client, project, person and time spent, so hours delivered per client per month are already recorded rather than reconstructed at renewal time. Project Intelligence rolls them up per project and contributor, which is where the utilisation figure comes from.
Quotes and invoices live against the same client records, so the fee you sold and the effort you delivered can be compared without exporting anything. When it is time to reprice, the conversation starts from data both sides can see. See the clients, projects and task modules, the feature list, or how it works.
Turn the hours your team already logs into a per-project margin.
From line-item quote to sent invoice without retyping anything.
Estimate vs logged hours per project, weekly, turned into a change request in time.