The assignment: decide whether a response-time report is misleading
A fictional support manager receives a favorable chart: 85% of answered tickets got a response within two hours. The queue still contains frustrated customers. Your task is to reconcile the chart with the unanswered workload and propose an operating action using the ticket and event files.
The dataset has thirty tickets, public bot acknowledgments, private agent notes, human public replies, an exact event retry and two replies after the reporting cutoff. You must decide which event qualifies as a response before computing a duration. The case fixes a 120-minute elapsed-time target and a reporting instant of September 16 at 12:00 UTC.
GitLab’s support indicators distinguish different service measures and use defined reporting periods. Its production policies are not the thresholds in this exercise. Here all time is elapsed time: there is no weekend pause, business-hours calendar or claim about an employer’s contractual service-level agreement. Those additions would require a different clock.
Data and worked inputs
Sources[1]
An acknowledgment or private note is not the response being measured
Deduplicate by event ID, rejecting contradictory versions. Join every event to a known ticket; an unmatched event is an exception, not evidence to discard silently. Ignore events after the reporting instant. They are useful later, but they did not exist for this report.
For each ticket, find the earliest public human-agent event at or after ticket creation and at or before the cutoff. The bot acknowledgment at one minute does not count. The private agent note at three minutes does not count. Choosing the earliest event of any kind would make nearly every ticket appear fast without establishing that the customer received a substantive human response.
Validate time order before subtracting timestamps. A response before creation should trigger investigation. Store the original timestamp strings alongside parsed values so a timezone problem is inspectable. If you choose to add a business-hours extension later, define its calendar separately; subtracting wall-clock timestamps does not magically exclude nights or weekends.
Give unanswered tickets a state rather than an invented duration
Twenty tickets have a qualifying observed reply. Ten do not. Of the ten unanswered tickets, six are already beyond the two-hour target; four are recent enough that they may still meet it. Classify them as breached and pending respectively. Do not assign a duration of zero to the pending tickets or use the current age as if it were their final response time.
| State | Count |
|---|---|
| Replied within target | 17 |
| Replied after target | 3 |
| Unanswered and past target | 6 |
| Unanswered, still within target | 4 |
| All tickets | 30 |
| Evaluated met share | 17 / 26 = 65.38% |
Among the twenty replied tickets, seventeen meet the target and three do not. Add the six overdue unanswered tickets: the evaluated population now has seventeen met and nine breached. Four remain pending. The met share among evaluated tickets is 17/26, approximately 65.38%, compared with 17/20 = 85% among answered tickets only.
The gap is a selection effect created by the denominator. It does not prove that the first report was malicious or that a particular person performed poorly. Your job is to make the missing population visible and label the two measures so nobody mistakes one for the other.
Use the distribution without hiding the censored cases
Observed first-response durations have a median of 57.5 minutes. The nearest-rank 90th percentile is 180 minutes: sort the twenty durations and select the eighteenth value. Other percentile interpolation methods can produce different values, so record the method. A percentile without a definition can create a false disagreement between two otherwise correct implementations.
Both statistics describe only the twenty observed responses. They exclude the ten unanswered tickets by construction. Place the unanswered and overdue counts beside the distribution. A rapidly answered majority can coexist with a severely delayed tail, and the tail is precisely where an operating review may be needed.
Do not compare raw team rates as though ticket difficulty were randomized. The integration queue has six breaches and four pending tickets; the billing queue has three breaches and no pending tickets in this constructed cohort. That suggests a workload to inspect, not a causal ranking of teams. Case complexity, staffing and assignment rules are not provided.
Recommend an action the queue owner can take
A useful memo corrects the measurement and proposes a bounded response to the unresolved workload. It does not promise that faster acknowledgment alone improves resolution quality or customer outcomes.
Original fictional support-manager memo
Test the boundary that makes a pending ticket a breach
Build a ticket-level table with created time, first qualifying reply, observed duration when available, current unanswered age and classification. Keep observed duration blank for unanswered tickets. Add totals that reconcile to all thirty records and retain the event exclusions.
Advance the reporting clock without adding events. A pending unanswered ticket becomes breached only when its elapsed age is greater than the target. A reply exactly at 120 minutes meets the stated rule. Test both boundaries. Also duplicate an existing event, add a private note and add a future reply; none should create an extra customer response in the original snapshot.
Run the reference after completing your own version. The checker verifies the supplied case answers, not your readiness for a support role. The richer evidence is the table, assumptions and manager memo that another person can inspect. A chart is optional; the decision does not require a visualization library.
Data and worked inputs
Explain the measurement correction without claiming operational impact
A truthful project description is: “Analyzed a synthetic support event log and showed how excluding overdue unanswered tickets changed measured target attainment from 65.38% to 85%.” Do not say you improved a real team’s response time. This work diagnoses reporting and proposes action; it does not execute an intervention.
In an interview, be ready to explain why unanswered tickets cannot be assigned zero duration, why a private note is excluded and what would change under a business-hours clock. A useful follow-up is how to measure resolution next. You would need a defined resolution event, reopening treatment and an observation window; you cannot reuse the first-response definition unchanged.
For an original extension, add a documented priority field and report the status distribution within priority groups. Explain how the new grouping changes the operating question. Avoid making a league table from tiny groups or interpreting a descriptive difference as proof of unequal employee performance.