Introduction

If your team manages production systems, incidents are inevitable. What is optional is the chaos that often comes with them: vague tickets, unclear ownership, mysterious priorities, and silent pileups of “small” problems that suddenly turn into big ones.

One way to bring order to this chaos is to think of incident management like running an old-school post office.

Every incident is a letter. Your team is the sorting center. Your stakeholders are the recipients who need clear, timely delivery.

By embracing this postal metaphor, you can design an incident intake and handling system that’s visual, predictable, and hard to ignore—so outages get sorted and resolved before they’re sitting in an overflowing pile at your team’s doorstep.

Step 1: Treat Every Incident Like an Incoming Letter

In many organizations, incidents arrive through a mess of channels: Slack pings, DMs, emails, vague complaints in meetings, error dashboards. This is like people throwing mail directly at postal workers instead of using a mailbox.

Goal: All incidents enter through a single, predictable “mail slot.”

Think of your incident intake as a physical post office counter:

1. Mailbox / Intake Form

   • One channel (or as few as possible) where all incidents get logged.
   • Example: a dedicated /incident Slack command, a simple web form, or a Jira/ServiceNow “New Incident” template.

2. Stamping the Envelope (Initial Logging)
   Every new incident must be:

   • Timestamped (when was it first observed?)
   • Given a unique ID (incident number)
   • Briefly described (what’s visibly wrong?)

3. No Orphan Letters
   If an issue isn’t in the system, it doesn’t exist. Train everyone: “If it’s not logged, it’s not an incident.” This prevents silent, informal work that never makes it into your queue—and later surprises you.

Step 2: Define Severity Levels Like Postal Classes

Post offices don’t treat all envelopes the same. There’s standard mail, priority mail, express mail. Your incidents need the same structure.

Define clear severity levels based on impact and urgency, for example:

• SEV0 – Critical (Express Overnight)

  • System-wide outage, major revenue impact, or legal/compliance risk.
  • Immediate, all-hands-on-deck response.

• SEV1 – High (Priority Mail)

  • Significant degradation, many users impacted, but partial functionality remains.
  • Fast response within defined SLA.

• SEV2 – Medium (Regular Mail)

  • Limited impact, workarounds available, or affects a subset of users.
  • Scheduled resolution in planned windows.

• SEV3 – Low (Bulk Mail)

  • Cosmetic issues, minor inconveniences, or internal-only quirks.
  • Addressed as capacity allows.

When a new “letter” arrives, your intake person (or automation) stamps it with a severity class. This determines:

• Who must be notified
• How quickly it must be addressed
• What level of ceremony (war room, status page, etc.) is required

This avoids endless arguments like, “Is this actually urgent?” You’ve pre-agreed on what “urgent” means.

Step 3: Assign Clear Roles in Your Sorting Center

In a post office, not everyone does everything. There’s intake, sorting, routing, local carriers. Incident response should be just as structured.

Typical roles include:

• Incident Commander – The floor manager. Owns coordination, decisions, and status. One per incident.
• Triage Engineer – The sorter. Confirms impact, gathers data, and routes work to the right specialists.
• Functional Responders – The carriers. Database, frontend, infra, security, etc., who do the hands-on investigation and fixes.
• Communications Lead – The postal clerk at the window. Keeps stakeholders updated and manages announcements.

The rule: each incident gets an explicit owner, just like each letter has an address. If ownership is unclear, it’s like mail with no destination label: it will sit somewhere, forgotten.

Step 4: Visualize Flow with a Kanban Board

Imagine if a post office had no bins, no shelves, no visual cues—just piles of letters on the floor. That’s what your backlog looks like in many teams.

A kanban-style board gives you the equivalent of sorting shelves:

• Waiting (Inbox) – New incidents logged but not yet triaged.
• In Progress – Being actively worked on.
• Completed – Resolved and closed.

Even a simple board like this makes invisible work visible:

• You see when the inbox is overflowing.
• You spot when things are stuck in progress for too long.
• You make it hard for incidents to simply disappear.

