Are Your Support Retainers Actually Profitable?

I have a question I put to agency owners who run a book of support and maintenance work alongside their build practice: "When did you last re-cost a retainer?" The build, everyone re-costs at close. The retainer, almost nobody does. It was priced once, eighteen or thirty months ago, and it has been invoicing the same flat fee ever since.

That asymmetry is the whole problem. A support retainer is a product line, not a favour you do for a client after a build. It has revenue, it has a cost to serve, and it has a margin that moves over time — usually downward, because everything that erodes it (scope, seniority, communication load) ratchets one way. Support retainer profitability is not something you set at sale and bank for the life of the contract. It is something that needs measuring on the same cadence you'd apply to any other product.

This piece is for the finance lead or owner who has a column of monthly retainers on the P&L, each one looking fine at the invoice line, and a quiet suspicion that at least one of them is underwater. It builds on what project margin actually is — the same three cost components apply — and on the three project types every agency runs, which makes the case for separating support from development in the first place. Here we go one level deeper into the support line specifically.

Why support retainers drift into loss

A retainer is sold against an assumption: this client will need roughly n hours a month, at roughly this role mix, within this response window. The price is set to clear cost plus a margin against that assumption. The assumption is reasonable on the day it's made. It then stops being true, slowly, in three predictable ways.

SLA creep

The contract said "response within one business day". In practice the client now expects a reply within the hour, because that's what they got the first few times and it set the bar. Honouring an informal one-hour response means somebody senior has to be watching the queue, or interruptible, most of the working day. The contract priced a one-day SLA; the agency is staffing a one-hour one. The cost of standby — the bench time, the context-switching, the senior who can't be put on focused build work because they're on support watch — is real, and none of it was in the original price.

Seniority drift

The budget assumed a mid-level engineer would handle most tickets, with occasional senior input. What actually happens: the production system is fragile, the tickets are gnarly, and the only person who can safely touch the integration is the lead who built it. So the lead takes the "quick fix". The retainer is billed at a blended support rate that assumed mid-level delivery; it is being delivered by someone whose real cost is half as much again. Every ticket worked by the wrong seniority widens the gap between what the retainer earns and what it costs.

Unlogged communication

This is the quietest one and often the largest. The build had tickets; people logged time against tickets. The retainer has a Slack channel. The client drops a question in the channel; a senior engineer spends twenty minutes diagnosing it and replies; nothing is logged because it "wasn't really a ticket". Multiply by a dozen exchanges a week, add the standing fortnightly call, the email threads, the "can you just look at this before the call" messages, and you have several hours a week of senior time that exists nowhere in Jira and therefore nowhere in the margin report. The retainer looks profitable precisely because the most expensive part of serving it was never recorded.

The combined effect is that a retainer can look healthy on every metric you happen to be watching, and lose money on the one you aren't.

What a re-costed retainer actually shows

Take a retainer we ran (anonymised, scaled to round numbers). On paper it was one of the steadier lines on the book.

• Billed: £6,000/month, flat, for a managed-services arrangement on a production platform
• Assumed budget at sale: ~50 hours/month, mostly mid-level, with a one-business-day response SLA
• Logged hours in Jira: ~46/month — comfortably inside budget, which is exactly why nobody worried

On the logged hours alone, at a blended support role rate, this retainer reads as a 30-something-percent margin line. Fine. Now re-cost it properly, with the three components from the margin definition.

• Labour at real cost. Of the 46 logged hours, ~18 were the lead's, not the mid's, because the tricky tickets kept routing to him. The lead's fully-loaded cost is far above the mid's. Costing the named people who actually did the work rather than the budgeted role mix pushes labour cost to about £3,300/month.
• Unlogged communication. A fair accounting of the Slack threads, the calls, and the email added roughly 9 hours/month of senior time that never hit a ticket — call it another £900/month at real cost.
• Allocated overhead. The retainer's pro-rata share of monthly overhead, on its share of revenue, came to about £1,900/month.

