Home / Blog / Outage intake

Playbook · May 28, 2026 · 8 min read

An outage intake playbook that stops issues from stalling

When something breaks, the first minutes decide the day. A good intake process turns a frantic call into a tracked, owned, escalating ticket. A bad one turns it into a voicemail no one hears until the damage is done.

The problem with "just call us"

Plenty of businesses handle outages with a phone number and good intentions. It works right up until the moment it matters most: after hours, during a rush, or when the one person who knows the fix is unreachable. Without structure, urgent issues and routine questions land in the same undifferentiated pile — and the urgent ones lose.

Step 1 — Capture structure, not a paragraph

The first job of intake is to ask the right questions every time, whether a human or an automated receptionist takes the call. Free-form voicemails hide the details that decide priority. Capture, at minimum:

• Location or system affected — which site, line, or service.
• Symptom — what's actually happening, in the caller's words.
• Impact — who and how many are affected right now.
• Reachback — the best number or contact for updates.

Step 2 — Assign severity on a clear scale

Severity is the lever that makes everything else work. Keep it simple enough that anyone can apply it under pressure:

• P1 — a core service is down; people can't work or reach you.
• P2 — degraded but functioning; a workaround exists.
• P3 — minor or cosmetic; no immediate impact.

The point isn't precision — it's a shared language so a P1 never sits behind a P3.

An outage that isn't owned is an outage that's getting worse. The first question is never "what broke" — it's "who has it now."

Step 3 — Route to an owner immediately

Every ticket needs a name attached the moment it's created. Route by severity, location, and the current on-call rotation, and make ownership explicit. "The team" is not an owner. A ticket with a single accountable person moves; a ticket assigned to everyone is assigned to no one.

Step 4 — Escalate on a clock

The difference between a five-minute fix and a five-hour disaster is usually whether escalation happened automatically. Set acknowledgment windows by severity: if a P1 isn't acknowledged in a few minutes, it escalates to the next person, then the next. Escalation should be a property of the system, not a favor someone remembers to do.

Step 5 — Close the loop and learn

When it's resolved, two things happen: the caller gets an update, and the resolution is logged with a timestamp. Over a few weeks, those logs show you where issues cluster, which sites report late, and how fast you actually respond. That's how intake stops being firefighting and starts being improvement.

The one-page version

1. Capture location, symptom, impact, and reachback — every time.
2. Assign P1/P2/P3 with a shared, simple scale.
3. Give every ticket a single named owner at creation.
4. Escalate automatically when acknowledgment windows lapse.
5. Update the caller, log the resolution, and review the patterns.