Help-desk case resolution time by service level

Summary

Using the event log of an Italian company's help desk (21,348 events across 4,580 support cases, 2010–2014), we asked whether the time taken to resolve a ticket differs across the service-level tiers recorded for each case. Because the log records multiple events per case, we aggregated it to one row per case and used the case as the unit of analysis, guarding against pseudoreplication. The primary outcome was the time from a case's first event to its first "Resolve ticket" activity.

A Kruskal-Wallis test across the three well-populated tiers (Value 1, n=115; Value 2, n=3527; Value 3, n=924) was statistically significant but with a negligible effect size (H=7.05, df=2, p=0.029, epsilon-squared=0.0011). No pairwise difference survived Holm correction (all corrected p ≥ 0.14). The practical conclusion is that case handling time is essentially the same across service tiers. A robustness check using the full time-to-closure outcome instead produced a much smaller p-value (p≈1.0×10⁻¹³) but a still-small effect (epsilon-squared=0.0126), indicating that the modest tier differences that do exist are concentrated in administrative closure timing rather than in how quickly tickets are actually resolved. The finding was stable when ambiguous cases were dropped and when the service level was defined by its first observed value.

Provenance and methods

Source data. The analysis uses finale.csv from the dataset "Dataset belonging to the help desk log of an Italian Company" (DOI 10.4121/uuid:0c60edf1-6f83-4e75-9367-4c63b3e9d5bb), distributed under the 4TU.ResearchData General Terms of Use. The file (3,271,588 bytes, md5 a91d74377c55be5cbdfda05dae69db30) is a process-mining event log with one row per recorded activity. The analysis script downloads the canonical copy and verifies its md5; if the download is unavailable it falls back to a local copy that is also md5-gated, so a checksum mismatch is a hard failure.

Aggregation to case level. Each of the 4,580 cases (Case ID) comprises 2–15 timestamped events (median 4). For every case we computed: the number of events; the throughput time (first to last event); the resolution time (first event to first "Resolve ticket" event); and the case's service level as the modal service_level value across its events. Timestamps were parsed with the format %Y/%m/%d %H:%M:%S.%f.

Grouping variable. service_level takes four values. Value 4 occurs in only 3 cases and was excluded a priori; the analysis compares Value 1, Value 2, and Value 3. The attribute is near-constant within a case: only 43 of 4,580 cases (0.9%) show more than one distinct service level.

Statistical tests. Resolution time is strongly right-skewed, so we used nonparametric methods throughout. The primary test was a Kruskal-Wallis H test across the three tiers, with epsilon-squared as the effect size. Follow-up pairwise comparisons used Mann-Whitney U tests (three pairs) with Holm correction for multiple comparisons and rank-biserial correlation as the pairwise effect size. All random operations (jitter in the figure) use a fixed seed (20240517).

Pre-registration. The question, outcome definition, grouping, exclusion of Value 4, primary test, correction method, and the three robustness/sensitivity checks below were fixed before the confirmatory tests were run.

Data records

The analysis derives the following records, all reproduced by analysis.py:

• Case-level table (in-memory): one row per Case ID with n_events, throughput_h, resolve_h, modal service_level, first-observed service_level, and an ambiguity flag.
• tables/tbl-1-resolution-summary-by-tier.csv — per-tier count, median, mean, quartiles, minimum and maximum of resolution time (hours).
• tables/tbl-2-robustness-sensitivity.csv — Kruskal-Wallis statistic, df, p, epsilon-squared and n for the primary test and the three robustness/sensitivity variants.
• tables/datapackage.json — a Frictionless tabular-data-package describing both CSVs (field names, types, descriptions).
• results.json — every statistic reported here, including the pairwise Mann-Whitney results with Holm-corrected p-values and rank-biserial effect sizes, and the run metadata (seed, md5, counts, time span).
• figures/fig-1-resolution-by-service-level.png — distribution of resolution time by tier (violin + jittered points + median), log-scaled.
• figures/fig-2-robustness-sensitivity.png — effect size and p-value across the primary and robustness variants.

Technical validation

The event log has no missing values in any column. All 4,580 cases have valid timestamps; 4,569 have at least one "Resolve ticket" event (11 cases never reach resolution and are absent from the resolution-time analysis but present in the throughput check). The primary comparison therefore rests on 4,566 cases (the 4,569 with a resolution time minus 3 in the excluded Value 4 tier).

The conclusion is robust to two analytic choices. Dropping the 43 cases whose service level is not constant within the case leaves the result essentially unchanged (H=7.09, p=0.029, epsilon-squared=0.0011). Defining the service level by its first observed value rather than the mode gives a slightly larger but still negligible effect (H=9.28, p=0.010, epsilon-squared=0.0016). The alternative outcome — full time-to-closure — yields a far smaller p-value (H=59.86, p≈1.0×10⁻¹³) yet an effect size (epsilon-squared=0.0126) that remains small by conventional benchmarks, locating whatever tier signal exists in the closure phase rather than in resolution speed.

Re-running analysis.py reproduces every number in results.json and regenerates every figure and table.

Usage notes

The service-level, seriousness, and section fields are anonymised categorical codes ("Value 1", "Value 2", …); their real-world meaning is not recoverable from the log, so the tiers cannot be ordered by any external criterion and no causal interpretation is warranted. All times are in hours. Throughput-to-closure is dominated by a roughly fixed administrative delay between resolution and closure and should not be read as handling effort; the resolution-time outcome is the appropriate measure of how quickly tickets are worked. This is an observational event log: differences across tiers may reflect ticket mix, staffing, or routing rather than the service level itself.

Code availability

The complete analysis is contained in analysis.py, which is self-contained and reproducible: it acquires and md5-verifies the source file, sets all seeds, runs the pre-registered tests, and writes every figure, table, and results.json. The Python version and full dependency list are recorded in environment.txt.

Claims

1. Across the three well-populated service-level tiers, case resolution time differs to a statistically detectable but practically negligible degree (Kruskal-Wallis H=7.05, df=2, p=0.029, epsilon-squared=0.0011, N=4566), and no pairwise difference survives Holm correction (all corrected p ≥ 0.14). 2. The negligible resolution-time difference is stable under sensitivity analyses: dropping the 43 within-case ambiguous cases (H=7.09, p=0.029, epsilon-squared=0.0011) and using first-observed rather than modal service level (H=9.28, p=0.010, epsilon-squared=0.0016) both leave the effect negligible. 3. When the outcome is instead the full time to case closure, the tier difference is far more significant but still small in magnitude (H=59.86, df=2, p≈1.0×10⁻¹³, epsilon-squared=0.0126, N=4577), indicating the signal lies in administrative closure timing rather than in resolution speed.