Freshdesk

Support & Relation client

Six Freshdesk KPIs selected to drive customer support agent performance across throughput, velocity, quality, and SLA compliance, with the selection criteria made explicit.

6 available indicators

Indicator Object Type Formula Unit
Tickets Resolved Number of tickets resolved or closed by the agent in the period. Ticket Lagging COUNT count
Average First Response Time Average time in hours between ticket creation and the agent's first response. Ticket Lagging AVG(first_response_hours) hours
Average Resolution Time Average time in hours between ticket creation and resolution. Ticket Lagging AVG(resolution_hours) hours
Reopen Rate Ratio of tickets reopened over tickets resolved, per agent. Ticket Lagging COUNT_RATIO %
SLA Breach Rate Ratio of tickets where the first response SLA was breached over total tickets assigned to the agent. Ticket Leading COUNT_RATIO %
Open Backlog Number of open or pending tickets currently assigned to the agent. Ticket Leading COUNT count

Freshdesk exposes a wide range of objects: tickets, conversations, agents, contacts, companies, groups, and knowledge base articles. This integration focuses on tickets, which constitute the fundamental unit of work in customer support and the only object that supports attributable, time-bound performance measurement at the individual agent level. Objects such as contacts, companies, or knowledge base articles are rich in data but relate to customer segmentation and content management rather than to agent performance. Six KPIs were retained, selected against three criteria: ability to attribute to an owner, resistance to gaming, and balance between leading and lagging indicators.

Throughput and resolution quality

Tickets Resolved counts the number of tickets closed by an agent in a given period. Reopen Rate measures the proportion of those resolutions that were subsequently reopened by the customer. The two indicators are designed to be read together, and their pairing is what makes each one reliable. Taken in isolation, Tickets Resolved is a throughput indicator with a significant gaming risk: an agent can inflate the count by closing tickets prematurely, without verifying that the customer's problem was actually solved. Reopen Rate acts as a direct counterweight. An agent who closes tickets superficially to maximize volume will see their Reopen Rate rise accordingly, which mechanically reveals the gaming. Conversely, a low Reopen Rate in a context of high volume indicates genuine, durable resolution — the combination that a support manager wants to see.

Reading Tickets Resolved alongside Reopen Rate also surfaces a subtler dynamic: agents who handle the most complex tickets tend to have higher Reopen Rates not because of weak execution but because complex problems inherently carry more ambiguity at closure. This context cannot be read from either indicator alone, but the divergence between volume and quality prompts the right managerial question.

Velocity and customer experience

Average First Response Time measures the average delay between ticket creation and the agent's first substantive response. Average Resolution Time measures the average total duration from creation to closure. These two indicators occupy different positions in the support cycle and reveal different things when read in combination. A short Average First Response Time combined with a long Average Resolution Time indicates that the team engages customers quickly but struggles to bring issues to completion: the back-and-forth phase is where delays accumulate. The inverse pattern — a long first response with a rapid final resolution — suggests that tickets queue before being picked up, but once work begins it proceeds efficiently. Each configuration points toward a different operational lever: staffing coverage in the first case, triage and assignment processes in the second.

Average First Response Time also carries a gaming risk of its own: an agent can send a brief, uninformative acknowledgment to reset the clock without meaningfully engaging with the customer's problem. This behavior is detectable through Reopen Rate, which rises when superficial first responses fail to drive actual resolution. The three-indicator group — first response, resolution time, reopen rate — forms a self-correcting set where gaming one metric tends to degrade another.

SLA compliance and backlog health

SLA Breach Rate measures the proportion of tickets where the first response service level agreement was violated. Open Backlog measures the number of open or pending tickets currently assigned to an agent. Both are leading indicators: they describe the present state of an agent's workload rather than the outcomes of completed work. Their role in the indicator set is anticipatory. A rising SLA Breach Rate signals that an agent is no longer able to honor response commitments, which is a warning that precedes the degradation of first response time and, downstream, resolution time. Open Backlog provides the structural explanation: an agent whose backlog is growing is operating above sustainable capacity, and SLA breaches are the predictable consequence.

Tracking both indicators together enables managers to distinguish between two causes of SLA breach that require different responses. An agent with a high SLA Breach Rate and a low Open Backlog is likely facing complexity or skill gaps on specific ticket types. An agent with a high breach rate and a large, growing backlog is facing a volume problem that no individual behavioral change can resolve — the response is reassignment or team-level capacity adjustment.

Scope and limits of the integration

Freshdesk records ticket lifecycle events and timing fields, but does not measure the quality of the interaction itself. A ticket marked resolved may correspond to an expert, empathetic exchange that left the customer satisfied, or to a terse reply that technically closed the issue without addressing the underlying concern. The API data does not distinguish between the two. Customer satisfaction scores, when enabled through Freshdesk's CSAT module, are not available via the standard REST API v2 and are therefore excluded from this integration. The absence of CSAT data is the most significant gap in the indicator set: throughput, velocity, and SLA compliance are necessary but not sufficient measures of support quality.

Furthermore, this integration only captures tickets that are assigned to an agent via the responder field. Tickets that are unassigned, handled by automation, or resolved through the self-service portal are invisible to agent-level KPIs. The completeness of the picture depends directly on team discipline in ticket assignment: teams that systematically assign every inbound ticket will produce reliable indicators; teams where unassigned tickets accumulate or where agents work informally outside the tool will produce systematically underestimated volumes.