The buying testA useful retainer makes the next production decision faster and safer. A monthly bucket of unnamed hours does not.
A website maintenance retainer needs three work queues
Put incidents, scheduled upkeep and planned improvements in separate queues. They need different priorities, evidence and approval rules. Without that separation, a broken form competes with a new landing page in the same vague backlog.
Imagine the analytics script stops recording checkout completion while a homepage redesign is in review. The tracking failure needs triage now. The redesign needs planned feedback and release evidence. Calling both tasks "maintenance" hides the decision the team must make.
GOV.UK's service guidance treats live operation as more than bug fixes, upgrades and security. It also includes continuous improvement. Ask a prospective partner to show how work enters each queue, who can change its priority and what proves that it is complete.
| Work queue | Concrete example | Evidence before closure |
|---|---|---|
| Incident response | The lead form rejects valid submissions | Reproduction, fix, journey retest and release record |
| Scheduled upkeep | A dependency reaches its supported upgrade window | Compatibility checks, deployment result and rollback point |
| Planned improvement | The pricing page needs a clearer comparison | Approved change, measured event and post-release review |
Response time is not resolution time
Define when the partner acknowledges an issue, begins investigation, communicates again and restores service. A fast reply is useful, but it is not a promise that every defect can be fixed in the same window.
A missing image may be reversible in minutes. A checkout failure caused by a payment provider may require evidence, escalation and a temporary route. The contract should distinguish restoration from permanent repair and say what happens when a third party controls the outcome.
Write severity around user and business impact, not emotion. A typo on an old article and a form that drops every request should not become equally urgent because two people used the word "critical" in Slack.
The retainer starts with access and a runbook
A partner cannot operate a site safely without current access, known owners and a short recovery procedure. The first deliverable should be an operating map, not a list of speculative improvements.
For example, a production incident may require the repository, hosting account, DNS, analytics, consent platform and form destination. If the only administrator left the company, the retainer begins with account recovery, not code.
Record who can approve production, where secrets live, how to contact critical vendors and which journey must be checked after every release. Keep ownership with the client wherever possible, and grant the partner the minimum access needed to do the work.
Monitoring should lead to a decision, not a dashboard
Monitor signals that can trigger an action. Uptime, form completion, crawl health, field performance and security warnings are useful only when someone knows what change they authorize.
web.dev recommends combining lab checks with real user monitoring. A lab test can catch a regression before release, while field data shows what visitors actually experienced. Google also recommends Search Console notifications and routine security checks because a compromised site can damage users and search visibility.
A practical setup might alert when the contact journey stops completing, then attach a browser trace and the last deployment. A weekly screenshot of ten green scores is easier to produce, but it tells the team less about what to do next.
Use the technical SEO audit guide when crawl, indexing or performance signals need a deeper diagnosis. The retainer can operate the resulting controls once the source problem is understood.
Maintenance must preserve content and accessibility
Ongoing support should protect the systems that non-developers change. A codebase can remain stable while a new campaign page introduces broken headings, vague links or images without useful alternatives.
W3C recommends assigning responsibilities, monitoring progress and integrating accessibility throughout delivery. For a CMS-driven site, that might mean required fields, author guidance and a release check on a representative page rather than another annual clean-up.
Use a website content audit when ownership, duplication or stale promises are the dominant problem. Use website accessibility remediation when known barriers require a structured repair program. The retainer should prevent recurrence after those projects close.
Capacity needs a rule before the backlog grows
Decide how the team protects incident capacity and chooses improvements. Otherwise the loudest request consumes the month, important upkeep moves again and nobody knows whether unused capacity carries forward.
Consider a hypothetical month with a broken integration, a routine framework update and three campaign requests. The partner should surface the tradeoff: restore the integration, reserve the agreed upkeep window, then ask the owner which campaign change creates the most useful outcome.
Ask how capacity is forecast, what can interrupt planned work, who accepts completed work and how unresolved items are reported. "Unlimited requests" is not unlimited delivery. It usually means requests wait in a queue whose operating rules were never explained.
Some changes belong outside the retainer
Move work into a separate project when the team must discover a new journey, change the architecture or coordinate several business owners. A retainer can fund small experiments, but it should not disguise an unplanned redesign.
Replacing a pricing sentence fits ongoing support. Rebuilding pricing logic across the website, billing system and sales process needs research, decisions and broader acceptance criteria. Pretending both are tickets makes the second change less visible, not less risky.
The website redesign strategy helps decide when maintenance is preserving the wrong structure. A good partner should be willing to say when the retainer is the wrong container for the work.
Website maintenance retainer buying checklist
Send Seuil your current backlog, one critical journey and the names of the people who own production decisions. Email bonjour@seuil.digital to scope the smallest retainer that can keep the site safe and useful.
- Incidents, scheduled upkeep and improvements have separate queues.
- Severity reflects user and business impact.
- Response, restoration, resolution and communication rules are distinct.
- Repository, hosting, domain, analytics and vendor access have named owners.
- Every release leaves evidence and a usable rollback point.
- Monitoring signals have thresholds, recipients and next actions.
- Capacity, interruptions, carry-over and acceptance are explicit.
- The contract explains when a change becomes a separate project.