What is escalation rate, and how do you measure it in Metabase?

Escalation rate is the share of tickets that tier-1 support hands off — to tier-2, to management, or to engineering. It's the metric that shows where frontline knowledge runs out, which makes it less a performance grade than a map of training, documentation, and product gaps. Measure it in Metabase from help desk data synced into a database (Zendesk, Freshdesk, Intercom, or Gorgias).

What escalation rate measures

It measures how often a ticket exceeds the frontline's reach — but "the frontline's reach" ends in three different places, and the distinction matters:

• Tier-1 → tier-2 — a skills or permissions boundary. The bread-and-butter escalation, and the one to use as the headline rate.
• Management escalation — an upset or high-stakes customer. A relationship signal, closer to CSAT than to routing.
• Engineering escalation — a suspected bug or missing capability. A product signal that no amount of support training will move.

A high tier-1 → tier-2 rate means either a training and documentation gap or a genuinely hard product area — and the by-topic breakdown tells you which. Escalation rate pairs naturally with first-contact resolution: one counts the tickets the frontline finishes, the other counts the ones it passes on, and gaming either one distorts the other.

What data does it need?

• A per-ticket escalation marker — an escalated_at timestamp derived from group/team changes, an escalation tag, or a tier field change in the audit history.
• An escalation type (tier-2, management, engineering) so the three series stay separate. Tags or destination group usually encode this.
• topic or category on every ticket, because the by-topic view is the whole point.
• created_at and solved_at, to compare resolution time for escalated vs non-escalated tickets.

SQL patterns

-- Monthly tier-1 -> tier-2 escalation rate by topic. Topics that
-- escalate far above the baseline are training, docs, or product gaps.
SELECT
  date_trunc('month', t.created_at)                       AS month,
  t.topic,
  COUNT(*)                                                AS tickets,
  COUNT(*) FILTER (WHERE t.escalated_at IS NOT NULL)      AS escalated,
  ROUND(100.0 * COUNT(*) FILTER (WHERE t.escalated_at IS NOT NULL)
        / NULLIF(COUNT(*), 0), 1)                         AS escalation_rate_pct
FROM tickets t
GROUP BY date_trunc('month', t.created_at), t.topic
HAVING COUNT(*) >= 20  -- skip topics too small to trust
ORDER BY month, escalation_rate_pct DESC;

-- What escalation costs in customer time: resolution percentiles for
-- escalated vs non-escalated tickets, last 90 days.
SELECT
  (t.escalated_at IS NOT NULL)                            AS was_escalated,
  COUNT(*)                                                AS resolved_tickets,
  PERCENTILE_CONT(0.5) WITHIN GROUP (
    ORDER BY EXTRACT(EPOCH FROM (t.solved_at - t.created_at)) / 3600.0
  )                                                       AS median_hours,
  PERCENTILE_CONT(0.9) WITHIN GROUP (
    ORDER BY EXTRACT(EPOCH FROM (t.solved_at - t.created_at)) / 3600.0
  )                                                       AS p90_hours
FROM tickets t
WHERE t.solved_at >= current_date - INTERVAL '90 days'
GROUP BY (t.escalated_at IS NOT NULL);

Pitfalls

Where this metric applies

• Zendesk + Metabase — group changes and audit events that mark escalations
• Freshdesk + Metabase — group assignment and ticket activity history
• Intercom + Metabase — team assignment changes on conversations
• Gorgias + Metabase — tags and team routing for e-commerce queues

Related

Metrics

Analytics & dashboards

FAQ