By Yair Knijn · August 27, 2025

The outage where the fix took twenty minutes and the silence cost the contract

The service-desk manager will tell you the outage lasted twenty minutes. The login service was down, an engineer found the bad config push, rolled it back, and the dashboards went green. Clean MTTR. The post-mortem writes itself. And the client's account exec spent those twenty minutes on a call with their CTO with nothing to say, because nobody from your side told them anything until it was already over.

That is the trap. The manager believes resolving the technical fault is handling the incident. It is half of handling the incident. The other half is the part that decides whether the client renews: who is talking to whom, how often, and with what honesty. When an outage hits and there is no major-incident process, the desk goes silent while it fixes things, and silence reads as incompetence even when the engineering is excellent.

Major incident management: the roles your desk doesn't staff

A major incident is not a big regular ticket. ITIL 4 treats it as a separate procedure with its own roles precisely because the normal queue model collapses under it. The roles that go unstaffed are the ones that have nothing to do with the code: an incident commander who owns the response, a communications lead who owns the message, and a scribe who keeps the timeline. None of these people touch the broken service. That is the point.

Most desks have none of these defined before the incident, so they get improvised mid-crisis by whoever is loudest. The result is three engineers debugging the same thing, no single owner, and a client update that goes out forty minutes late because everyone assumed someone else was sending it.

Incident commander vs technical lead: why one person can't be both

The person with their hands in the config cannot also be the person writing the stakeholder update. The cognitive modes are opposed. Diagnosis wants depth, tunnel vision, and silence. Command wants breadth, status, and a clock. Ask one human to do both and you get a technical lead who stops debugging every six minutes to draft a sentence, or a commander who disappears into the logs and the comms channel goes dark.

Separate them. The technical lead drives the fix and reports status to the commander. The commander never debugs. They decide severity, pull in resources, set the next update time, and decide what the client hears. On a true SEV-1 that division is not bureaucracy, it is the only thing that keeps both jobs from being done badly.

The comms cadence that keeps clients calm while you fix it

Clients do not need a fix in the next five minutes. They need to know you know, and they need to know when they will hear from you again. The standard for a severe incident is a short, predictable interval — for a SEV-1, an update roughly every 15 to 30 minutes, sent on schedule whether or not anything changed. "No change, next update in twenty minutes" is a real update. It tells the CTO their vendor is awake.

• State what is affected and the scope, not the root cause you are still chasing.
• Give the next update time in every message, and hit it.
• Use one timestamped channel as the single source of truth, not three threads and a phone call.
• Give honest uncertainty over an invented ETA. A missed ETA costs more trust than admitting you don't have one.

Post-incident review that produces a problem record, not just relief

The dangerous moment is when the service comes back and the room exhales. Relief is not closure. A rollback fixed the symptom; it did not explain why a bad config reached production with no gate. If the review ends at "resolved," the same incident is scheduled to happen again, and next time the client will not extend the benefit of the doubt.

A real post-incident review produces a problem record, blameless, with a timeline reconstructed from the scribe's notes and at least one action item with an owner and a date. That is the difference between an outage you survived and one you learned from.

OpsDesk gives each client workspace a severity-driven major-incident track: declare an incident, assign commander and technical lead as distinct roles, run the update clock so the comms channel never goes quiet, and convert the close-out into a linked problem record with owned actions. The fix can still take twenty minutes. The silence does not have to. See how the incident lifecycle holds the whole response together.