Workflow break check · your result
Where your support escalation typically breaks
These are the places setups like yours usually fail; they are not findings about your systems, since nothing here looked at them. Each one comes with a way to check it yourself. Navceed is being built to run checks of these six kinds; today it runs them on an example company, and connecting your own tools is coming next.
1 check first
1 more
2 check first
1 more
1 check first
3 more
1 check first
1 also check
1 check first
1 more
1. The ticket has no priority or plan, so it gets no target, or the wrong one
Check firstTargetsRun by support opsabout 20 min
Shown because you answered “Agents set the priority by hand when they pick the ticket up”; “There is no such rule”.
How to check, and why it happens
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
2. The clock is stopped while the customer is still waiting on you
Check firstTargetsRun by support opsabout 15 min
Shown because you answered “It is also used for tickets waiting on engineering or another team”; “There is no such rule”.
How to check, and why it happens
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
3. The account's own owner never hears about the escalation
Check firstEscalationYou can run thisabout 20 min
Shown because you answered “Nobody is told; someone watches the queue”; “Someone notices and tells us”.
How to check, and why it happens
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
4. A ticket that needs engineering never gets an engineering issue
Check firstEngineeringRun by support opsabout 20 min
Shown because you answered “Agents copy the text across to the engineering tracker by hand”; “Someone notices and tells us”.
How to check, and why it happens
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.
5. The account page shows the wrong number of critical issues
Check firstAccount viewRun by your help desk adminabout 15 min
Shown because you answered “An agent picks the account by hand”; “Agents copy the text across to the engineering tracker by hand”.
How to check, and why it happens
The CRM account shows zero open critical issues when there are some, or still shows one after it was fixed. The account owner prepares a renewal or a call on the wrong picture.
Why it happens. In some tools a count on an account is built from linked records filtered by status and priority. An unlinked ticket, a renamed status or a delayed update changes the number (our reading).
Usually fixed by: The CRM admin with support operations (what counts as open and critical).
Kind of break, one of six: Count: do the numbers at each end agree? Field landed: did each field arrive with a value, in the right place?
Sources: Vendor documentation
6. The ticket arrives and is tied to no customer account
Check firstIntakeRun by support opsabout 20 min
Shown because you answered “Someone notices and tells us”; “An agent picks the account by hand”.
How to check, and why it happens
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
Show more (7)
7. The ticket is tied to the wrong customer account
Check firstIntakeRun by support opsabout 20 min
Shown because you answered “There is no such rule”; “An agent picks the account by hand”.
How to check, and why it happens
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
8. A failed payment or a churn-risk signal does not reach the account's owner
Check firstAccount viewRun by your help desk adminabout 20 min
Shown because you answered “Someone notices and tells us”; “An agent picks the account by hand”.
How to check, and why it happens
A customer's payment fails or their health score drops, and the CRM is flagged or a message goes to a shared inbox. The person who owns the account does not hear until the next review or until the customer cancels.
Why it happens. The signal is created in the billing or usage tool and has to find the account, then its owner, then notify them; a failed delivery or a missing link at any point leaves it unseen. In some billing tools, events are retried for a limited time only.
Usually fixed by: Revenue operations with finance (billing link) and account management.
Kind of break, one of six: Arrival: did it show up in the next tool in time? Freshness: is the step still running, and on time?
Sources: Vendor documentation
9. The targets follow old rules or the wrong working hours
Check firstTargetsRun by support opsabout 20 min
Shown because you answered “There is no such rule”; “Agents set the priority by hand when they pick the ticket up”.
How to check, and why it happens
A target rule or a working-hours calendar is changed, but tickets already open keep the old numbers. Tickets over a weekend or holiday show a due time that does not match what the customer was promised.
Why it happens. Working-hours calendars, holidays and target rules are separate settings, and in some tools a change reaches an open ticket only when something else updates it.
Usually fixed by: Support operations (calendar and rules), with the support lead (what was promised to customers).
Kind of break, one of six: Condition: does a rule that should always hold, hold? Freshness: is the step still running, and on time?
Sources: Vendor documentation · Vendor documentation · Vendor documentation
10. The escalation names someone who has left or is away
Check firstEscalationRun by your help desk adminabout 15 min
Shown because you answered “Someone notices and tells us”; “Nobody is told; someone watches the queue”.
How to check, and why it happens
The rule sends the alert to a named person, a ticket owner or an account owner who has left, been switched off or is on leave. Their tickets move to a shared group or pile up, and the alert goes to an inbox nobody reads.
Why it happens. Escalation rules and account-owner fields are filled in by name, and they are not part of the leaver checklist. In some tools a deleted agent's tickets fall back to a shared group; the case of someone who is only away is our reading.
Usually fixed by: The admin of each tool, with the support lead and account management (leaver checklist).
Kind of break, one of six: Condition: does a rule that should always hold, hold? Arrival: did it show up in the next tool in time?
Sources: Vendor documentation
11. The escalation goes to a duty rota with nobody on it
Check firstEscalationRun by support opsabout 15 min
Shown because you answered “Someone notices and tells us”.
How to check, and why it happens
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
12. The late-ticket alert repeats until people ignore it, or stops firing
Worth a quick lookEscalationRun by support opsabout 15 min
Shown because you answered “Nobody is told; someone watches the queue”; “Monthly, quarterly or at close”.
How to check, and why it happens
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
13. "Closed" in engineering is read as "fixed", even when it was cancelled
Worth a quick lookStatus backRun by support opsabout 15 min
Shown because you answered “I'm not sure, to: How would you notice that a field arrived blank, or in the wrong place?”.
How to check, and why it happens
An issue is closed because it was cancelled, duplicated or declined, and the ticket is updated or solved as if the problem were fixed. The customer may be told it is done when it is not.
Why it happens. The status mapping between the tools counts every finished state the same. In some tools both "done" and "cancelled" trigger the ticket update; what the customer is then told depends on what the team does next (our reading).
Usually fixed by: Support operations with the engineering manager (agree what each closed state means to the customer).
Kind of break, one of six: Return path: does what the next tool did get back to the first? Field landed: did each field arrive with a value, in the right place?
Sources: Vendor documentation
The common questions follow six kinds of check: Arrival (did it show up in the next tool in time?), Return path (does what the next tool did get back to the first?), Count (do the numbers at each end agree?), Freshness (is the step still running, and on time?), Field landed (did each field arrive with a value, in the right place?), Condition (does a rule that should always hold, hold?).
Checking by hand does not last
Everything above is a one-off look. The breaks that cost you are the ones that start next Tuesday, when someone changes a field.
No sign-up was needed for this page and nothing you chose was saved. Print this page to keep it. Start again.