How to calculate cost per ticket (and why most teams get it wrong)

Cost per ticket looks like the simplest number a service desk reports, but leave benefits and shared overhead out of the cost pool, count tickets created instead of tickets closed, or divide one month’s costs by another month’s volume, and the result lands on a budget slide looking cleaner than the desk actually runs. Nobody questions it until a staffing, pricing, or tooling decision rests on it.

The margin for error is wider than most teams assume. MetricNet puts the average fully loaded cost per ticket at $20 for the service desk, $70 for desktop support, and $200 for onsite field support. With that much spread between IT support tiers, a ticket count padded with spam and duplicates or a cost pool missing half its inputs can make an expensive desk look efficient.

So here’s where most people get the calculation wrong and how to actually calculate your organization’s cost per ticket.

» Don’t miss our guide to automating ticket routing

Why most cost-per-ticket figures are wrong

Cost per ticket is the average amount a service desk spends to resolve one IT support issue or complete one request over a set period. The unit of work is the ticket, which is the record tracking one IT problem or service request, whether an employee reported it, a technician logged it, or an infrastructure monitoring alert generated it.

A ticket stays one ticket no matter how many technicians touch it, how many messages go back and forth, or how many sessions it takes to close. The metric measures cost per completed piece of work, not cost per interaction, and a lot of calculation errors come from losing sight of that.

That means cost per ticket calculations being wrong usually isn’t a problem with the formula. The errors come from what goes into it, such as a cost pool missing expenses, a ticket count that includes unfinished work, or costs and tickets pulled from different date ranges. Each one produces a clean-looking number that nobody thinks to question.

Four mistakes that distort the result

The most common mistakes people make when calculating cost per ticket are:

• Leaving costs out: Teams often count technician wages and stop there, missing benefits, software licenses, phone costs, and the desk’s share of rent and shared services. In-house tools get skipped too, because nobody receives an invoice for them.
• Counting tickets created instead of tickets completed: Created tickets measure demand coming in, not work the team finished. Any request still open at the end of the period inflates the count without contributing a completed piece of work, which pushes the cost per ticket down.
• Keeping invalid records in the count: Spam, test tickets, duplicates, and cancellations where no support work was done all add to the ticket total. None of them represents a resolved issue, so they dilute the cost of the tickets that do.
• Mixing reporting periods: Dividing April’s costs by March’s completed tickets describes neither month. If March was quiet, each ticket looks more expensive than it was. The distortion is hardest to spot for clients who contact support irregularly, where one unusual month can skew the whole result.

» Here’s our guide to automated ticket resolution using AI

Why a low number isn’t automatically a good one

Three of the four mistakes push cost per ticket down, which is part of why they survive. Nobody challenges a number that makes the desk look efficient. But a low cost per ticket isn’t necessarily good if it comes at the expense of service levels or customer satisfaction, and a high one isn’t necessarily bad when service quality is above average. A figure deflated by bad inputs is worse than either, because it can’t tell you which situation you’re in and where you need to focus your attention.

Before a cost-per-ticket figure goes anywhere near a budget or staffing decision, check which costs and tickets were included and confirm they cover the same dates. Applying the same method every period is what makes one period’s result comparable to the next.

» Want to reduce costs? Don’t miss these ticket handling best practices for IT admins

How to calculate cost per ticket step by step

The formula for cost per ticket is one line of division. The real work is making sure both sides of that division hold up. Here are the steps you should follow:

Step 1: Gather your inputs and set the measurement period

Before calculating anything, assemble four things for the same date range:

• A count of unique tickets resolved or closed in the period
• Technician pay and benefits from payroll
• Tool and telecom costs, confirmed against invoices and license records
• The shared overhead the desk draws on

Then choose a period:

Note: Monthly volatility is easy to underestimate. A desk spending $63,000 a month that completes 700, 1,050, and 900 tickets across a quarter would report $90, $60, and $70 per ticket. The quarterly figure is $71.32. Whichever period you choose, costs and tickets must cover exactly the same dates.

Step 2: Apply the formula

Cost per ticket (CPT) is the total service desk operating cost for a period divided by the qualifying tickets completed in that same period: CPT = C ÷ T

• C is everything it cost to run the desk, including technician pay, benefits, tools and telecoms, and the desk’s allocated share of overhead
• T is the count of valid, unique tickets resolved or closed during the same dates. Duplicates, spam, test tickets, and cancellations with no support work are removed under a documented rule

For example, a desk with $40,000 in labor and benefits, $4,000 in dedicated tools and telecoms, and $6,000 in allocated overhead has a total operating cost of $50,000. Divided across 1,000 completed tickets, that’s $50 per ticket.

The result is an average, not the cost of any individual ticket. A password reset costs less, and a multi-day incident costs more.

Step 3: Build the numerator

