Escalation Boundary Mapping (Onboarding)

Escalation Boundary Mapping (Onboarding)

1. 01

   Inventory every ticket type the client's queue received in the trailing 90 days

   Pull raw exports rather than dashboard summaries so refund disputes, billing errors, and password resets are counted separately instead of collapsing into one 'support' bucket.

2. 02

   Rank ticket types by emotional charge and refund or legal exposure, not by volume alone

   A 40-ticket-per-month chargeback thread carries more escalation risk than 4,000 password resets, and routing logic built on volume alone will misclassify it.

3. 03

   Write the auto-resolve list and cap it at the categories with a documented first-contact resolution rate above 70%

   Forethought's Triage Agent and similar classifiers will happily accept any category you hand them; the cap is a client-protection decision, not a technical one.

4. 04

   Define the human-only list explicitly, covering anything involving account closure, legal threats, or a named account manager

5. 05

   Set the confidence threshold that forces handoff and record it in the client-facing scope document

   A 144.3M-parameter decision model such as Julia 1 can rank options across 52 locales, but the threshold is what stops a low-confidence multilingual ticket from being answered in the wrong language.

6. 06

   Name the escalation owner on the client side and the on-call agent on the agency side, with response windows in hours

   Two named people and a stated window beat a shared inbox; unresolved ownership is the most common reason triage pilots stall in month two.

7. 07

   Rehearse three real escalated tickets end to end before go-live and log where the automation dropped the thread

   Use tickets the client already resolved manually so you can compare the automated path against a known-good outcome.