Where your support escalation typically breaks

A ticket is parked in a "waiting" or "on hold" status because engineering has it, and the target stops counting. The customer has heard nothing for days and the report still shows the ticket as on time.

Why it happens. In some tools a target pauses on a "waiting" status because that status was meant for "waiting on the customer", and teams also use it for "waiting on us". Which targets pause differs by tool and by target.

Usually fixed by: Support operations (statuses and which targets pause), with the support lead (what each status means).
Kind of break, one of six: Freshness: is the step still running, and on time? Condition: does a rule that should always hold, hold?
Sources: Vendor documentation · Vendor documentation · Vendor documentation

The rota has gaps (nights, weekends, holidays, hand-over hours). A late or critical ticket is escalated to the rota and, in the gap, nobody receives it, or it is sent on to a second level that nobody checks.

Why it happens. Rotas are built to cover working shifts, and the rule that escalates to them was written assuming that someone is always on it. In some on-call tools, an hour with nobody on call means nothing is created at all. How a rota kept in a spreadsheet behaves is our reading.

Usually fixed by: The support lead or the rota owner, with the admin of the tool that holds the rota.
Kind of break, one of six: Arrival: did it show up in the next tool in time? Condition: does a rule that should always hold, hold?
Sources: Vendor documentation

A customer writes from a personal address, a different part of the company's domain, or before the account was set up, and the ticket sits with no account on it. The response targets, the escalation to the account's owner and the per-account counts all depend on that account, so none of them fire.

Why it happens. Tickets are matched to accounts by the sender's email address or domain, and that match fails for personal addresses, subdomains and people who wrote before the rule existed.

Usually fixed by: Support operations (matching rules), with the CRM admin (account domains and contact records).
Kind of break, one of six: Field landed: did each field arrive with a value, in the right place? Arrival: did it show up in the next tool in time?
Sources: Vendor documentation · Vendor documentation

A ticket arrives with no priority, or the customer's plan is not part of the rule, and either no response clock starts or the slowest default applies. A premium customer's ticket then waits like everyone else's, and nothing marks it as late.

Why it happens. In some tools the targets are keyed to the priority field and to the first rule whose conditions match, and nobody checked what happens to tickets that fit no rule. Whether your plan or tier is wired into the rules is our reading.

Usually fixed by: Support operations (intake rules, target rules), with the account owner (which plan gets which target).
Kind of break, one of six: Field landed: did each field arrive with a value, in the right place? Condition: does a rule that should always hold, hold?
Sources: Vendor documentation · Vendor documentation · Vendor documentation

A critical or late ticket is escalated to the support lead or the engineering channel. The person who owns the customer relationship, and who would call the customer, learns about it from the customer, days later.

Why it happens. The people the help desk can notify are its own agents, while account owners live in the CRM, and nothing looks up the owner of the ticket's account. In some tools escalation reaches the assigned agent or a supervisor; whether it can reach someone who is not a help desk user varies by tool (our reading).

Usually fixed by: Support operations with the head of account management.
Kind of break, one of six: Arrival: did it show up in the next tool in time?
Sources: Vendor documentation

The ticket is tagged as a bug but nobody creates the issue, or it is made by copy and paste with no link back. Engineering never sees it, or sees it with no customer, plan or urgency attached.

Why it happens. Creating and linking the issue depends on the agent doing it by hand, and on every agent having an account in the engineering tracker (our reading).

Usually fixed by: Support operations with the engineering manager (intake rule).
Kind of break, one of six: Arrival: did it show up in the next tool in time?
No public source found for this one: it is our reading of how these hand-offs usually work.