Mean Time to Resolve (MTTR)

MTTR formula: MTTR = Sum of (Resolution Timestamp - Creation Timestamp for all tickets in period) / Number of Resolved Tickets in Period. The raw mean is highly susceptible to skew from a small number of extremely long-duration tickets — a single 90-day-open unresolved bug can distort the mean dramatically while the median reflects the typical customer experience accurately. Support Ops should report both mean and median MTTR, and also segment MTTR by: ticket priority (P1 MTTR should be 2–4 hours for enterprise SaaS; P4 MTTR may be 10+ business days and is acceptable); ticket type (billing tickets close in hours; engineering escalations may take weeks); channel (chat MTTR should be under 15 minutes; email MTTR is measured in hours); and customer tier (enterprise vs. SMB may have very different MTTR targets). MTTR reported as a single blended number conflates all these dimensions into a figure that is hard to act on and easy to game.

MTTR reduction requires identifying where time is spent — the resolution process has distinct phases where improvement is possible. Agent assessment time (first touch to full diagnosis): reduced by structured diagnostic workflows in the knowledge base ("for [symptom], check these 5 things in order"), auto-populated account context from CRM integration, and AI-suggested solutions based on ticket text. Engineering wait time (Tier 2 escalation holding for an engineering response): reduced by defining Engineering escalation SLAs and monitoring compliance; building Tier 2 diagnostic tools that enable Tier 2 to resolve issues that previously required engineering; and building a resolution library for common engineering escalation patterns. Customer wait time (agent waiting for the customer to provide additional information): reduced by agents requesting all needed information in one message rather than sequential follow-ups; automated "waiting for customer" status-based reopening so tickets aren't marked resolved while waiting; and proactive follow-up timers (automated reminder sent to customer and agent if no response in 24 hours). Post-diagnosis hold (solution known but blocked by process): reduced by clearly defined agent authority to implement common fixes without approval.

The MTTR-CSAT relationship is non-linear and counterintuitive. Reducing MTTR generally improves CSAT — customers appreciate faster resolution. But MTTR reduction achieved through rushed resolutions, premature ticket closure, or superficial fixes actively damages CSAT: a ticket closed in 2 hours without actually solving the problem will generate a very low CSAT score and likely a reopen (measured as a "recontact rate"). The tension point: when management incentivizes MTTR reduction as a KPI without CSAT guardrails, agents optimize for closure speed over resolution quality — taking shortcuts, marking tickets resolved before thorough verification, and deflecting complex issues to the knowledge base without genuine help. Support Ops mitigates this by: reporting MTTR alongside CSAT and recontact rate in every operational dashboard (making gaming obvious through the recontact signal); explicitly telling agents that a long MTTR on a complex issue handled with care is valued over a fast MTTR achieved through deflection; and setting MTTR targets by ticket type that reflect realistic resolution quality timelines rather than aspirational speed goals.