Profession Calculators
Tech & IT

IT Ticketing Backlog Burn-Down Calculator

Calculate days to clear IT support ticket backlog based on current queue size, daily ticket arrival rate, team resolution capacity, and target resolution SLA for help desk planning.

Share:
Current Situation

Open tickets in queue

New tickets per day

Team Capacity

Number of support staff

Average resolution capacity

SLA & Goals

Response/resolution time goal

Desired steady-state backlog

Embed This Calculator on Your Website

Add this free calculator to your blog, website, or CMS with a simple copy-paste embed code.

Introduction

A service desk with 400 open tickets and a 3-person team is not just inconvenient -- it is a measurable business risk. HDI's 2025 Technical Support Practices & Salary Report found that organizations with SLA compliance below 70% report 23% higher employee frustration scores and 18% higher IT-related turnover. The math behind a ticket backlog is deceptively simple: if your team resolves fewer tickets per day than arrive, the backlog grows indefinitely. Yet most IT managers eyeball their queue rather than model it. At 35 tickets arriving daily with a 3-person team resolving 36 per day, you net exactly 1 ticket of progress daily -- meaning a 400-ticket backlog takes 400 days to clear without any staffing change. This calculator applies queuing theory fundamentals to give you a data-driven answer to the question every IT manager eventually faces: how many people do I actually need?

What This Calculator Does

This IT ticketing backlog burn-down calculator determines how long it will take to eliminate an existing ticket backlog given your team size, individual resolution rate, and daily ticket arrival volume. It calculates net burn rate (resolutions minus arrivals), projected days to reach zero backlog, average ticket wait time, SLA compliance status against your target, and minimum staffing required to meet your SLA. The tool uses Little's Law adapted for IT service desk queuing and includes 2026 industry benchmarks for ticket volumes and resolution rates across L1, L2, and L3 tiers.

The Formula

Net Burn Rate = (Team Size x Tickets per Person per Day) - Daily Arrival Rate | Days to Clear = Current Backlog / Net Burn Rate | Avg Wait Time = Backlog / Total Daily Capacity | Staffing Needed = ceil(Daily Arrivals / Tickets per Person per Day) + 1 buffer

