What support after go-live should actually include

Support is a promise about two clocks, not one: how quickly a qualified person answers, and how quickly the system works again. A contract that names only the first is a call centre with your name on it. The answer flips with what you are buying: a handful of hours a month suits a stable system with occasional questions, and a monthly retainer suits a system that carries money every day.

Why are response time and resolution time different promises?

Response means somebody qualified has acknowledged the problem, taken ownership, and said what happens next. Resolution means the system is restored, or a workaround has been agreed and written down. Most contracts quote the first, because it is cheap to promise and easy to measure; ask for both, with the hours of cover and the name of the role that answers.

Two words need defining before anything else: "restored" — a fix, or a workaround that holds until the fix? — and "severity". If severity is not defined with an example from your own history, every ticket begins with an argument about whether it is urgent, and the queue gets ordered by whoever is loudest.

What counts as a bug, and what is a change request?

A bug is the system not doing what the agreed document says. A change is the system doing what was agreed, and you wanting something else. The line has to be written before the first ticket, with two examples on each side, because otherwise every conversation is a negotiation in which the vendor holds the logs and you hold the memory.

The cheapest tool for this is the acceptance test written during the build. With those tests, "the invoice total is wrong for a customer with a credit note" is a bug with a reference. Without them, it is a discussion about expectations, and the discussion is billed either way.

Hours, a retainer or per incident — which suits whom?

What you buy	What it suits	What it does not give you
Hours as used	A stable system, occasional questions	Anyone watching it
Monthly retainer	Money moving through it daily	Unlimited work
Per incident	Rare, clear failures	A response time

Hours are honest for a small system that changes twice a year: you pay for what you use and you accept that nobody is watching between calls. A retainer is not really about the hours; it buys a person who already knows where the invoice numbers come from, and a contract that makes monitoring somebody's job. Per incident is the cheapest line on paper and the most expensive on the day it matters, because the person you need is busy with a client who pays monthly.

Why do monitoring and backups belong inside support?

Support without monitoring is a promise to react to what customers report, and customers report late — after they have lost patience, not after the first failure. An uptime check, error tracking, a scheduled job that fails loudly, disk space and certificate expiry: this is the part of support that finds the problem before the phone does.

Backups belong there too, with a named owner, a stated frequency, a location that is not the same disk, and a restore that somebody has performed. Support that excludes both is a fire brigade without a smoke alarm, and it will still send a bill.

Speed belongs in the same list, and it is the argument most often settled by opinion. Core Web Vitals are measured from real visits rather than from a laptop on a fast connection, so a page that feels quick in the office and slow at a counter becomes a number both sides can read.

What should the monthly note contain?

One page, not a dashboard. What broke, what was fixed, how long each took, what is still open, what changed in the system, what is at risk next month — a certificate expiring, a database growing, an integration whose provider is retiring an endpoint — and the hours used against the hours bought.

The note is what turns a renewal into a decision. Without it, support is a subscription you keep because cancelling is more work than paying, and you cannot tell whether the system is getting better or only older.

What does a clean exit look like?

Agree it before you sign, not when you want to leave: on termination, the repository and the accounts handed over within a stated period, a runbook, a final restore test, and a named number of days of help during the transition. A support contract silent on exit is not a maintenance agreement; it is a subscription to a particular person.

How do you set this up?

1. List the three failures that would stop trading that day. Those define critical, and nothing else does.
2. Write a severity scale with one real example from your own history at each level.
3. Decide hours or retainer against how much money passes through the system each day.
4. Put response and resolution targets in writing, with the hours of cover and who answers.
5. Name monitoring and a restore test as deliverables, with a frequency and an owner.
6. Fix the change-request rate or process in writing, with an example of each kind of request.
7. Require the monthly note and the exit clause as part of the contract.
8. Review after three months: how many incidents, how many hours, how many "bugs" were changes.

Where this goes wrong

• The promise is four hours and what arrives is a ticket number. A queue acknowledging receipt is not a person taking ownership, and the clock stops when the ticket is closed.
• Everything is critical, because nobody defined critical, so the queue is ordered by who shouts and the real incident waits behind three false ones.
• No monitoring. You learn about the outage from a customer on a Saturday, and the first hour goes on working out who to call.
• The retainer is spent on small changes, so there is nothing left in the month the incident lands, and the invoice arrives twice.
• Backups are named in the contract and nobody has restored one. The clause is true and useless.
• Two support contracts for two halves of one flow, each blaming the other while the customer waits.
• No exit clause. Leaving costs a project, so nobody leaves, and the price is set by whoever is already inside.

What this does not cover

It quotes no prices, deliberately: rates depend on the market, the system and how well it is documented, and a figure in an article ages badly. It does not cover your hosting provider's guarantees, which are a separate contract and usually promise service credits rather than a working business. And it does not replace the service levels your own customers expect from you — support on the inside has to be faster than the promise you made on the outside.

We take support contracts with monitoring, a restore test and the exit clause written in, because a system nobody can leave is not maintained, it is rented.