Same Clock, Same Tiers, One Question

At an Italian software company's help desk, tickets tagged “Value 1” take a median of 354.7 hours — 14.8 days — to reach a “Resolve ticket” event. Tickets tagged “Value 2” take a median of 140.5 hours, just under 6 days. “Value 3” sits at 160.5 hours, 6.7 days. Read as three numbers side by side, the slowest tier's median is 2.53 times the fastest tier's — exactly what a tiered support system is supposed to produce.

That is the whole premise of tiered support: a priority label is meant to set a resolution-time target, with higher-urgency tickets held to a faster clock. Industry ITIL guides describe critical tickets targeted for same-day resolution on a 24x7 clock, down to low-priority tickets allowed 48 hours or more on a slower, business-hours clock. A 2.5x gap between tiers looks, at a glance, like a support system doing exactly its job.

Except that isn't quite what the company's own data says once you ask the numbers to prove it.

Four Years, 4,580 Tickets, Three Tiers

The event log behind this analysis records 21,348 timestamped activities across 4,580 distinct support cases, running from January 13, 2010 to January 3, 2014. Each case is tracked from the moment a ticket is inserted to the moment its issue is resolved, and the primary question here is simple: does the service-level tier attached to a case predict how long that resolution takes?

The underlying log is “Dataset belonging to the help desk log of an Italian Company,” released by Mirko Polato in 2017 on 4TU.ResearchData — a compact, real, openly licensed file that has since become a standard benchmark in process-mining research, reused far beyond its original operational purpose.

On average a case generates 4.66 events, and over the nearly four-year span the log implies a rough intake pace of about 3.16 new cases per day — a small, steady operation, not a call-center at industrial scale.

The three tiers analyzed are far from evenly sized: Value 2 accounts for 3,527 of the 4,566 cases in the primary analysis — 77.2% of the total — while Value 3 holds 924 cases (20.2%) and Value 1 just 115 (2.5%), a 30.7x gap between the largest and smallest tier. A fourth tier, Value 4, appears in only 3 cases and is excluded from the comparison entirely.

One thing the data cannot tell you: what “Value 1,” “Value 2,” and “Value 3” actually mean. The service-level field is released as anonymised codes, with no published key mapping them to real urgency, customer segment, or SLA target. The tiers cannot be assumed to run low-to-high the way P1–P4 priority levels typically do — a constraint that shapes everything that follows.

What the Effect Size Actually Says

Here is the statistical trap this dataset sits directly on top of: with thousands of cases, a hypothesis test gains enough power to flag even a trivially small true difference as “significant.” A p-value alone cannot tell you whether an effect is large enough to matter — only an effect size can.

Applying the standard interpretive scale for this kind of test (below 0.01 is “negligible,” 0.01–0.04 is “weak,” and it climbs from there), three of the four statistical checks run on this data land squarely in “negligible” territory: the primary resolution-time test (epsilon-squared = 0.0011), a check that drops ambiguous cases (0.0011), and a check that redefines the tier by its first-observed value instead of its most common value (0.0016). Only one variant — swapping the outcome to the full time-to-closure — clears the negligible line, and even then it only reaches “weak” (0.0126), nowhere near “moderate.”

Ranking all four tests by p-value and by effect size produces the identical order both times, which matters: it means the differences in significance across these four checks aren't a fluke of shifting sample size (every variant sits between 4,525 and 4,577 cases) — they track a real, if still small, difference in how much the closure-time outcome explains compared to the resolution-time outcome. That top variant's effect size is 11.4 times the primary test's, and it is still only “weak.”

None of the Pairs Survive Correction

Break the three-tier comparison into its three individual pairs and the picture holds. Only Value 2 vs Value 3 has a p-value under 0.05 before any correction (0.0473); Value 1 vs Value 2 (0.0517) and Value 1 vs Value 3 (0.3503) are already not significant on their own. Apply the Holm correction that a fair three-way comparison requires, and Value 2 vs Value 3's p-value rises to 0.1418 — the one pairwise gap that looked real evaporates the moment multiple comparisons are accounted for properly.

This isn't a case of comparing an unreliable grouping variable, either: 4,537 of 4,580 cases (99.06%) have one single, internally consistent service-level value across every event in that case. Only 43 cases (0.94%) show any ambiguity at all, which is exactly why redefining the tier by its first-observed value instead of its most common value barely moves the result.

There is one genuine small-sample wrinkle worth flagging: Value 2 and Value 3 both show the classic shape of duration data, with the mean sitting well above the median (Value 2's mean is 1.84x its median; Value 3's is 1.81x) — a few very slow tickets pulling the average up. Value 1 does the opposite: its mean (334.6 hours) sits slightly below its median (354.7 hours). With only 115 cases, that inversion is a small-sample quirk, not evidence of a different underlying process.

The Fastest Tier Has the Biggest Hidden Delay

Here is where the tiers do diverge — just not in resolution speed. Subtract each tier's median resolution time from its median time-to-full-closure, and an administrative gap appears: 635.3 hours for Value 1, 819.3 hours for Value 2, and 770.3 hours for Value 3. Because that gap is large and runs roughly the same size across all three tiers, the tier-to-tier spread nearly disappears once you look at full closure time instead of resolution time: medians vary by 153% across tiers on resolution time, but by only 6% on closure time.

The sharpest illustration: Value 2 — the tier that resolves tickets fastest, at a 140.5-hour median — carries the single largest administrative gap of the three, at 819.3 hours. Its overall time-to-closure (roughly 959.8 hours after that gap is added back) ends up close to Value 1's, despite resolving tickets 2.5 times faster. Whatever weak signal the tier attribute does carry in this data lives almost entirely in a roughly tier-invariant delay that happens after a ticket is already fixed — not in how quickly anyone actually worked it.

That distinction matters operationally. The premise of a service tier is to compress the clock on the actual work. If the real variability sits in a post-resolution administrative process instead, then the tiering system isn't the lever a company would reach for to speed things up — the closure workflow is.

What the Labels Don't Tell You

One more check, using nothing but the labels themselves: if Value 1, 2, and 3 corresponded to a descending or ascending urgency ladder, resolution-time medians should move monotonically with that order. They don't. Ordered by label, the medians run 354.7, 140.5, 160.5 hours — neither rising nor falling in sequence. The actual fastest-to-slowest order is Value 2, then Value 3, then Value 1.

That's consistent with the earlier caveat: these codes are anonymised, and nothing in the public data confirms they were ever meant to behave like a graduated scale in the first place.

A small, separate quirk: 11 of the 4,580 cases (0.24%) never generate a “Resolve ticket” event at all — they simply have no resolution timestamp anywhere in their history, and drop out of every resolution-time comparison in this piece as a result. They're rare enough not to change any conclusion, but real enough to note.

The Question a Tier System Should Answer

None of this means the service-level field is meaningless — cases still carry the label, and the label may correlate with things this dataset can't see: customer type, contract terms, ticket complexity. What the data does say is narrower and more useful: on this help desk, across four years and 4,566 tickets, knowing a case's tier tells you almost nothing about how fast it got resolved.

Companies build and staff tiered support on the premise that the tier is an operational lever — something that, when pulled, changes how fast work gets done. If a help desk's own historical data shows that lever barely moves resolution speed, the more useful question stops being “should Tier 1 be faster than Tier 2” and becomes “what is actually setting the clock here” — a question this dataset's own administrative-delay pattern already points toward, and one the underlying company would need its unanonymised records to fully answer.