Support-Signal Escalation Playbook 2026

Build the benchmark once, refresh it quarterly (the benchmark play covers it in full):

1. Comparison customers: same segment (plan tier, size band), 12+ months as customers, renewed at the same or higher revenue. Aim for 20; with fewer, label it low confidence.
2. Support load: tickets per seat per month – their median. Your support lead approves it.
3. Usage: their median share of seats active each week – the same figure the weekly check uses.

This play is the exception to the weekly rhythm. It runs daily, or on each new ticket, because a support problem can get worse by the day. Default trigger: the last 14 days' tickets, doubled to a monthly rate, divided by seats – at twice the benchmark or more. Tune it to your queue.

Say an account pays $30,000 a year for 40 seats and renews in four months. Customers its size file about 0.2 tickets per seat a month – eight tickets – and keep about 28 of 40 seats active each week. This one filed 19 in ten days, 12 about exports, and weekly active seats fell from 30 to 21. (The numbers are illustrative.)

Under about a hundred accounts, do it by hand.

• Core work blocked? Is the broken thing the job they bought you for, or an edge? Ask support if the tags don't say.
• Champion affected? Did your main contact file or get copied on the tickets?
• Root-cause theme: what most of the tickets are about, in a few words.
• Known incident? An outage or bug hitting every customer has its own process and status page.

Escalate, by default, if any of these hold: core work blocked, the champion affected, weekly active seats a fifth or more below the benchmark, or renewal inside 120 days. Everything else is contained, including heavy users at or above the usage benchmark. High usage alone is not a reason to escalate or dismiss tickets. Check what's blocked, who's affected, and whether ticket volume has changed relative to usage. Write the line down so escalation is a rule, not a debate.

Support raises the priority of the account's open tickets, and sets an Account impact field on the organization so new tickets from it arrive at that priority. On the record, set Recommended move to No move, the reason in one line, and Review date two weeks out. Nobody gets a Slack message. The leave-it-alone play covers the decision in full.

One Slack message to both, with a link to the account record and the tickets. Slack is the alarm; the plan and everything after it live on the record, so the next person to open the account sees what happened.

• Fix known: support has a fix or workaround with a date, or it's a known incident with a status page. Proactive update.
• Not yet: the cause is unclear or the fix has no date. Joint plan and a call with the champion.

The note below, sent before the customer asks for one. If updates go out on a set rhythm until the fix ships, your team may choose to automate them; the record shows what went out.

The plan below: who fixes (support, with engineering), who talks to the customer (the CSM), and how often the customer hears from you until it's solved. Then the call invite.

They change the draft or run it as written, the same day. The CSM owns every customer conversation. Before acting, record the success measure and a review date eight weeks out: the update sent is activity; tickets back under the benchmark in two weeks is progress; weekly active seats back and the renewal signed are the result.

Eight weeks on, record in Review result whether support load and usage came back, and what else played a part. If nothing moved, change the plan, stop it, or give it time; the eight-week review covers how. Where practical, randomize the timing of moves across equally eligible accounts. Otherwise, compare similar triggered accounts over the same window and label the result observational. For contained accounts: did any later escalate? Each one means the line needs tuning. Send the month's root-cause themes to product.