You can implement this in tools like Jira, Trello, Linear, or a custom incident app—as long as it’s always visible to the team.

Step 5: Break “In Progress” into Detailed Postal Stages

For more complex environments, “In Progress” is too vague. It’s like having a sign that says “Somewhere in the mail system.” You need to know where things are stuck.

Break “In Progress” into multiple columns that map to your incident lifecycle:

• Detected – Issue observed and logged.
• Triage in Progress – Validating the incident, confirming impact, setting severity.
• Escalated / Assigned – Routed to the right team or specialist.
• Mitigating – Implementing a fix or workaround.
• Monitoring – Watching the system to ensure stability post-fix.
• Ready for Closure – Fix confirmed; documentation and follow-up tasks pending.

This level of granularity gives you:

• Bottleneck visibility – Is triage slow? Are escalations piling up? Are fixes done but never closed?
• Capacity signals – Maybe you need more people for detection or better tooling for triage.

Just as a postal system tracks a package through each depot, your incident workflow should track each issue through clearly named stages.

Step 6: Treat Communication Like Delivery Routing

Incidents aren’t just technical problems; they’re also communication problems. In the postal metaphor, communication is the delivery route.

Each incident should have:

• A clear address label:

  • Owner: Who is responsible for getting this to resolution?
  • Stakeholders: Who needs to be informed (product, support, leadership, customers)?

• Defined routes and cadences:

  • For SEV0: updates every 15–30 minutes.
  • For SEV1: hourly or as milestones occur.
  • For SEV2/3: daily or at key points.

• Standard message formats:
  Use structured updates, for example:

  • What happened
  • Who is impacted
  • What’s being done now
  • Next update time

If you don’t define this, you get the communication equivalent of misdelivered or lost mail: rumors, duplicated work, and frustrated customers.

Step 7: Build (or Adopt) an Incident “Post Office” App

You can work with whiteboards and spreadsheets, but over time it helps to encode your postal metaphor in a dedicated app.

Your incident tracking and postmortem tool should:

• Capture all the metadata you care about (severity, owner, impact, affected systems, timelines).
• Implement your workflow stages (Detected → Triage → Escalated → Mitigating → Monitoring → Completed).
• Integrate with your communication channels (Slack, email, status pages).
• Support postmortems/post-incident reviews linked directly to incidents.

Whether you customize an off-the-shelf tool or build your own, the principle is the same: make your app function like a digital post office—letters in, stamped, sorted, routed, tracked, and archived.

Step 8: Use Post-Incident Reviews as “Return to Sender” Feedback

Post-incident reviews are where your postal system learns.

Think of them as “return to sender” loops:

• Which incidents were misclassified (wrong severity stamp)?
• Where did routing break down (sent to the wrong team, or bounced around)?
• Which types of “mail” keep coming back (repeated incidents with the same root cause)?
• Where did communication fail (stakeholders surprised, customers uninformed)?

A good post-incident review doesn’t just ask, “What broke?” It asks:

• How could we have detected this sooner? (Better mail slots and sensors.)
• How could we have routed it better? (Clearer addresses and sorting rules.)
• How could we make handling it easier next time? (Runbooks, automation, training.)

Each review is a chance to update your sorting rules, routing paths, and handling procedures so fewer incidents get lost or delayed the next time.

Conclusion

Running incident response without structure is like running a post office without bins, routes, or stamps. Things may move, but not reliably, and certainly not predictably.

By treating your incident system like a post office for outages, you can:

• Standardize how incidents enter your world (mail slots, not chaos).
• Classify and prioritize them using clear severity “classes.”
• Visualize their flow through a kanban board and detailed stages.
• Route communication to the right people at the right time.
• Continuously improve with post-incident “return to sender” loops.

You don’t need perfect tools to start. You need a shared mental model.

Begin with the metaphor: every incident is a letter, and your job is to make sure no letter gets lost—stamped, sorted, routed, delivered, and learned from before the next batch arrives at your team’s doorstep.