This worked example uses eight invented support cases to show how counts, duration, and open-case age fit together. It is not a benchmark and does not describe any employer, Fintwist, or Corpay Prepaid. The dataset contains synthetic identifiers only. It has no connection to payroll systems and no personal information. Its value is that every result can be checked against a small, visible set of assumptions.
The observation date is a fictional November 10. Six cases are closed, with elapsed calendar-day durations of 0, 1, 1, 2, 4, and 10 days. Two remain open, with current ages of 3 and 8 days at the observation date. The exercise assumes all timestamps use the same time zone and that the elapsed-day values have already been validated. Real analysis would need to check those assumptions first.
Start with the population statement There are eight cases in the ledger, six closed and two open. The closed share is 6 divided by 8, or 75 percent, at the observation date. That number is not a success rate. A closed case may have been resolved, withdrawn, classified as a non-exception, or closed under another rule. The example uses “closed” only as a status, and a real report would need the closure definition.
The ledger also records contacts per case: 1, 1, 2, 2, 3, 4, 2, and 3. These sum to 18 contacts. The mean contacts per case is 18 divided by 8, or 2.25. Six cases have more than one contact, so the repeat-contact proportion is 75 percent under that simple definition. None of this establishes that the contacts were unnecessary or that the underlying payments failed.
Calculate closed-case duration carefully The six closed durations sum to 18 days, giving an arithmetic mean of 3 days. After sorting, the middle two values are 1 and 2, so the median is their average, 1.5 days. The range is 0 to 10 days. The ten-day case raises the mean relative to the median, which is why reporting only one measure would hide part of the distribution.
The zero-day value needs interpretation. In this exercise it means same-day closure after rounding to whole calendar-day differences, not literally zero effort or zero elapsed seconds. A real report should use an appropriate unit and explain its rounding rule. Do not compare a whole-day measure with an hours-based service target without converting and checking how the timestamps were recorded.
Keep the open cases out of the completed-duration formula The open cases have observed ages of 3 and 8 days, but their final durations are unknown. Adding those ages to the closed-case duration list and calling the result “average resolution time” would be incorrect. Excluding them from that formula is appropriate, but they must remain visible elsewhere in the report. Otherwise the analysis would omit a currently eight-day-old unresolved case while highlighting a low median among completed work.
Show “2 open; current ages 3 and 8 days as of November 10” next to the completed-duration summary. If the cases close later, update their final durations and preserve the observation date of the earlier report. A changing result is not necessarily an error; it can reflect additional follow-up. The report should make that maturation visible rather than silently replacing historical snapshots.
Add a payment denominator only with a matching definition Suppose, separately, the fictional period contains 400 eligible expected payments and 4 distinct confirmed affected payments. The observed affected-payment proportion is 4 divided by 400, or 1 percent. The eight support cases are not used as the numerator because some may be questions, duplicates, or concerns about the same payment. The example intentionally distinguishes the case ledger from the payment-outcome count.
If you cannot link cases to distinct eligible payments, you cannot honestly calculate the affected-payment proportion from case count alone. You could report “8 cases per 400 expected payments,” which is 2 cases per 100 payments, but that is a workload ratio, not a failure rate. Name the measure according to what was counted. The label is part of the calculation’s integrity.
Test one data-quality change Imagine that the ten-day closed case lacks a valid opening timestamp after review. The duration calculation would then use five valid closed records, while one closed record remains excluded for that reason. The mean would become 1.6 days and the median 1 day. Those lower values do not prove better service; they reflect a changed input population. Report the exclusion and its impact rather than celebrating the apparent improvement.
The same principle applies to duplicate contacts, missing categories, and unresolved classifications. A data-cleaning choice can materially change a metric. Keep a small audit note identifying the record, rule, and result of the change, using synthetic or appropriately protected identifiers. Do not remove records simply because they are inconvenient or produce an unfavorable headline.
Use the downloadable exercise responsibly The accompanying fictional CSV and local calculator are teaching aids. They do not accept uploaded payroll files, call provider APIs, or send data to a server. The calculator works with aggregate numbers entered in the browser and makes the formulas visible. Do not enter employee names, account numbers, or credentials. For real analysis, use approved systems and privacy controls appropriate to the organization.
The exercise’s complete conclusion is deliberately modest: eight fictional cases, eighteen contacts, six closed cases with a three-day mean and one-and-a-half-day median, and two still open. A separate fictional payment population has a one-percent confirmed affected proportion. Keeping those statements separate is the lesson. Combining them into one unsupported provider score would discard the care used to calculate them.