Estimating rework in task queue from correction and reopen records

Research findings

## Question and scope The protocol does not estimate an industry benchmark; it produces a local description that outsourcing company operators can review. Record the opening count, additions, withdrawals, resolutions, and unresolved items at the end of the window. Record how corrections, reopens, and duplicate requests are treated so timekeeping exception rate cannot be inflated by reclassification. Write the decision the study is meant to inform before choosing the measure. If the case moved between owners, include both owner periods in the review note and name the handoff time. This protocol asks how task queue can be described from the operational record in outsourced operations without turning a completion count into a quality claim. The population should include cases handled by every owner and channel in scope, not only the queue with the cleanest records. A case is complete only when the timekeeping system shows the approved destination value and the client report supports it. Keep the protocol with the task queue batch so the next reviewer can see what was measured. Keep the review note with the case so the next sampler does not have to reconstruct the decision from memory.

## Population and unit A population that changes size during the day should be reported with the start, end, and net change, not only the closing total. Report the number of cases that could not be classified and the reason, rather than forcing them into a category. The stop event should be the verified destination update, not the last message in the thread. Separate cases opened before the window from cases opened and closed inside it, and report both counts. When a value is missing, record the missing state and the reason instead of leaving an empty field in the extract. A population that changes size during the day should be reported with the start, end, and net change, not only the closing total. Record the queue at the start and end of each observation day so additions and withdrawals are visible. If the definition of rework rate changes, keep the old and new values side by side for the transition period. If the queue was archived during the window, report the loss and exclude the affected period rather than assuming the cases were resolved. At Outsourced Company, the task queue review should end with a dated note and a named owner for the next check.

## Definitions and measures Test each definition on a routine case, a missing-evidence case, and a case that crossed owners. Use a stable case key and a separate identity crosswalk stored in an approved system. Define whether a case that waits for a third party is open, paused, or excluded, and apply that rule to every owner. Give one concrete example and one boundary case to each reviewer before collection begins. If the evidence is sensitive, record the approved reference and access path rather than copying the content. Define how a correction after close is linked to the original case and whether it creates a new case. Use a stable case key and a separate identity crosswalk stored in an approved system. Record the person who approved the definition and the date it became effective. If two reviewers disagree, preserve both classifications until the definition is clarified. The note should distinguish what was observed, what was inferred, and what still needs an owner decision.

## Data dictionary and evidence Each case needs the source, the observation time, the field supported, the owner, and the reviewer. Keep the identity crosswalk in the approved system and restrict it to the review owner. Keep the source reference and the coded value in the same row, and do not overwrite the original with a later correction. Pilot the dictionary with two reviewers and compare their classifications before the main sample. Record this decision in the study log with the case key, the review date, and the person who approved the classification. Keep free-text notes separate from coded fields so the analysis does not depend on inconsistent wording. If a field is derived, record the formula and the source fields used to calculate it. Store sensitive evidence in the approved repository and keep only the reference in the analysis file. Define who may change a coded value and how the change is logged. Keep the evidence reference beside the coded value so a reviewer can test the same case without rebuilding the queue. Each case needs the source, the observation time, the field supported, the owner, and the reviewer. Record the extraction time separately from the event time so a late entry is visible. Keep the original evidence reference next to the coded value so the reviewer can verify the classification. Do not use a zero or an empty string to represent missing evidence. If the source changes after the observation, preserve the earlier value and add a dated note instead of replacing it.

Discussion

## Sampling and collection Stop expanding the sample only when the review question is answered, not when the result starts to look favorable. A second reviewer should re-extract a small subsample and record disagreements before the full analysis. A sample of recent closures can miss the oldest unresolved work, which is often the most informative. A case that is difficult to access is still part of the frame; report the access failure rather than replacing it silently. At Outsourced Company, the reviewer should be able to explain this step to team lead from the case record alone. If the population is small, report every case and the reason the sample is exhaustive rather than presenting a false precision. Do not clean the data by filling missing values; preserve the missing state and report it as a result. Keep the sample selection reproducible by recording the export date, filter, and random seed or start rule. A case that is difficult to access is still part of the frame; report the access failure rather than replacing it silently. Use the same note in the case file and the study extract; do not create a second version in a personal document. Sample across the full observation window, including the days when the queue was busiest and the days when coverage changed. Collect the case from the team roster, the timekeeping exception, and the approval record, and stop at the verified close. Use a random or systematic start rule and then take consecutive cases within each stratum. Record the date of the sample and the version of the queue export. When a case needs an exception, record the reason, the owner, and the date before continuing the review.

Implications and limits

## Analysis and reporting For task queue, report the age distribution and the share of cases waiting on a named decision rather than a single average. If two measures disagree, report both and explain what each one counts. Write the finding in plain language and separate what was observed from what the team believes caused it. Use a case-level table to explain an outlier before treating it as a process signal. Keep the measurement note short enough to read with the case and specific enough to support the reported task cycle time. State which findings are descriptive and which require a follow-up test with a larger or different sample. If two measures disagree, report both and explain what each one counts. Use a simple before-and-after comparison only when the definitions and observation window are the same. Report the number of cases that drive a small-sample result and the direction of the effect. If two reviewers disagree, preserve both classifications until the definition or the evidence is resolved.

## Limitations Report what remains unknown and what evidence would be needed to answer the next question. The study cannot determine whether a professional judgment was correct, only whether the record supports it. If the reviewer also performed the work, note the independence limitation and use a second reviewer for a subsample. Record the access problems that prevented a case from being reviewed. Link the observation to the exact field in the team roster and to the timekeeping exception that supports it. The cited public sources frame recordkeeping, privacy, security, or control practice; they do not provide a local result. Report the unknown population and the evidence that would be needed to describe it. Do not treat a missing record as proof that the work did not happen; it is evidence about the record. A missing record is evidence about the record, not proof that the work was never done. Do not let a summary written later replace the evidence that was available at the first decision.

## Review and next action If the action affects unowned task, route it to client sponsor and record the approval before implementation. Repeat the protocol with the same definitions and window, then compare the same measures. Set the next sample date before closing the review, so the action does not drift. Close the review when the owner accepts the finding and the next test is on the calendar. If the case moved between owners, include both owner periods in the review note and name the handoff time. Record the decision and the next check so the study does not end as an archive. If the action changes timekeeping error, record the approval from operations manager before implementation. Close the review only when the owner has accepted the result and the next check is scheduled. Record the owner, due date, and exact change that will be tested at the next review. Keep the review note with the case so the next sampler does not have to reconstruct the decision from memory.