Gabriel EspinheiraAuthor
TL;DR: A useful website maintenance agreement names four separate jobs: hosting, technical care, content changes, and conversion improvement. Each needs an owner, cadence, evidence, and boundary. If the scope only says “maintenance”, you are buying availability without a clear promise of what will change.
“Hosting and maintenance” is one of the most expensive vague phrases in a service agreement.
It can mean somebody keeps the server online. It can mean updates, backups, content edits, analytics, landing pages, or a monthly report nobody reads. Two providers can use the same label while selling entirely different responsibilities.
That ambiguity creates the familiar question: what am I actually paying for?
The answer should fit on one page. Split the work into four jobs, then make each job accountable.
1. Hosting keeps the website available
Hosting is the infrastructure the site runs on. It usually covers the server or platform, bandwidth, certificates, deployment infrastructure, and basic availability monitoring.
The accountable version names:
- where the site is hosted;
- who owns the account and billing relationship;
- how uptime is monitored;
- who responds when the site is unavailable;
- what recovery path exists if a deployment fails.
Hosting does not automatically include fixing application bugs, updating content, improving page speed, or changing a form. Those are separate jobs.
Ownership matters here. Your business should be able to leave a supplier without losing its domain, content or data, and it should know before signing who owns the code. Our website plans put that line in writing: the domain, brand, content and data are yours; the code stays SharpHaw's.
2. Technical care keeps the system healthy
Technical care starts where hosting stops. It covers the work required to keep the website secure, compatible, recoverable, and technically sound.
Depending on the stack, that can include:
- dependency and platform updates;
- security patching;
- backup checks and restoration tests;
- broken-form and broken-link monitoring;
- performance checks;
- error investigation;
- accessibility regression checks;
- DNS, certificate, and integration maintenance.
The word “updates” is not enough. A useful scope defines how often checks happen, what gets fixed without approval, what requires a separate decision, and how completed work is shown.
A report that says everything is green is weak evidence. A short change log is better: what was checked, what changed, what failed, what remains open, and who owns the next action.
3. Content changes keep the website accurate
A technically healthy website can still be commercially wrong.
Services change. Team members leave. Offers become clearer. Proof ages. A launch announcement stays on the homepage for six months. Content maintenance exists to keep the site aligned with the business buyers meet today.
This job needs an operating rule, not an unlimited-edits promise. Define:
- what counts as a content change;
- where requests enter the queue;
- who supplies and approves the source material;
- the expected turnaround;
- the number of active requests;
- what becomes a new page, feature, or project.
The request system matters as much as the allowance. Work disappears when it lives across email, chat, documents, and calls. A shared queue, such as the one we use in SharpOS, leaves one visible record of the request, decision, draft, and approval.
4. Conversion improvement makes the website earn its keep
Conversion improvement is the job most often implied by a maintenance fee and least often specified.
It is not the same as keeping the site online. It means finding and shipping changes intended to help more qualified visitors take the next useful action.
That can include:
- clarifying an offer or call to action;
- improving a high-intent service page;
- reducing friction in a form;
- creating a campaign landing page;
- adding missing proof;
- fixing a mobile journey;
- testing a meaningful page change;
- connecting website behaviour to sales feedback.
This work needs a hypothesis and a decision, not just activity. Every change should say what problem it addresses, what was shipped, what evidence will be watched, and when the result will be reviewed.
That is the difference between a maintained brochure and a conversion-first website that continues to adapt.
Put one accountability line under each job
An honest scope can use the same four fields for every job:
| Field | Question it must answer |
|---|---|
| Owner | Who notices and acts without being chased? |
| Cadence | When does this work happen? |
| Evidence | How can the client see what changed? |
| Boundary | What is included, and what triggers a new decision? |
Applied to the four jobs, the agreement becomes much easier to inspect:
| Job | Accountable promise |
|---|---|
| Hosting | Keep the site available and own incident response |
| Technical care | Check, patch, test, and document system health |
| Content changes | Ship approved updates through one visible queue |
| Conversion improvement | Propose, release, and review commercial changes |
If a supplier cannot fill those cells, the fee is not necessarily unfair. It is simply undefined.
Separate care from improvement
There is a useful line between preserving the current system and improving its commercial performance.
Care prevents deterioration. Improvement creates a reason for the site to get better.
Bundling both can work, but the agreement should still show the allocation. Otherwise urgent fixes consume the entire month while improvement remains an implied future benefit. The client sees a recurring invoice; the supplier sees an endless support queue; neither can say whether the site is moving forward.
One simple operating model is:
- technical risks enter a care queue;
- business requests enter a content queue;
- one conversion opportunity is chosen at a time;
- shipped work and open decisions are visible in the same workspace;
- the next priority follows evidence, not whoever sent the last message.
This is close to how SharpHaw structures a senior-led growth subscription: one queue, visible work, and continuous shipping across the website and the marketing around it.
Some websites only need two jobs
A small brochure site with stable information and little qualified traffic may only need reliable hosting and periodic technical care. Paying for monthly conversion work would be theatre if nobody will use the evidence or approve changes.
The right scope depends on the role the site plays in the business.
If it is a contact card, preserve it. If it is expected to generate enquiries, support sales, launch offers, or answer buyer objections, it needs content and conversion ownership too.
That is the strongest reason not to buy a broad maintenance package by default. Buy the jobs the website actually has.
Audit the next maintenance invoice
Take the last month of work and sort every item into the four jobs.
Then ask:
- Which job received no work?
- Which job has no named owner?
- Which job produced no visible evidence?
- Which requests waited because the boundary was unclear?
- Which commercial improvement shipped?
If the answers are hard to find, the next conversation should not start with the fee. Start with the scope.
Name the jobs. Name the owner. Name the evidence. Then decide whether the arrangement is worth continuing.
If your website is meant to support growth but its maintenance scope only preserves the status quo, talk to SharpHaw about a clearer operating model.
The service behind this article: Conversion-First Websites
