Why "Critical" tickets took just as long as "Low" priority ones

This case study analyzes a simulated IT helpdesk dataset of 1,000,000 tickets logged over November 2023, spanning five categories, four support teams, and four priority levels. The starting business question was simple: is the service desk actually triaging work by priority, and can leadership trust the resolution-time metrics being reported?

The analysis found that average resolution time was statistically flat across every priority level (5.24–5.25 hours), escalation rate was flat at ~50% regardless of team or category, and 30% of tickets — including 30% of tickets marked "Resolved" — had no resolution timestamp at all. None of the fields meant to differentiate how work is handled were actually doing so.

The recommendation isn't a new dashboard — it's three structural fixes: enforce priority-based SLA routing, formalize escalation criteria, and make resolution-timestamp capture mandatory before a ticket can close. Section 11 estimates the impact of the first fix alone.

IT service desks are typically built around a priority system: Critical and High priority tickets are supposed to be triaged and resolved faster than Low priority ones, because they represent bigger business impact — a down production system versus a cosmetic UI bug, for instance. Escalation exists as a safety valve for tickets that a frontline team can't resolve alone.

In this dataset, tickets are logged with a priority, a category, an assigned team, and an escalation flag — the raw ingredients for exactly that kind of differentiated service. Whether those fields are actually influencing how tickets get handled, rather than just being recorded, is the question this case study sets out to answer.

• IT Service Desk Manager — owns day-to-day triage and staffing, needs to know if priority is being honored operationally.
• Team Leads (Desktop Support, Application Support, Security Team, Network Team) — accountable for their team's resolution times and escalation patterns.
• IT Operations Director — reports SLA performance upward and needs to trust the underlying numbers.
• End users / employees — submit tickets and set an implicit priority expectation when they mark something Critical.
• Reporting / BI team — builds dashboards on top of this data and inherits any data-quality gaps silently.

A ticket is created by a user or monitoring system, assigned a category and subcategory (e.g. Security → "Suspicious DLL injection"), given a priority level, and routed to one of four teams. From there it moves through Open → In Progress / Pending / On Hold, may be escalated if the assigned team can't resolve it, and is eventually marked Resolved with a resolution timestamp recorded.

In principle, priority should compress this timeline for urgent tickets, and escalation should correlate with ticket severity and category (e.g. Security incidents escalating more often than routine hardware requests).

• Are Critical and High priority tickets being resolved meaningfully faster than Low priority ones?
• Is escalation applied consistently based on severity, or does it vary by team/category?
• Can the "average resolution time" metric currently reported upward be trusted?
• Where should the service desk focus its first improvement effort?

The dataset contains 1,000,000 tickets created during November 2023 (~33,300 tickets/day on average, with low day-to-day variance). Fields: Ticket_ID, Date_Created, Date_Resolved, Category, Subcategory, Priority, Status, Assigned_Team, Resolution_Time_Hrs, Description, Escalated.

Two things stood out before any deeper analysis: every categorical field is close to perfectly evenly distributed, and Date_Resolved is missing for 30% of tickets regardless of current status — a data-quality issue worth flagging before trusting any resolution-time KPI built on top of it.

Average resolution time and escalation rate were compared across Priority, Category, Assigned Team, and the top Subcategories (filtered to those with 500+ tickets, to avoid reading noise as signal).

The same flatness held across Category and Assigned Team, and the subcategory with the single highest escalation rate ("Access denied by SIEM policy") sat at 52.9% — only marginally above the 50% baseline, and within the range expected from sampling noise at ~2,000 tickets per subcategory. No dimension showed a meaningful, consistent effect on either resolution time or escalation.

Root cause of Finding 1 — no SLA-driven routing. Priority appears to be a field that's captured but not operationalized: there's no evidence of a queueing or routing rule that pulls Critical tickets to the front. Tickets are most likely worked in the order they arrive (or another priority-blind order), regardless of the label attached to them.

Root cause of Finding 2 — undefined escalation criteria. A flat ~50% escalation rate across every team and category is the signature of a decision with no consistent rule behind it — most consistent with escalation being left to individual agent judgment rather than tied to defined severity thresholds or ticket type.

Root cause of Finding 3 — no closure validation. The ticketing system allows a ticket to move to "Resolved" without requiring a resolution timestamp to be entered. This is a process/system gap, not a random data error — it happens at a constant ~30% rate across every status, suggesting a systemic missing step rather than occasional human error.

• 1. Introduce tiered SLA targets, enforced by routing. Define explicit targets per priority (e.g. Critical: 2h, High: 4h, Medium: 8h, Low: 24h) and route/queue tickets so Critical work is actually surfaced first — not just labeled first. Owner: Service Desk Manager.
• 2. Formalize escalation criteria. Replace ad-hoc escalation with documented thresholds tied to category and severity, and require an escalation reason code. This also makes Finding 2 auditable going forward. Owner: Team Leads.
• 3. Make resolution-timestamp entry mandatory to close a ticket. A one-line system validation rule closes the 30% data gap at the source, and every resolution-time KPI downstream becomes trustworthy without extra reporting work. Owner: ITSM platform admin.
• 4. Monitor with three new KPIs (below), reviewed weekly by the Service Desk Manager for the first quarter after rollout.

This estimate covers Recommendation 1 only (tiered SLA routing for Critical tickets), since it's the fix most directly tied to a measurable time saving. Figures are illustrative and assumption-labeled, shown per 1,000 Critical tickets so they can be rescaled to a real organization's actual ticket volume.

More views — including a live-filterable version of this dashboard — are in the Dashboard Gallery.

• "No variation" is a finding, not a dead end. It would have been easy to conclude "priority has no effect, nothing to report" — the more useful read was asking why a field that should create variation isn't.
• Data completeness has to be checked before anything is built on top of it. A resolution-time KPI is meaningless if a third of the underlying tickets are silently excluded from it.
• Structural findings transfer even from a simulated dataset. The specific numbers here are illustrative, but the pattern — fields recorded without being operationalized — is one I look for in real operational data too.