Coverage and response

Coverage windows are written into the engagement, not implied by tone. What hours, which days, and what counts as urgent enough to interrupt them — all three stated, so the business can decide what other arrangements it needs.

Severity is defined by consequence instead of by adjective. A site returning errors to every visitor and a misaligned heading are not the same event, and agreeing that distinction in advance prevents it being negotiated during the incident by whoever is most agitated.

Response time and resolution time are separated and stated separately. Acknowledging a report quickly is a commitment that can be honored; resolving an arbitrary fault in a fixed window is not, and promising the second is how a support arrangement starts producing arguments.

There is a written first response for total unavailability, because that is the case where improvisation is most expensive and least likely to go well: confirm the scope, check the deploy history, check the platform's own status, then work outward.

Incidents get a short written record afterwards — what happened, what caused it, what was changed. Not a formality: the same fault recurring twice is normal, and the second occurrence is only cheap if somebody wrote down the first.

Work outside the agreed scope is quoted rather than absorbed silently. Absorbing it seems generous and reliably ends with an unstated expectation that is discovered by disappointing somebody.

Where a business genuinely needs coverage beyond what is offered, saying so is part of the work. A business whose revenue depends on a system being available at three in the morning needs an arrangement that reflects that, and pretending otherwise to keep an engagement serves nobody.

Everything above is unremarkable, and the reason to publish it is that the alternative — leaving availability to be inferred — reliably produces a disappointment neither side agreed to.