Cost per Ticket

A support team spending $150,000 in a month and handling 10,000 tickets under a consistent counting rule has a cost per ticket of $15 in the same currency, though a complex case may cost far more than $15 and a simple answer far less. Define the ticket first, since a support email, chat and phone call may each create a request or several contacts may belong to one issue, and count consistently.

Choose the status too, because tickets opened, handled and resolved are not identical, and if the denominator is resolved requests the metric should be called cost per resolution. Match the period, since monthly expenses divided by quarterly volume produce a meaningless ratio unless the amounts are converted to the same interval.

Include staff costs such as pay, benefits, training and supervision, which can be major parts of support expense and not just agents' wages, and include tools like software, phone systems, workstations and outsourced services in a fully loaded view. Allocate overhead such as facilities and shared management using a clear rule, without changing allocation methods silently between periods.

Treat outsourced tickets fairly, because a vendor fee might replace internal wages while integration and oversight costs may remain. Watch volume effects, since a fixed monthly team costs more per ticket when volume falls even if employees work just as effectively, and measure backlog, because a team could lower cost per handled ticket by leaving hard cases open.

Check reopenings too, as a hurried answer that leads to another ticket can make apparent efficiency misleading, so define whether repeat contacts are new work. Track quality, because satisfaction, first-contact resolution and service levels help show whether lower cost is harming the customer, and segment by channel since voice, email and chat consume different effort, splitting costs by actual labour or another defensible basis rather than assigning equal cost blindly.

Segment by issue type as well, because a password reset and a technical investigation should not have the same expected handling time and a single average hides the mix. Record automation costs, since a chatbot may deflect routine questions but needs design, maintenance and review, so its total cost is not zero, and avoid counting deflection as resolution because a customer who gives up after a failed self-service attempt may return with more work later.

Check coverage hours, since overnight or multilingual support may cost more per ticket to meet a service promise and the higher ratio may be intentional, and compare similar teams because wage markets, channels and case complexity differ, so external benchmarks need context before making staffing decisions. Look at marginal decisions as well: the average of all costs does not equal the extra cost of one more ticket when spare capacity exists.

Use trends, since a sustained increase can point to lower volume, harder issues, rising wages or poor workflows, and investigate the driver. Tie changes to outcomes, because if a knowledge base reduces routine contacts, remaining tickets may be more complex and average cost may rise despite better customer experience, and share the definition so finance, operations and reporting teams agree on which cost lines and statuses enter the metric.

Metabase describes a fully loaded cost divided by handled tickets and warns against optimising without satisfaction, and HDI likewise emphasises that lower cost alone is not necessarily good service. For an owner, cost per ticket is a useful operating signal when it sits beside case mix, quality and waiting time, not a mandate to spend the least possible amount.