Build an MSP major incident communication process

Why major incident communication breaks down

Most MSPs have a technical incident process. Fewer have a communication process that survives the first 20 minutes of a major outage.

The common failure pattern is familiar: phones spike, clients open duplicate tickets, engineers post updates in Teams, dispatchers chase status manually, and account managers ask for a client-facing summary that no one has time to write. By the time the root cause is found, the service desk has spent as much energy managing confusion as resolving the issue.

An MSP major incident communication process solves a different problem than escalation. Escalation decides who works the incident. Communication decides what every affected person is told, through which channel, at what cadence, and from which system of record.

For MSPs, this matters because every major incident crosses multiple boundaries at once: internal teams, client contacts, executive stakeholders, vendors, monitoring systems, and the PSA. If those boundaries are not designed ahead of time, they become bottlenecks during the incident.

Define what counts as a major incident

Start with a simple definition your dispatchers and technicians can apply without debate.

A major incident is not just a high-priority ticket. It is an event that affects multiple users, a critical business function, a shared service, or a contractual commitment. Examples include:

• Microsoft 365 outage affecting several clients
• Client firewall failure stopping site connectivity
• Ransomware indicators or confirmed security compromise
• Line-of-business application unavailable for a department
• Backup platform failure across multiple protected systems
• Cloud hosting outage affecting production workloads

Create two or three severity levels, not ten. For example:

• Sev 1: Business-stopping, security-impacting, or multi-client outage
• Sev 2: Critical function degraded with workaround available
• Sev 3: Significant impact, but isolated or contained

Each level should define who is notified, how often updates are sent, and who can approve external communication.

Assign communication roles before the outage

During a major incident, the technical lead should not also be responsible for answering every client message. Split the work.

A practical MSP incident team usually includes:

• Incident commander: owns coordination, decisions, and internal timeline
• Technical lead: owns diagnosis, work plan, and engineering assignments
• Communications lead: owns client updates, phone scripts, chat responses, and email wording
• Dispatcher or service coordinator: watches queues, deduplicates tickets, and routes new reports
• Account or client success contact: handles executive stakeholder expectations for strategic accounts

In a small MSP, one person may cover multiple roles. That is fine. The important point is that each role is explicit. When a Sev 1 starts, no one should ask who is allowed to send the first client update.

Build one incident record in the PSA

Every channel should feed one controlling incident record. Without that, the team ends up with dozens of related tickets and no authoritative timeline.

The controlling record should include:

• Incident summary and severity
• Affected clients, locations, users, and services
• Start time, detection source, and first response time
• Current status and next update time
• Internal timeline of actions taken
• External updates sent, with timestamp and audience
• Related tickets, calls, chats, alerts, and vendor cases
• Resolution summary and post-incident tasks

This is where many PSA workflows struggle. The process depends on clean classification, related-ticket handling, and useful summaries. Corei’s autonomous tickets are designed for this kind of intake work: classifying, routing, summarizing, and connecting related work without requiring a dispatcher to manually touch every item.

Whether you use Corei or another PSA, the rule should be clear: no major incident lives only in email, chat, Teams, or a vendor portal. The PSA needs the record.

Phone intake: capture reports without flooding dispatch

Phone calls are often the first signal that a client-impacting incident is larger than one user. They are also the fastest way to overwhelm a dispatcher.

Your process should define what happens when calls spike around the same symptom. The phone workflow should capture:

• Caller name, company, and callback number
• Reported symptom in the client’s words
• Location, device, application, or service affected
• Whether the caller is reporting a new issue or asking for an update
• Whether the issue matches an active major incident

For active incidents, the goal is not to create a unique troubleshooting path for every caller. The goal is to acknowledge the report, associate it with the incident, provide the approved update, and avoid distracting engineers.

This is one reason AI phone intake is useful during outages. With AI phone intake, calls can be answered, captured, summarized, and converted into tickets or attached context without every caller waiting for a human dispatcher.

Phone scripts should be short. For example:

• We are aware of the issue affecting access to email for your organization.
• Our team is actively working the incident under priority status.
• The next update is scheduled by 10:30 a.m., or sooner if there is a material change.
• We have linked your report to the incident record.

Avoid speculative root cause language on the phone. If the cause is not confirmed, say so.

Chat: give clients a fast path without losing control

Client chat can reduce phone volume, but only if it follows the same source of truth. During an incident, chat should not become a separate support lane with different information.

Your chat process should include three modes:

1. Normal intake, where each issue is handled as a standard support request.
2. Incident-aware intake, where clients asking about a known outage receive the approved status and are linked to the incident.
3. Escalated chat, where a human joins because the client has a distinct symptom, executive concern, or urgent business impact.

