Time to Resolution (TTR)¶

Definition¶

Time to Resolution (TTR) measures the average time it takes for a support team to fully resolve a customer inquiry, issue, or ticket. It starts when the issue is reported and ends when it is marked as resolved.

Description¶

Time to Resolution (TTR) is a key indicator of support efficiency, operational readiness, and customer satisfaction, reflecting how quickly customer issues are resolved from first touch to closure.

The relevance and interpretation of this metric shift depending on the model or product:

In SaaS, it highlights support team bandwidth and product complexity
In eCommerce, it reflects how well operational logistics are supported
In B2B tools, it surfaces escalation processes and CS enablement

A shorter TTR improves trust and retention, while longer times may indicate tooling gaps, resource limits, or knowledge base blind spots. By segmenting by issue type, channel, or region, teams can identify specific friction points and optimize support flows accordingly.

Time to Resolution informs:

Strategic decisions, like investing in automation, hiring, or training
Tactical actions, such as rerouting tickets or enhancing self-service tools
Operational improvements, including playbooks, internal documentation, and macros
Cross-functional alignment, supporting CS, support, product, and PMM in delivering fast, frictionless experiences

Key Drivers¶

These are the main factors that directly impact the metric. Understanding these lets you know what levers you can pull to improve the outcome

Support Routing and Triage Logic: Right ticket → right person = faster resolution.
Agent Enablement and Tools: Knowledge bases, macros, and internal wikis reduce back-and-forth.
Recurring Issues or Bugs: Known issues create avoidable delays — unless proactively addressed.

Improvement Tactics & Quick Wins¶

Actionable ideas to optimize this KPI, from fast, low-effort wins to strategic initiatives that drive measurable impact.

If resolution time is climbing, segment by issue type and resolve frequent offenders with docs or UX fixes.
Add escalation playbooks with clear routing rules for speed.
Run a support enablement sprint: macro refresh, search optimization, agent QA.
Refine product feedback loops — turn repeated tickets into sprint tickets.
Partner with product to fix high-friction issues and bugs causing ticket overload.

Required Datapoints to calculate the metric
- Ticket Open Time: When the issue or inquiry is first logged.
- Ticket Resolution Time: When the issue is marked as resolved.
- Total Resolved Tickets: The number of tickets closed during the measurement period.
Example to show how the metric is derived

A SaaS company resolves 1,000 tickets in a month with a total resolution time of 50,000 minutes:
- TTR = 50,000 / 1,000 = 50 minutes per ticket

Formula¶

Formula

\[ \mathrm{Time\ to\ Resolution} = \frac{\mathrm{Total\ Resolution\ Time\ for\ All\ Resolved\ Tickets}}{\mathrm{Total\ Number\ of\ Resolved\ Tickets}} \]

Data Model Definition¶

How this KPI is structured in Cube.js, including its key measures, dimensions, and calculation logic for consistent reporting.

SupportTickets

cube('SupportTickets', {
  sql: `SELECT * FROM support_tickets`,

  measures: {
    timeToResolution: {
      sql: `TIMESTAMPDIFF(HOUR, ticket_open_time, ticket_resolution_time)`,
      type: 'avg',
      title: 'Average Time to Resolution',
      description: 'Average time in hours to resolve a ticket from the time it is opened to the time it is resolved.'
    },
    totalResolvedTickets: {
      sql: `id`,
      type: 'count',
      title: 'Total Resolved Tickets',
      description: 'Total number of tickets resolved in the given period.'
    }
  },

  dimensions: {
    id: {
      sql: `id`,
      type: 'number',
      primaryKey: true,
      title: 'Ticket ID',
      description: 'Unique identifier for each ticket.'
    },
    ticketOpenTime: {
      sql: `ticket_open_time`,
      type: 'time',
      title: 'Ticket Open Time',
      description: 'The time when the ticket was opened.'
    },
    ticketResolutionTime: {
      sql: `ticket_resolution_time`,
      type: 'time',
      title: 'Ticket Resolution Time',
      description: 'The time when the ticket was resolved.'
    }
  },

  preAggregations: {
    main: {
      type: 'originalSql',
      scheduledRefresh: true,
      refreshKey: {
        every: '1 hour'
      }
    }
  }
});

Note: This is a reference implementation and should be used as a starting point. You’ll need to adapt it to match your own data model and schema

Positive & Negative Influences¶

Negative influences