True cost to serve: £3,300 + £900 + £1,900 = £6,100/month against £6,000 billed. The retainer that looked like a steady 30%+ line was running at roughly −2%. Not a disaster on any single month, which is exactly why it survived two years. But it was consuming senior capacity that the build practice — running at real margins well into the twenties — needed, and it was doing so at a loss.

The point of the example is not the specific minus-two. It is that nothing on the invoice, the logged hours, or the SLA dashboard would have told you this retainer had drifted underwater. You only see it when you re-cost the three components against the named people who actually did the work.

How to instrument per-retainer real margin

You cannot fix what you cannot see, and the reason support retainer profitability drifts unnoticed is that the standard instrumentation — invoice value, logged hours against budget — is blind to all three drift forces. Here is what to measure instead.

Cost per ticket, not hours against budget

Hours against budget tells you whether you're inside the hour allowance. It tells you nothing about what those hours cost. Compute cost per ticket using each ticket's worklogs at the named person's real hourly cost, then watch the distribution. A retainer where the median ticket costs £40 and the top decile costs £400 is telling you that a small number of tickets — usually the ones routed to the lead — are carrying the cost. That's a routing problem you can act on, invisible in the budget view.

Who actually works the tickets

Pull the seniority mix of delivered hours and compare it to the mix the retainer was priced on. If the retainer was sold assuming 80% mid and 20% senior, and it's running 55% mid and 45% senior, you have quantified the seniority drift. This single comparison is often the largest single explanation for a retainer that's underwater, and it points straight at the fix.

Time that isn't in Jira

This is the hard one, because by definition it isn't recorded. You don't need surveillance to get a usable number — Saldo reads Jira read-only and would never see a Slack thread, and that's by design. What you need is a light convention: a single recurring "client communication" ticket per retainer that the team logs comms time against, even in rough fifteen-minute blocks. It will be under-counted at first. Even under-counted, it usually moves the real margin by several points and ends the fiction that comms is free.

Put those three together and the retainer stops being a flat invoice line and becomes a margin report you can actually run an agency on — cost per ticket, the real seniority mix, and an honest accounting of the time that used to vanish.

What to do once you can see it

Measurement is the first half. The second half is three operational moves, none of which require losing the client.

1. Re-cost every retainer quarterly. Put it on the same cadence as any other product review. A retainer that was fairly priced at sale will have drifted by the second or third quarter; catching it early makes the repricing conversation small. Most clients accept a 10–20% adjustment on a clearly-evidenced retainer, especially when you can show them the response times and ticket volumes they've actually been getting.
2. Cap or tier the scope. A flat fee with an unbounded SLA is an open invoice. Define what the retainer includes — hours, response window, role mix — and what sits outside it. Work above the cap becomes either a change request or a higher tier. Tiering also gives the client a legitimate way to pay for the one-hour response they've been getting for free.
3. Route work to the right seniority. If the lead is the only person who can safely touch the system, that is a knowledge-concentration risk you should be retiring anyway. Pairing a mid with the lead on the early tickets, documenting the fragile areas, and deliberately moving routine work down the seniority ladder lowers the cost to serve and de-risks the account at the same time.

None of these is a pricing trick. They are the same disciplines you'd apply to a build that was running over: see the real number, understand which component is driving it, and act on the driver rather than the symptom.

The shorter version

A support retainer is a product, and like any product its margin moves. Priced once and never re-costed, it drifts towards loss through tighter SLAs, senior people doing work the budget priced for juniors, and a communication load that never reaches a timesheet. The flat invoice hides all of it.

If you want to see your own retainers re-costed on your real Jira data — cost per ticket at named-person cost, the actual seniority mix against the one you sold, overhead allocated honestly — that's Saldo. The 15-minute demo runs on your real Jira; we don't ask for card details up front. The retainers that come out underwater are rarely the ones you'd have guessed, which is the whole reason to measure them.