Team capacity is daily throughput: 4 agents at 12 tickets/day each equals 48 tickets/day capacity. If 44 new tickets arrive daily, net burn is 4 tickets/day. A 320-ticket backlog clears in 80 days. Average wait time (Little's Law adaptation): current backlog divided by daily capacity equals average days a new ticket waits. For SLA compliance, compare this average wait against your target resolution time. Staffing requirement: to clear arrivals the same day they arrive with a 1-agent buffer for sick time and peaks, the formula requires enough agents so that (agents x tickets/person/day) exceeds arrivals by at least one agent's capacity.

Step-by-Step Example

1

Baseline the current situation

Service desk has 280 open tickets. Team of 4 agents each resolves 11 tickets/day (verified from ticketing system metrics last 30 days). New tickets arrive at 43/day (measured from Monday-Friday volume over the same 30-day period).

2

Calculate net burn rate

Team capacity: 4 x 11 = 44 tickets/day. Arrivals: 43/day. Net burn: 44 - 43 = 1 ticket/day. At this rate, the 280-ticket backlog clears in 280 days -- approximately 13 months. The team is barely keeping pace.

3

Evaluate SLA compliance

Average wait time: 280 backlog / 44 capacity = 6.4 days per ticket on average. If the SLA target is 48-hour resolution, the service desk is operating at roughly 15% SLA compliance. Every ticket that enters the queue today waits 6+ days before resolution.

4

Model staffing solutions

To reach 48-hour SLA with 43 daily arrivals: need a queue depth no greater than 88 tickets (43/day x 2 days). Currently 280 tickets -- 192 tickets need clearing. Adding 1 agent (5 total, 55/day capacity): net burn = 55 - 43 = 12/day. Clears 192 excess tickets in 16 days, then SLA-compliant. Adding 1 agent costs $65K/year; SLA breach cost in productivity loss far exceeds this.

Real-World Use Cases

Post-Merger IT Integration Surge

A company acquires a 200-person business. Onboarding generates 600 new tickets in 2 weeks (account setup, equipment, access requests). Normal team of 5 resolves 60/day. With merger arrivals of 100/day for 2 weeks, net burn is negative (-40/day). The backlog peaks at 360 tickets. Model shows that adding 3 temporary contractors for 4 weeks brings net burn to +90/day, clearing the backlog in 4 days and returning to steady state before the contractors' cost exceeds $15K.

Monthly Capacity Planning

Ticket volumes grow 8% month-over-month (40 tickets/day in January becomes 43 in February, 47 in March). Current team handles 44/day. The calculator shows the team falls behind arrivals starting in February. The IT manager hires one additional agent in January, extending capacity headroom to Q4 before another hire is needed.

Outsourcing vs Hiring ROI

Service desk at 55% SLA compliance, 3-person team, growing backlog of 500 tickets. Two options: hire 2 FTEs at $65K each ($130K/year), or contract an MSP at $8/ticket with 98% SLA guarantee. At 45 tickets/day (11,700/year), MSP costs $93,600/year and delivers higher SLA. The burn-down model quantifies the trade-off, making the outsourcing case financially clear.

Comparison

TierTypical Tickets/Agent/DayAvg Resolution TimeSLA TargetEscalation Rate
L1 (Password resets, basic access)20-3515-30 minutes4 hours25-35%
L1 (General break-fix)12-2030-90 minutes8-24 hours20-30%
L2 (Application support)6-122-8 hours24-48 hours10-20%
L3 (Infrastructure/engineering)2-64 hours to 2 weeks3-5 business days5-10%
Mixed (typical SMB helpdesk)10-151-4 hours24 hours15-25%

Common Mistakes to Avoid

  • Measuring team capacity from best-case days rather than 30-day averages. One agent resolved 18 tickets on a Tuesday does not mean their sustainable rate is 18/day. Calculate from a 20-30 day rolling average that includes slow days, complex tickets, meetings, and training.

  • Ignoring ticket complexity distribution. A team of 4 averaging '12 tickets/day' may be 8 L1 simple tickets and 4 L2 complex tickets per agent. Replacing 3 L2 agents with L1-only staff does not maintain the same throughput on the complex queue.

  • Counting weekends in burn-down timelines when tickets only arrive and get resolved on business days. A 50-day burn-down is 50 business days = 10 weeks, not 7 weeks.

  • Assuming steady arrival rate. Monday mornings and the day after major incidents generate 2-4x normal volume. Model peak-day capacity separately to identify whether your SLA survives normal demand spikes without a backlog spike.

Frequently Asked Questions

Accuracy and Disclaimer

Backlog calculations use deterministic queuing models that assume constant arrival rates and consistent resolution speeds. Real service desk ticket flow is stochastic with daily volume variation, complexity differences, seasonal patterns, and staff availability fluctuations. Projections should be treated as planning estimates, not guaranteed outcomes. Actual clearance times may vary 20-40% from model projections. SLA compliance depends on ticket prioritization discipline, escalation adherence, and tooling effectiveness in addition to capacity. This tool is for planning and staffing analysis only. Consult IT service management professionals and consider ITIL framework guidance for comprehensive service desk optimization.

Conclusion

A burn-down model is most powerful when it moves from calculation to action: either increase throughput (staffing, automation, self-service deflection) or reduce arrivals (root cause elimination, better user training). Once you have optimized your service desk capacity, use the Cloud Infrastructure Cost Estimator to evaluate whether infrastructure investments can reduce ticket volume at the source, and the Server Cost of Ownership Calculator to assess whether aging hardware is generating a disproportionate share of your ticket queue.