Sources checked 29 October 2026. The service company, case records, and comparisons below are original hypothetical examples.
At a service company's weekly review, a dashboard labeled resolution time shows an improvement. Eight requests in an earlier cohort received a first reply after five hours on average. Eight later requests received one after an hour and a half. The operations director considers moving staff away from the team.
Then someone opens a case record. The customer received a reply after two hours, the request was closed at eight hours, reopened at sixteen, and closed again at sixty. The dashboard stopped its clock at the first reply. The customer's case continued.
Both times can describe something real. The problem is using one endpoint to answer a question about another. Before changing staffing, the director needs to decide what the dashboard is supposed to represent.
Give the model a job
A dashboard selects events, definitions, and records from a larger process. That selection makes it readable. It also sets limits on the decisions it can support.
In “Science and Statistics,” George Box argues for confronting models with observations and attending to inadequacies that matter. His discussion supports checking whether a simplification is useful for a particular purpose. It does not imply that every model is equally informative or that adding detail always improves one. [1]
For this team, first reply time may help examine acknowledgment speed. It cannot, on its own, describe how long a request remains unresolved. Rename the measure so the dashboard tells readers where its clock starts and stops.
The visual below follows one illustrative request. A short measurement window captures the reply. A longer view includes closure, reopening, and a later closure. Neither picture guarantees that the case will never reopen again.
Keep the unfinished cases in view
At forty-eight hours, all eight earlier requests have a recorded closure, averaging twenty-six hours. In the later cohort, only three requests are closed, averaging ten hours. Four are known to remain open, and one has an unknown closure status.
An average over those three closed requests looks encouraging. It describes a selected subset. It does not estimate the final average for all eight requests. Removing the unfinished work from the display makes the comparison easier to misread.
For a case known to be open at the observation cutoff, the eventual completion time is beyond what has been observed. NIST describes the corresponding right-censoring issue in reliability data: some event times lie beyond the end of observation. Applying that distinction to these service cases is a methodological analogy, not a reliability study of support teams. [2]
Unknown status is a separate problem. We cannot assume that the missing record describes either an open or a closed case. Keep it labeled as unknown until the record is reconciled. Giving it a zero duration, or the current cutoff time, would invent an outcome.
Change the boundary and read the denominator
The playground contains the same two groups of eight requests. Change the endpoint from first reply to observed closure. Then extend the follow-up period from forty-eight to ninety-six hours.
Three later closures now appear. Six later requests are closed, with a mean of forty-three hours; one remains open and one remains unknown. The comparison has changed because more of the process is visible. This still does not establish a final mean for the complete cohort.
You can also exclude reopened cases or omit records with unknown status. Watch both the average and the included count. The tool always reports how many original records each filter removes. A comparison between selected subsets needs a different interpretation from a comparison between the full submitted cohorts.
The data table lets you inspect each request. All requests begin at hour zero for this demonstration, so the cutoff gives them equal follow-up. Real cohorts may contain requests opened on different days. Their ages need explicit treatment before combining them.
Add the information that could change the action
The next dashboard need not contain every event. A clear first-reply measure, a count of requests still open, an explicit unknown-status count, and a carefully labeled closure summary may answer the immediate review questions. Keep access to the underlying case histories.
Choose additions because they could alter the decision. If staffing is under review, repeated visits and unresolved workload may matter. If the question is whether customers receive acknowledgment promptly, first reply time remains relevant. A useful representation depends on its intended use.
Before the next staffing meeting, take three records that the current headline fails to explain. Write down the opening event, first reply, later state changes, and observation cutoff. Reconcile the unknown record separately. Then replace the ambiguous dashboard label and ask which staffing conclusion the available evidence can support. Leave the decision open where the case history is still incomplete.
Sources
[1] George E. P. Box, “Science and Statistics” (1976). Original essay, especially sections 2.1–2.4. Used for model checking, not attribution of the map–territory phrase.
[2] NIST/SEMATECH e-Handbook, “Censoring”. Technical explanation of observation cutoffs; service examples and decision prompts here are original.
One email when we publish. Research, product decisions, and what teams report back.
