Where your support escalation typically breaks

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 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 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

Two accounts share an email domain (a parent and its subsidiaries, a reseller and its customers, a consultancy that supports several clients). The ticket lands on one of them, so targets, escalation and the "open issues" count go to the wrong account and the wrong owner.

Why it happens. In some tools, domain matching picks one account when several fit, and the person writing in is not asked which account they mean.

Usually fixed by: CRM admin (account structure), with support operations (matching and manual override).
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

An hourly rule for late tickets either alerts again and again about the same ticket, or does not alert at all on a busy day. After a week of noise people mute it, and the one ticket that matters is missed.

Why it happens. In some tools, time-based rules run on a schedule, match again on every run unless they change something on the ticket, and can act on only a set number of tickets per run. Whether other tools repeat or fire once is our reading.

Usually fixed by: Support operations (rule design) or the help desk admin.
Kind of break, one of six: Freshness: is the step still running, and on time? Count: do the numbers at each end agree?
Sources: 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