Service desk operating expense should cover five components:

• Salaries and benefits for the agents themselves
• Salaries and benefits for indirect staff, including team leads, supervisors, dispatchers, trainers, and managers
• Technology and telecom expenses, such as computers and software licenses
• Facilities costs, such as office space and utilities
• Travel, training, and office supplies

Support is labor-intensive, so personnel costs make up the vast majority of that total.

The test for any expense is whether it reflects what it took to handle the tickets counted in that period. Direct costs are straightforward. Shared costs need to be allocated.

Here’s a good starting point:

• List every cost the desk shares with other teams, such as company-wide software, rent, utilities, and HR, finance, or management support
• Pull each cost’s total for the measurement period from invoices, contracts, or the general ledger
• Choose an allocation basis for each cost, such as active seats for software, floor space for facilities, and headcount or scheduled hours for management support
• Multiply each cost by the desk’s share to get the allocated amount
• Add the allocated amounts to direct labor and dedicated tools and telecoms to get C
• Record the source, the allocation basis, and a review date for every estimated figure
• Use the same allocation method every period, because changing the basis between periods changes the result even when nothing about the desk has changed

Step 4: Build the denominator

A ticket belongs in T only if it meets three conditions:

• It’s a valid, unique support record.
• It involves work the service desk was responsible for.
• It was resolved or closed during the measurement period.

Billing status doesn’t matter. A ticket counts whether or not the work was invoiced or paid.

To turn raw ticket data into a clean count:

1. Export the ticket ID, status, completion date, cancellation reason, whether work was logged before cancellation, and spam and merge flags for the period
2. Keep only tickets resolved or closed within the period, including those opened in an earlier period
3. Remove spam and test tickets
4. Consolidate duplicates and merged records, keeping the final ticket ID so the issue counts once
5. Remove cancellations with no support work logged, and keep cancellations where a technician did log work
6. Check that the starting count minus every removal equals the final count

For example, 1,050 candidate records minus 20 spam or test records, 20 duplicates, and 10 no-work cancellations leaves 1,000 qualifying tickets. Tickets still open at the end of the period are left out and counted in the period they’re completed.

In Atera, you can pull the starting list with the Timesheet report. Filter by Ticket Resolved Date, match the time period to your cost dates, and leave Include all tickets unchecked so only resolved and closed tickets appear. Then export the results to Excel for cleaning.

Step 5: Calculate from technician time logs

When technicians log time per ticket completely and consistently, a time-driven calculation gives a more granular result. It’s useful for comparing ticket types, support tiers, or customers with very different workloads.

The method works like this:

1. Convert each work session’s logged minutes to hours
2. Multiply the hours by the technician’s full internal hourly cost, based on wages and benefits rather than the external billing rate
3. If more than one technician worked the ticket, add their costs together
4. Add any vendor or travel cost and the ticket’s share of shared desk costs
5. Repeat for every qualifying ticket, then divide the total by the ticket count

For example, a ticket with 30 minutes from a $40-per-hour technician ($20), 15 minutes from a $60-per-hour technician ($15), and a $5 share of software, phone, and overhead costs comes to $40.

In Atera, the same Ticket Resolved Date export used for the denominator already includes the hours logged against each qualifying ticket, so both inputs come from one report. Hourly costs come from payroll. Don’t use the report’s Rate or Amount fields as internal costs; they’re billing figures. Rate shows 0.00 for retainer and flat-fee contracts, and Amount is the billed subtotal for each ticket.

Pro tip: Teams without per-ticket time logs can still produce a defensible figure, just start with total labor and overhead for the period. If technicians split time between desk work and other duties, estimate the desk’s share from work schedules or a short one- to two-week time-logging sample, then split costs shared across the whole team (such as a manager’s salary) by headcount and divide the total by the qualifying completed tickets.

» Increase your technician value with a modern IT troubleshooting framework

Turning cost per ticket into a working metric

Cost per ticket is only as reliable as the decisions made before the division: which costs count, which tickets qualify, and which dates both sides cover. Make those decisions once, document them, and apply them the same way every period. The real value comes from breaking it down by ticket type and client, where it shows exactly which work is consuming your technicians’ time.

Atera keeps tickets, logged technician time, and endpoint IT management in one platform, so each period’s ticket count and hours come from a single Timesheet report rather than a patchwork of exports.

Once that breakdown shows which repetitive requests are eating into the queue, Robin, Atera’s AI technician, resolves routine end-user requests like password resets autonomously and end to end, with no technician in the loop. Robin resolves up to 92% of Tier-1 and complex Tier-2 technical incidents this way, which means every one of those tickets stops showing up in your cost-per-ticket count at all.

 Curious how many of your own tickets fall into that category? See how many of your tickets Robin could resolve before your next cost-per-ticket review.