Should an analyst report the mean or the median?

Choose the summary that answers the business question, and show enough context to reveal important exceptions. The mean uses every value’s magnitude; the median describes the middle of the ordered observations. In this support-ticket example, neither measure alone describes both a typical completed ticket and the long-delay problem.

The fictional dataset is for analyst interview practice across US, UK and European teams. It contains no real customer records and is not a service benchmark or a verified employer interview question.

The dashboard that seems to contradict itself

A support manager compares two sets of five resolved tickets. Earlier resolution times were 2, 3, 4, 5 and 6 elapsed hours. Later times were 1, 2, 3, 4 and 30 hours. The team’s dashboard says the median improved from 4 to 3 hours. Another report says average resolution time doubled from 4 to 8 hours.

Both calculations are correct. Four later tickets resolved within four hours, but one took 30 hours. The median highlights the middle observation; the mean reflects the large delay too. The records are not matched ticket pairs, so do not claim each of four individual customers experienced an improvement.

Calculate and verify the result in Python

This self-contained standard-library script prints ticket counts, both summaries, a threshold count and the sum of elapsed durations. It needs no package installation.

from statistics import mean, median

before = [2, 3, 4, 5, 6]
after = [1, 2, 3, 4, 30]

for label, hours in [("before", before), ("after", after)]:
    print(label, {
        "tickets": len(hours),
        "mean_hours": mean(hours),
        "median_hours": median(hours),
        "over_8_hours": sum(h > 8 for h in hours),
        "total_hours": sum(hours),
    })

assert mean(before) == 4
assert median(before) == 4
assert mean(after) == 8
assert median(after) == 3
assert sum(h > 8 for h in after) == 1

Verified output: before: mean 4 hours, median 4 hours, zero tickets over 8 hours, total 20 hours. After: mean 8 hours, median 3 hours, one ticket over 8 hours, total 40 hours.

Python’s statistics reference documents these functions. For an even number of observations, its median uses the average of the two middle values. Empty input needs handling, and missing or non-finite values need an explicit validation policy before calculation.

Turn the numbers into a useful finding

A clear finding is: “The middle resolved ticket took one hour less, but the mean increased because one later ticket took 30 hours. One of five later resolved tickets exceeded our illustrative eight-hour threshold, versus none earlier.”

The median change is a 25% decrease, and the mean change is a 100% increase. These percentages describe this tiny dataset; they do not establish a reliable population trend. The eight-hour threshold is a rule chosen for this exercise, not an industry standard or an assumed contractual promise.

The sum of durations is not staff labor time. Tickets can overlap, wait for customer replies or remain idle outside working hours. Converting 40 elapsed ticket-hours into a staffing cost would require separate handling-time data and a documented cost model.

Do not remove the 30-hour ticket just to improve the report

Start by checking whether the record is valid. Was it a duplicate, an incorrect timestamp, a reopened case or a real unresolved dependency? If it is a data error, correct it through a documented rule and preserve the audit trail. If it is a real experience, deleting it because it is inconvenient hides the problem.

You can show a sensitivity view with and without the ticket, but label it clearly. Without the 30-hour record, the later four-ticket mean and median are both 2.5 hours. That alternative describes a different population. It should not silently replace the complete five-ticket report.

Check who is missing from the dashboard

These lists include resolved tickets only. A very old ticket still open at the reporting cutoff does not appear. A team could close easy cases quickly while its open backlog grows, making a completed-ticket summary misleading as an overall service-health measure.

Pair the report with open-ticket counts, backlog age and the number of incoming tickets. Compare the same inclusion rules over time. Decide whether the analysis follows tickets created during a period or tickets resolved during a period; those are different cohorts.

For teams spanning London, Berlin and New York, clarify whether duration means elapsed hours or business hours. If it means elapsed time, calculate between correctly interpreted timestamps. If it means business time, document the relevant working calendar, holidays and handoff rules. A calendar date alone is not enough to calculate either duration precisely.

What would you recommend next?

Investigate the long ticket’s workflow without assuming a cause from this summary. Check issue type, escalation path and waiting periods. Compare a larger set of comparable tickets, preserving counts and the distribution rather than only one headline statistic.

A dashboard might show the median for the middle experience, the mean for the arithmetic average, and a threshold breach count for an operational rule. A histogram or ordered dot plot can show whether the change is broad or concentrated. Do not claim statistical significance from two five-ticket samples without an appropriate analysis.

Practice your interview answer

“I would report the mean and median together here because they reveal different parts of the experience. I would retain the valid long ticket, check the unresolved backlog and clarify elapsed versus working hours. I would then investigate the delay and compare larger, consistently defined cohorts before claiming the process improved.”

Try adding a second 30-hour ticket. The later mean becomes about 11.67 hours, while the median becomes 3.5 hours. Explain why neither result says how many agent-hours were worked.

Continue with weighted conversion rates, US and UK date parsing and business case-study practice. For coached preparation, review interview plans and availability. All sessions and feedback are in English.