Factors that drive the metric in an undesirable direction, often signaling risk or decline.
- Support Routing and Triage Logic: Inefficient routing can lead to tickets being assigned to the wrong agents, increasing the time to resolution as the ticket is passed between agents.
- Agent Enablement and Tools: Lack of access to comprehensive knowledge bases or inadequate tools can result in longer resolution times due to increased back-and-forth communication.
- Recurring Issues or Bugs: Unaddressed recurring issues can cause repeated delays in resolution as agents spend additional time troubleshooting known problems.
- Agent Workload: High workload or understaffing can lead to longer resolution times as agents are unable to address tickets promptly.
- Complexity of Issues: Complex or multifaceted issues naturally take longer to resolve, increasing the average time to resolution.
Positive influences

Factors that push the metric in a favorable direction, supporting growth or improvement.
- Support Routing and Triage Logic: Effective routing ensures tickets are assigned to the most qualified agents, reducing resolution time.
- Agent Enablement and Tools: Access to robust knowledge bases and efficient tools enables agents to resolve issues more quickly.
- Proactive Issue Management: Addressing recurring issues or bugs proactively can prevent delays and reduce resolution time.
- Agent Training and Expertise: Well-trained and knowledgeable agents can resolve issues faster, decreasing the time to resolution.
- Automation of Routine Tasks: Automating routine tasks or responses can speed up the resolution process, reducing the average time to resolution.

Involved Roles & Activities¶

Involved Roles

These roles are typically responsible for implementing or monitoring this KPI:

Product Management (PM)
Support Operations
Activities

Common initiatives or actions associated with this KPI:

Customer Support
SLA Management
Escalation Handling

Funnel Stage & Type¶

AAARRR Funnel Stage

This KPI is associated with the following stages in the AAARRR (Pirate Metrics) funnel:

Retention
Type

This KPI is classified as a Leading Indicator. It signals potential future outcomes and is typically used to guide proactive decisions or forecast trends.

Supporting Leading & Lagging Metrics¶

Leading

These leading indicators influence or contextualize this KPI and help create a multi-signal early warning system, improving confidence and enabling better root-cause analysis.
- First Response Time: As a lagging KPI, First Response Time provides insights into how quickly support teams initially respond to customers. Analyzing trends in First Response Time can recalibrate expectations for Time to Resolution by identifying bottlenecks or inefficiencies that may be lengthening the overall resolution process. Improving First Response Time often leads to reduced Time to Resolution.
- Escalation Rate: Escalation Rate reflects the percentage of cases requiring higher-level support. High escalation rates suggest that frontline support may be unable to resolve issues efficiently, potentially signaling longer Time to Resolution. Monitoring Escalation Rate helps refine Time to Resolution forecasts and support process strategies.
- Ticket Volume: Ticket Volume indicates the workload on support teams. Large spikes or sustained increases in Ticket Volume can extend Time to Resolution due to resource constraints. Analyzing this lagging metric helps anticipate periods when Time to Resolution may be impacted, informing staffing and process improvements.
- Onboarding Completion Rate: Onboarding Completion Rate assesses how effectively new users complete the onboarding flow. Poor onboarding may lead to increased support queries and longer Time to Resolution as new users struggle with the product. Reviewing this KPI can help identify upstream improvements to reduce support burden and lower Time to Resolution.
- First Contact Resolution: First Contact Resolution measures the ability to resolve issues in a single interaction. Lower FCR rates typically lead to increased Time to Resolution due to multiple touchpoints per ticket. Tracking this lagging metric helps recalibrate expectations and strategies for improving Time to Resolution.
Lagging

These lagging indicators support the recalibration of this KPI, helping to inform strategy and improve future forecasting.
- Customer Churn Rate: Customer Churn Rate, although lagging overall, can act as a feedback loop for Time to Resolution by signaling downstream impacts of slow resolutions. If prolonged Time to Resolution is leading to increased churn, this relationship can be used to recalibrate leading indicators and prioritize resolution speed.
- Customer Satisfaction Score: CSAT is directly influenced by support experiences. Slow Time to Resolution often predicts lower satisfaction scores. Monitoring CSAT provides an immediate, qualitative signal that can help contextualize and forecast changes in Time to Resolution effectiveness.
- Net Promoter Score: NPS is sensitive to support interactions, with long Time to Resolution typically reducing promoter likelihood. Trends in NPS can act as an early warning for broader customer loyalty risks stemming from resolution delays, providing context for the leading indicator system.
- Customer Health Score: Customer Health Score aggregates product usage, satisfaction, and support KPIs. Changes in Time to Resolution can influence health scores, which in turn serve as a composite early warning for potential churn or expansion risk.
- Activation Rate: Activation Rate reflects how quickly users reach meaningful value. Prolonged Time to Resolution, especially for onboarding-related issues, can suppress Activation Rate. Monitoring this metric alongside TTR forms a multi-signal early warning system for user experience.