Support Escalation Prediction
“Which tickets will escalate to engineering?”
Book a demo and get a free trial of the full platform: research agent, fine-tune capabilities, and forward-deployed engineer support.
By submitting, you accept the Terms and Privacy Policy.
Loved by data scientists, ML engineers & CXOs at
A real-world example
Which tickets will escalate to engineering?
Engineering escalations cost 8x more than L1 resolutions and take 5x longer. A SaaS company handling 5,000 tickets per month where 12% escalate spends $3.6M annually on engineering support time. Late escalations are worse: tickets that should have been escalated immediately but bounced through L1/L2 first have 3x longer MTTR and generate 2x more negative NPS responses. The escalation signal is in the intersection of ticket content, the reporting account's product usage anomalies, and recent deployment history.
Quick answer
Escalation prediction requires connecting ticket metadata, account product telemetry, user history, and recent deployment data in a relational model. Tickets from accounts experiencing recurring API errors, filed by users with prior escalation history, about recently deployed features escalate at 9x the base rate. Routing these tickets directly to L2/L3 reduces mean time to resolution (MTTR) by 45%.
Approaches compared
4 ways to solve this problem
1. Priority-based routing
Route tickets based on the priority tag set by the submitter. P1 goes to senior agents, P2-P3 to the general queue.
Best for
Simple and transparent. Ensures critical issues get senior attention when customers accurately set priority.
Watch out for
Customers either over-prioritize (everything is P1) or under-prioritize (a genuine production bug marked P3). The priority tag reflects customer frustration, not actual escalation likelihood.
2. Text classification on ticket content
Train an NLP model on ticket descriptions to predict escalation probability based on language, keywords, and sentiment.
Best for
Catches tickets with specific technical language that correlates with complex issues. Works across all ticket types.
Watch out for
Ticket text alone lacks context. 'API returning 500 errors' sounds the same whether it is a user misconfiguration or a platform-wide regression after a deployment. The product telemetry and account context tell you which it is.
3. Historical escalation rates by category
Calculate escalation rates by ticket category (API, performance, billing) and route high-escalation categories to senior agents by default.
Best for
Data-driven routing that is simple to implement and maintain. Works when escalation patterns are stable across time.
Watch out for
Category averages hide variance. An API ticket from an account with zero product errors is very different from an API ticket from an account experiencing 7 recurring 500 errors. The category is the same, but the escalation probability is 3x different.
4. KumoRFM (relational graph ML)
Connect tickets, accounts, users, product events, and agents into a graph. The GNN learns that ticket context plus product telemetry plus user history predicts escalation with 91% accuracy.
Best for
Highest accuracy because it connects ticket text to product reality. An API error ticket from an account experiencing actual API 500 errors is treated differently from the same ticket text when the API is healthy.
Watch out for
Requires product telemetry integrated with the support system. If product events and support tickets live in disconnected systems, the integration work is a prerequisite.
Key metric: Relational ML reduces support MTTR by 45% by routing likely-to-escalate tickets directly to the right expertise level, saving $3.6M annually in engineering time.
Why relational data changes the answer
Escalation is driven by the intersection of ticket content, account context, and product state. The same ticket description (e.g., 'API returning errors') has completely different escalation probabilities depending on whether the account is actually experiencing API errors (product events table), whether the user has filed escalated tickets before (user history), and whether the affected endpoint was recently deployed (deployment history). A text classifier on ticket content alone treats these identically.
Relational models connect tickets to product telemetry to account health to user history and learn patterns like 'P1 API error ticket from a $240K account with a health score of 45, filed by a user with 3 prior escalations, about an endpoint deployed 3 days ago, where the account has 7 recurring 500 errors in the last 48 hours.' That combination escalates at 9x the base rate. Engineering escalations cost 8x more than L1 resolutions and take 5x longer. Routing the right tickets directly to L2/L3 eliminates the bounce-around that turns a 4-hour resolution into a 3-day ordeal.
Routing support tickets by priority tag is like routing emergency calls by the caller's voice volume. The person shouting might have a minor complaint, while the calm person describing chest pain needs an ambulance. What matters is not how the caller feels but the clinical context: their symptoms, medical history, and vital signs. Graph ML reads the clinical context behind each ticket.
How KumoRFM solves this
Graph-learned product intelligence across your entire account base
Kumo connects tickets, accounts, users, product events, and support agents into a graph. It learns that tickets from accounts that experienced a specific API error pattern in the last 24 hours, filed by users who previously had escalated tickets, about features deployed in the last sprint, escalate at 9x the base rate. The model captures agent-topic expertise (certain agents resolve specific issue types 3x faster) and account-level product stability signals that ticket text alone cannot convey.
From data to predictions
See the full pipeline in action
Connect your tables, write a PQL query, and get predictions with built-in explainability — all in minutes, not months.
Your data
The relational tables Kumo learns from
TICKETS
| ticket_id | account_id | user_id | category | priority | created_date |
|---|---|---|---|---|---|
| TK301 | ACC301 | U301 | API error | P1 | 2025-03-02 |
| TK302 | ACC302 | U302 | Feature request | P3 | 2025-03-02 |
| TK303 | ACC303 | U303 | Performance | P2 | 2025-03-01 |
ACCOUNTS
| account_id | plan | arr | health_score | csm |
|---|---|---|---|---|
| ACC301 | Enterprise | $240,000 | 45 | Lisa T. |
| ACC302 | Growth | $36,000 | 82 | Mike R. |
| ACC303 | Enterprise | $180,000 | 68 | Lisa T. |
USERS
| user_id | account_id | role | prior_escalations | tenure_days |
|---|---|---|---|---|
| U301 | ACC301 | Developer | 3 | 450 |
| U302 | ACC302 | Admin | 0 | 120 |
| U303 | ACC303 | Developer | 1 | 280 |
PRODUCT_EVENTS
| event_id | account_id | event_type | timestamp | details |
|---|---|---|---|---|
| PE01 | ACC301 | API 500 error | 2025-03-02 | endpoint: /v2/predict |
| PE02 | ACC301 | API 500 error | 2025-03-01 | endpoint: /v2/predict |
| PE03 | ACC303 | Slow query | 2025-03-01 | query_time: 12.5s |
AGENTS
| agent_id | name | tier | specialty | avg_resolution_hours |
|---|---|---|---|---|
| AG01 | Alex | L1 | General | 4.2 |
| AG02 | Priya | L2 | API issues | 8.5 |
| AG03 | James | L3/Eng | Backend | 24.0 |
Write your PQL query
Describe what to predict in 2–3 lines — Kumo handles the rest
PREDICT BOOL(TICKETS.ESCALATED_TO_ENG, 0, 48, hours) FOR EACH TICKETS.TICKET_ID WHERE TICKETS.PRIORITY <= 'P2'
Prediction output
Every entity gets a score, updated continuously
| TICKET_ID | ACCOUNT | CATEGORY | ESCALATION_PROB |
|---|---|---|---|
| TK301 | ACC301 | API error | 0.91 |
| TK302 | ACC302 | Feature request | 0.03 |
| TK303 | ACC303 | Performance | 0.42 |
Understand why
Every prediction includes feature attributions — no black boxes
Ticket TK301 -- ACC301, API error, P1
Predicted: 91% escalation probability
Top contributing features
Recurring API 500 errors (48h)
7 occurrences
32% attribution
User prior escalation history
3 past escalations
22% attribution
Account health score
45 (critical)
18% attribution
Feature deployment recency
/v2/predict updated 3d ago
16% attribution
Ticket priority vs account ARR
P1 on $240K account
12% attribution
Feature attributions are computed automatically for every prediction. No separate tooling required. Learn more about Kumo explainability
PQL Documentation
Learn the Predictive Query Language — SQL-like syntax for defining any prediction task in 2–3 lines.
Python SDK
Integrate Kumo predictions into your pipelines. Train, evaluate, and deploy models programmatically.
Explainability Docs
Understand feature attributions, model evaluation metrics, and how to build trust with stakeholders.
Frequently asked questions
Common questions about support escalation prediction
How do you predict which support tickets will escalate?
Connect ticket metadata to product telemetry (is the account actually experiencing errors?), user history (has this user escalated before?), and account health (is this a high-risk account?). Tickets where the product data confirms the reported issue, from users with escalation history, on accounts with low health scores, escalate at 9x the base rate. This context is invisible to text-only classifiers.
What is the cost of late escalation in SaaS support?
Engineering escalations cost 8x more than L1 resolutions and take 5x longer. Late escalations (tickets that bounce through L1/L2 before reaching engineering) have 3x longer MTTR and generate 2x more negative NPS responses. A SaaS company handling 5,000 tickets per month where 12% escalate spends $3.6M annually on engineering support time.
How does product telemetry improve ticket routing?
Product telemetry tells you whether the ticket matches reality. An API error ticket from an account with no actual API errors is likely a user misconfiguration (L1 resolution). The same ticket from an account with 7 recurring 500 errors on a recently deployed endpoint is a genuine platform issue (direct L3 routing). This context reduces MTTR by 45%.
Can ML match tickets to the right support agent?
Yes. Relational models learn agent-topic expertise from historical resolution data. Certain agents resolve specific issue types 3x faster than others. The model routes API issues to agents with API expertise and performance issues to agents with database knowledge, matching tickets to the agents most likely to resolve them quickly.
What data is needed for escalation prediction?
Four sources: ticket metadata (category, priority, description), account data (health score, ARR, plan tier), product telemetry (error logs, deployment history, feature usage), and user data (escalation history, role, tenure). The product telemetry is the highest-value addition because it connects the ticket to what is actually happening in the product.
Bottom line: A SaaS company handling 5,000 tickets per month that routes likely-to-escalate tickets directly to L2/L3 reduces MTTR by 45% and saves $3.6M annually in engineering time. Kumo connects ticket context to product telemetry and account health, routing tickets to the right expertise level before escalation damage occurs.
Related use cases
Explore more B2B SaaS use cases
Topics covered
One Platform. One Model. Infinite Predictions.
KumoRFM
Relational Foundation Model
Turn structured relational data into predictions in seconds. KumoRFM delivers zero-shot predictions that rival months of traditional data science. No training, feature engineering, or infrastructure required. Just connect your data and start predicting.
For critical use cases, fine-tune KumoRFM on your data using the Kumo platform and Research Agent for 30%+ higher accuracy than traditional models.
Book a demo and get a free trial of the full platform: research agent, fine-tune capabilities, and forward-deployed engineer support.