A controlled client chat experience helps because it gives users somewhere to go besides the phone queue. Corei’s client support chat is built for MSPs that want client-facing chat while keeping control over what is said, what becomes a ticket, and what is connected back to the PSA.

For major incidents, prepare chat snippets in advance:

• Acknowledgment snippet
• Known impact snippet
• Workaround snippet
• Next update snippet
• Resolved but monitoring snippet

The communications lead should own these snippets, not each technician individually.

Email: use cadence, not one-off reactions

Email remains the best channel for structured updates, especially when client executives, department leads, or multiple contacts need the same message.

The biggest mistake is waiting until there is a complete answer. In a major incident, silence creates more tickets. Your first update should go out quickly once the incident is confirmed, even if the only confirmed facts are impact, ownership, and next update time.

A simple cadence works:

• Initial notice: within 15 to 30 minutes of confirmation for Sev 1 incidents
• Progress updates: every 30 to 60 minutes, depending on severity
• Material change updates: immediately when scope, workaround, or estimated restoration changes
• Resolution notice: once service is restored or stable
• Post-incident summary: within one to three business days for major client impact

Each email should answer five questions:

• What is affected?
• Who is affected?
• What is the current status?
• What should the client do or avoid doing?
• When is the next update?

Do not bury the next update time. It is one of the most important parts of the message because it reduces follow-up requests.

PSA tickets: deduplicate, relate, and summarize

During a major incident, the PSA can either clarify reality or hide it. The difference is how you manage related work.

Create a standard rule: new tickets that match the incident should be related to the master incident, not worked as isolated break-fix tickets unless they show a distinct issue. The service coordinator or automation should check incoming tickets for matching symptoms, clients, locations, and services.

Good ticket hygiene during a major incident includes:

• A standard incident tag or type
• One parent or master incident record
• Related child tickets for affected users or clients
• Internal-only notes for technical actions
• External-facing notes approved by the communications lead
• A required resolution summary before closure

Dashboards matter here. Service leaders need to see the volume of related tickets, SLA exposure, client impact, and open follow-ups without asking the desk for manual counts. Operational views like Corei dashboards help managers track the incident while work is still moving.

Create templates for the moments that matter

Templates are not about sounding generic. They prevent mistakes when the team is under pressure.

At minimum, create templates for:

• Initial incident acknowledgment
• Client-specific impact confirmation
• Workaround instructions
• Vendor escalation notice
• Security-sensitive notice
• Resolution and monitoring notice
• Post-incident review summary

Each template should include placeholders for confirmed facts only. Avoid fields that invite guessing, such as estimated time to resolution, unless your team has a rule for when that estimate is allowed.

Also create internal templates. The incident commander needs a standard way to capture timeline entries, decision points, vendor interactions, and next actions.

Use automation carefully, with approval where needed

Automation can help during major incidents, but it should not be allowed to improvise client-facing claims. The safest pattern is to automate collection, routing, linking, drafting, and reminders, while requiring approval for sensitive external updates.

Good candidates for automation include:

• Detecting a spike in similar tickets or calls
• Creating a proposed major incident record
• Linking related tickets and chats
• Drafting summaries from call notes and ticket updates
• Reminding the communications lead when the next update is due
• Updating internal dashboards and gauges
• Creating post-incident review tasks

For MSPs using AI-assisted operations, governance is critical. Agentic workflows should be readable, approvable, and auditable so service leaders know what the system did, why it did it, and where human approval was required.

Measure the communication process after each incident

The post-incident review should not only examine the technical cause. Review communication performance too.

Track metrics such as:

• Time from detection to incident declaration
• Time from declaration to first client update
• Number of duplicate tickets created
• Percentage of related tickets correctly linked
• Number of inbound calls after each update
• Missed update cadence events
• Client complaints about clarity or timeliness
• Time to final incident summary

These measures reveal whether your process reduced uncertainty or added to it.

Also review message quality. Were updates accurate? Did they say what was known and unknown? Did clients know what to expect next? Did internal teams have the same information as external stakeholders?

Practical takeaway: build the process in layers

Do not try to redesign everything at once. Start with a working version your team can actually follow.

A strong first version of an MSP major incident communication process includes:

• A simple severity model
• Named incident roles
• One PSA master incident record
• Phone, chat, email, and ticket handling rules
• Pre-approved update templates
• A defined update cadence
• A dashboard view for service leaders
• A post-incident communication review

Once that is stable, add automation for intake, deduplication, summarization, reminders, and reporting.

The goal is not to make incidents painless. The goal is to make them controlled. Clients can tolerate a hard technical problem when they believe the MSP is organized, honest, and ahead of the next question. A clear communication process is how you prove that under pressure.