Retainers are most agencies' steady income. A survey by SoDa and Productive, as reported by Swydo, puts retainers at about 44% of agency revenue, and Swydo cites a Sprout Social survey of 220+ agencies in which nearly 80% use some form of retainer. Treat those as a vendor's summary, not a census. They still match what most agency owners already know: a large share of the money comes from "we look after it every month".
And the monthly part is usually the part nobody tracks.
Photo: graymalkn, CC BY 2.0
How a retainer leaks
The contract says 20 hours a month. Then the month happens. A plugin update, a form that stopped sending, a "quick" banner swap, two calls about the banner. Each one is small and each one is fair. By the 18th the hours are gone, the client has three more requests in the chat, and whoever is on the account says yes to all of them, because nobody told them the month was spent.
The overrun turns up at invoice time as a decision you can't really make any more: bill hours the client never agreed to, or write them off. Most agencies write them off.
A retainer you only add up at the end of the month isn't a budget. It's a hope.
Count it the way the work happened
Two rules make the numbers honest.
Calendar months, not rolling totals. The client bought "20 hours in November", so that's the figure to measure against. Hours from October don't spill into it, and unused November hours don't make December look healthy.
Hours land on the days the work was in progress. A task that ran from the 28th to the 4th is billed to both months, spread over the weekdays it was actually being worked on. If you book all of it on the day it closed, one month looks idle and the next looks over budget, and neither is true.
That's what Gavril does for a project set up as a retainer: the monthly hours, the hours logged on tasks split across their in-progress weekdays, and a projection for the month once a few working days have passed. One busy Monday isn't a trend. At 80% the PM sees it on the dashboard. A month on course to run over, or already over, goes into the morning digest of things to deal with. An accepted change request adds its hours to the month it was agreed in.
Decide now what happens when it runs out
The worst moment to work out your over-budget policy is in a client chat, at the point the client asks for one more thing. So write it down first, and make it boring.
When the month is actually over (a projection is the PM's call, not something to tell a client as fact), Gavril's answers in the client's chat change:
- New work is declined politely and passed to the PM. The client is told the month's hours are used up and that the PM will confirm whether it goes into next month or gets done now as extra hours. No promise and no date.
- Broken things are still taken. A maintenance client whose site is down doesn't get told to buy more hours first. Something broken or urgent isn't new work.
- No price is quoted, ever. Rates are a conversation for the PM, not something a chat reply should improvise.
On the 1st the PM gets the previous month's report: hours used against the retainer, what was fixed, what's still open. It's written from the numbers rather than by the model, and the PM reads, edits and sends it.
The overrun conversation is much easier on the 18th than at invoice time. It's the same one as what scope creep actually costs, it goes better with a change request process clients follow, and it fits naturally into status updates they already read.
All posts