Tickets per User per Month: Measure Your Desk Demand

Make the Denominator Explicit

For the user-based rate, divide support requests received by the supported users over the same period. If you use a completed quarter, add the supported user counts for each month to get user-months. Divide the quarter's requests by that total; don't divide by the number of months again.

The model compares tickets with managed seats. A seat is a billed user or the device count if larger at that client. If your device count exceeds your user count, label the seat-based result separately so you don't compare different denominators as though they were the same rate.

I'd have the person responsible for the desk own the counting rule. A report can be exact and still count the wrong work. Keep the rule beside the export so the next person can reproduce the number.

• Desk lead: choose the completed reporting period and export managed-client support requests received, with client and creation dates. Use resolved tickets as a separate comparison.
• Desk lead: remove project and new-client onboarding work from the support count. Separate monitoring alerts from user requests and retain the human labor on those alerts.
• Billing owner: reconcile the supported user count for each month to the billing records. Supply the seat count separately wherever devices exceed users.
• Desk lead: divide received support requests by the matching user-months or seat-months, with the denominator named. Repeat the calculation by client.
• Person assigning tickets: compare incoming work with resolutions and inspect the backlog. Check a sample for duplicated follow-ups or several issues bundled into a single ticket.
• Owner: approve the reporting rule with the desk lead before using the result for a hiring or margin decision.

Use the same logging rule in each period. A change from recording separate issues to bundling them will change the rate without establishing that support demand fell. If incoming tickets exceed resolved tickets, look at the unfinished work before treating closed tickets as the workload forecast.

Turn the Count Into Labor

The model doesn't staff from a seats-per-technician shortcut. It combines ticket labor with the alert work that remains after automation. Its tier mix and handling times are assumptions to compare with your own time records.

The weighted average is 30 × 65% + 60 × 22% + 120 × 13% = 48.30 labor minutes per ticket. Count the labor across the people who worked the ticket, including escalations. Elapsed time waiting for a client is a different measure.

At the well-run rate of 0.5 tickets per seat per month, the example produces 700 × 0.5 = 350 tickets a month. Their labor is 350 × 48.30 / 60 = about 281.8 hours a month. The model assumes an endpoint per seat and 0.04 labor hours per endpoint per month for remaining alerts. The separate monitoring-alert allowance therefore adds 700 × 0.04 = 28.0 hours a month.

The model starts with 1,660 available hours per technician each year and applies 70% service utilization. That gives 1,660 × 70% / 12 = about 96.83 productive hours a month. Ticket and alert work together require about 309.8 hours, or 3.20 full-time equivalents, so the example staffs four people.

Allow for the Next Whole Person

The example has 0.80 of a full-time equivalent of remaining capacity, about 77.6 hours a month using the unrounded inputs. At the same ticket mix, about 0.138 additional tickets per seat per month would consume that remaining capacity. The next staffing step is a fifth technician, whose modeled pool wage costs about $80,326 a year with burden.

Treat that as a calculation under the example's assumptions. Your next hire depends on the work you expect and the capacity actually available when they start. Longer handling times or extra alert labor can use the remaining hours without any change in the user-support ticket count.

The owner should ask the desk lead to compare those inputs with recruitment and training plans before promising capacity to sales. The person assigning tickets should flag work that has no available owner. An average month doesn't tell them who can take an urgent ticket now.

Check the Financial Consequence

Holding its other assumptions constant, the model's move from the well-run ticket rate to 1.0 raises desk cost from $38.25 to $66.94 per seat per month. Managed-services gross margin falls from 54.2% to 41.1%. That margin includes delivery labor and tools.

For the whole example MSP, the same workload change removes about $282,547 a year, or 7.8 percentage points of EBITDA. EBITDA is earnings before interest, taxes, depreciation, and amortization, after the operating costs and fair-market owner salary. This is a sensitivity for the example business, not a forecast of what your own desk will save.

I'd leave the growth hacks out of this decision. Compare your own labor and demand before deciding that the answer is another technician or a higher price. The model's Tier 3 work consumes 32% of ticket labor hours while resolving 13% of the tickets, which is a reason to inspect escalations as well as volume.

Give the Follow-Up a Named Owner

Ask the desk lead to choose recurring work worth investigating. Ask the technician who understands it to check whether a documented fix or automation can handle it appropriately. Keep unfamiliar or risky work with someone qualified to do it.

Use one standard technology stack and train the team on it. For a low-margin client with a fixable environment, have the account owner assess a refresh project before repricing. Record the hours before and after the change so you can examine what actually moved.

A lower ticket count alone doesn't prove that delivery improved. Missing records, changed counting rules, or work shifted into another queue can also change the number. Check the labor and unresolved work alongside it.

Start with a received-ticket export and reconciled user or seat counts for the same period. Have the desk lead sign off the sample and the counting rule, then put the incoming workload beside available technician hours. The owner can use that comparison to decide what to change before adding more clients to the board.