What it is (plain English)
A dedicated response process for the incidents that hurt: highest impact, many users, crucial services down. It adds what a regular ticket can't — a coordinated response team, structured stakeholder communications ("here's what we know, next update at 3pm"), and a post-incident review so the organization actually learns from the event.
Problems it solves
- Big outages handled in improvised group chats with no single person in charge.
- Executives and affected users left guessing while engineers heads-down troubleshoot.
- The same major outage recurring because nothing was captured afterward.
- No clear rule for when an incident is "major," so escalation depends on who's loudest.
What must exist first
Incident Management must be live and settled — major incidents are promoted from regular incidents, and the response process builds on the same groups and data.
What the customer needs to provide
- Clear promotion criteria: what makes an incident "major" for your business (revenue impact, user counts, specific critical services).
- Who runs the show: a major incident manager role or rotation, and whether a dedicated MIM group makes sense for your size and outage frequency.
- Your communication expectations: who must be informed, how often, through which channels.
- Commitment to post-incident reviews — the step that gets skipped and the step that creates the value.
Where it can go next
Every major incident should spawn a Problem Management investigation for root cause. On-Call Scheduling ensures the response team is reachable when the major hits at 2am.