Maintenance should never be one bucket of hours
The standard agency retainer is a bucket of hours. Ten hours a month, twenty, forty – use them for whatever you like. It sounds flexible, and flexibility sells.
I’ve spent years on the operations side of these agreements, writing them, running them and renegotiating them, and I’ll say plainly: the blended bucket is the single most common structural mistake in website maintenance. Not because the hours are wrong, but because two fundamentally different kinds of work are competing for the same pool – and one of them can’t afford to lose.
The two failure modes
Failure one: security gets starved. The client, quite reasonably, spends their hours on things they can see – content changes, small features, design tweaks. Every month, the visible work wins and the invisible work waits. Dependency updates slip. Patches queue. Nobody decided to neglect security; the structure decided it for them. Then one day a vulnerability lands in a component that’s three versions behind, and the cheapest work the agency never did becomes the most expensive incident the client ever had.
Failure two: the client discovers they bought insurance, not budget. The agency, quite reasonably, spends the hours on the unglamorous baseline – updates, monitoring, backups, patching. The client sees the monthly report, sees no new features, and asks the fair question: what am I actually paying for? The honest answer – “the absence of disasters” – is true, valuable and deeply unsatisfying to hear about hours they believed were theirs to direct.
One pool, two masters. Whichever master wins, someone ends the year feeling cheated – and both failures are structural, not moral. Nobody behaved badly. The contract did.
The architecture: two pools, two logics
The fix is to separate the work by its logic, not its labour. Our agreements are built on two distinct pools:
Pool one – Security & Maintenance, fixed fee. The non-negotiable baseline that keeps a platform safe, current and recoverable. It isn’t measured in hours and the client doesn’t spend it; it’s a standing obligation we price and carry. If a critical patch takes ten minutes, it happens. If it takes three days, it still happens. The client is buying an outcome – a maintained platform – not our time.
Pool two – Allocated Service Hours, discretionary. The client’s budget, directed by the client. Improvements, content support, small features, investigations, advice. This pool is measured in hours, tracked in a proper time-tracking system, reported monthly, and – where the agreement allows – rolled over. It’s flexible because it can afford to be.
The separation does something subtle and important: it removes the daily competition. Security work never queues behind a homepage tweak, because they’re not in the same queue. And the client’s hours are genuinely theirs, because the baseline isn’t quietly eating them.
What belongs in which pool
The sorting rule is a single question: does this work stop being optional when it’s ignored? If neglecting it eventually forces an emergency, it belongs in the fixed fee. If neglecting it merely means it doesn’t happen, it belongs in the hours.
Fixed fee: core and dependency updates. Security patching and vulnerability response. Uptime monitoring and alerting. Backups, and – the part everyone forgets – periodic restore tests. Certificate renewals. Environment and hosting liaison. The unglamorous list that nobody notices until it’s missing.
Service hours: new features and enhancements. Content and CMS support. Design changes. Integrations and third-party configuration. Investigation of incidents that turn out to be client-caused or invalid. Training, advice, and the “could you just quickly” work that makes a retainer feel alive.
Incidents route between the pools by classification – a discipline we covered in The anatomy of a website incident. A defect we introduced costs the client nothing. A vulnerability response draws on the fixed fee. An incident caused by a change on the client’s side, or one that investigation proves invalid, draws on their hours. The taxonomy and the two-pool structure are one system: the categories decide the routing, and the pools make the routing mean something financially.
The details that make it work
Rollover lives in one pool only. Unused service hours can roll – that’s a fair recognition that a client’s needs breathe month to month. The fixed fee never rolls, because it isn’t a quantity. You can’t bank this month’s patching against next month’s, any more than you can skip insurance in a quiet year.
The reporting must be real. Hours reported to a client should come from tracked time, not reconstruction at month end. Ours flow from Clockify into the monthly report automatically, with rollover arithmetic handled by the platform rather than a spreadsheet and good intentions. A two-pool structure only builds trust if the numbers underneath it are trustworthy.
The boundary needs a referee. Edge cases exist – is rebuilding a component during an update maintenance or improvement? Someone has to make that call consistently and be accountable for it. In our shop, that’s an operations decision, made against the sorting rule above and written down. The worst version of this model is one where every edge case reopens the whole negotiation.
What this costs, honestly
The two-pool model asks the client to accept a fixed fee for work they will rarely see, and it asks the agency to carry the risk of heavy months without a meter running. Both sides give something up. That’s usually the sign of a structure that will hold.
And it means being straight about what the fixed fee doesn’t buy: it doesn’t buy features, redesigns, or a discount on ambition. It buys the platform still being there – patched, monitored, backed up and recoverable – every single month, without anyone having to remember to choose it.
If your current maintenance agreement is one undifferentiated pot, here’s a diagnostic that takes five minutes: pull the last three months of reported hours and sort every line into “would an emergency eventually force this?” and “would this simply not happen?” If the first pile is thin, your platform is quietly accruing risk. If the second pile is thin, you’re paying for insurance you thought was a budget. Either way – now you know, and it’s fixable.
Emelia Gatley is Director of Operations at Websure. This series covers how the agency runs delivery, maintenance and security. Previously: