Time to Resolution

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.

Business Context

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.

Related Activities

Activities commonly tied to improving or operationalizing this KPI.

Activity	Description
Customer Support	Customer Support is a proactive, strategic approach to supporting customers throughout their lifecycle, ensuring they realize maximum value from a product or service. It makes the motion operational through ownership, routines, and cross-functional follow-through. Relevant KPIs include Complaints Received and Complaints Resolved.
SLA Management	SLA Management focuses on establishing, monitoring, and optimizing Service Level Agreements (SLAs) between internal teams—such as sales, product, and customer success—and external stakeholders, including customers and partners. It makes the motion operational through ownership, routines, and cross-functional follow-through. Relevant KPIs include First Response Time and Resolution Time.
Escalation Handling	Escalation Handling is essential for maintaining satisfaction and driving retention. It helps teams translate strategy into repeatable execution. Relevant KPIs include Complaints Resolved and Time to Resolution.

Required Datapoints

• 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

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

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

Positive & Negative Influences

Negative Influences

• 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

• 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.

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 likely future performance and is used to predict outcomes before they fully materialize.

Ownership

Primary Owner

This role is directly accountable for the KPI and is expected to drive progress and decisions around it.

• Support Operations

Secondary Owners

These roles contribute directly to performance and typically partner on execution, reporting, or optimization.

• Product Management (PM)
• Customer Success

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.

Data Model Definition

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

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