Prism

Escalation Management

Prism Customer Success Handbook — Section 2.7

What an escalation is

An escalation is an explicit declaration that an account needs elevated, cross-functional attention beyond normal process. It is operational: something is broken or breaking now, normal channels aren't sufficient on their own, and someone must own coordination until it's resolved.

Escalation is deliberately distinct from two things it's often confused with:

  • A support ticket, however severe. Support works tickets in queue by severity. A P1 ticket is not automatically an escalation — it becomes one when it needs coordination Support can't provide alone, or when its business context (an at-risk account, an imminent renewal) demands CS ownership.
  • Health decline. That's a customer-outcome problem, worked by playbook over weeks (3.1 Health Decline). Escalation is an operational problem worked over hours or days.

The test: does this need someone to actively coordinate a response across functions, right now? If yes, it's an escalation. If it's moving through normal process at acceptable speed, it isn't — labeling it one just dilutes the term.

Who can open one

  • The CSM — on observing something that warrants coordinated response
  • Support — when a ticket exceeds what queue handling can resolve, or hits an account CS has flagged
  • The customer — when they explicitly escalate

"The customer escalated" and "we escalated internally" are different events and are logged distinctly. A customer escalation is also a relationship signal, not only an operational one — it means normal channels left them feeling unheard.

Severity

Escalations use the same P1–P4 tiers as support (1.6 Health Scoring Methodology). One severity vocabulary across Support and CS is the entire point of shared definitions — a parallel scale would reintroduce the ambiguity the tiers exist to remove.

What an escalation adds on top of the ticket's severity is coordination ownership and comms obligations, not a different rating.

Tier In escalation terms
P1 Client-facing breakage or an account in crisis. Immediate coordinated response.
P2 Significant problem threatening the relationship or a near renewal. Same-day ownership.
P3/P4 Rarely escalations on severity alone — but a low-severity issue on an at-risk account, or one the customer has escalated, can warrant it for relationship reasons.

Severity is assigned honestly. Inflating severity to command attention breaks the signal chain for everyone. If a P3 needs escalation, escalate the P3 — don't relabel it a P1.

Roles during an escalation

Role Responsibility
Owner Coordinates the response, runs comms, drives to resolution. Usually the CSM for account-facing escalations; may be Support lead for purely technical ones. One owner, always.
Resolver(s) Whoever does the technical or commercial fix — Support, SE, Product, Sales, by type
Director of CS Notified on any P1; pulled in for executive-to-executive contact or commercial authority

The owner owns coordination, not necessarily the fix. Their job is that the right people are working it and the customer knows what's happening — not to personally resolve a database issue they're not equipped to touch.

Comms cadence

The part that makes escalation real rather than a label.

Severity Customer update Internal sync
P1 Every 4 business hours until resolved Daily until resolved
P2 Daily Every other day
P3/P4 On meaningful change As needed

Update on schedule even when there is no news. "Still working it, here's where we are, here's what's next" preserves trust. Silence destroys it — and silence is what customers actually complain about after an incident, more than the incident itself. A customer who hears from you every four hours during an outage remembers being taken seriously; a customer who hears nothing for a day remembers being abandoned.

Every update is logged as an activity.

Exit

Escalations that fade out instead of closing are the norm in undisciplined functions, and they're corrosive: nobody learns anything, and the customer never gets closure. Every escalation has a defined exit.

An escalation is closed only when:

  1. The problem is resolved — technically and, where relevant, commercially
  2. Resolution is confirmed with the customer — not assumed. "We think it's fixed" is not closure; "we confirmed with them it's working" is.
  3. A post-mortem is completed for every P1 — what broke, why, how it was handled, what prevents recurrence
  4. Closure is logged, with the escalation's full timeline intact for the account record

The confirmation step matters most. Closing an escalation the customer still considers open is how a resolved incident becomes a trust problem.

Post-mortems

Required for every P1, optional but encouraged for P2s that got messy.

A post-mortem covers: timeline, root cause (not just proximate cause), how the response went, and — most usefully — whether the escalation should have been caught earlier. A P1 that a health signal or support pattern could have predicted is a feedback item for the quarterly system review (2.3 Operating Rhythm): the model missed something it could have caught.

Post-mortems are not blame exercises. Their output is a change — to a trigger, a process, a product gap routed to Product (2.8 Voice of Customer & Product Feedback) — or an explicit finding that nothing systemic went wrong.

How escalations interact with the rest of the system