Measuring rework in outsourced administrative queues

Research findings

Rework is one of the few quality measures a small operations team can collect without a new dashboard, yet it is often reported without a definition. Two managers can agree that a queue has too much rework and still count different things. One counts reopened tickets, another counts corrected entries, and a third counts anything the owner had to touch twice. The disagreement is not about the data. It is about the unit of analysis. This review states the unit first so the rest of the method can be read against it.

This review treats rework as a completed work item that had to be repeated, corrected, or reopened because the first completion did not meet the stated acceptance rule. The population is items marked complete during a declared window. An item enters the rework count once, even if it is corrected several times, and the reason for the first correction is recorded. That rule keeps a single bad item from inflating the rate.

The acceptance rule has to exist before the count means anything. Write what a completed item must contain: the source document, the correct destination entry, the owner who approved an exception, and the time of completion. If the rule is vague, the reviewer is really measuring personal preference. A short written rule lets two reviewers classify the same item in the same way.

Use the queue's own events where possible. A reopen, a rejected review, a correction entry, or a second approval are observable signals. Each signal should carry a timestamp and a reason code that someone chose at the time. Reason codes typed from memory a week later are weak evidence, so collect the reason when the correction happens.

Report rework with its denominator in the same sentence. Saying that a queue had forty corrections is not a rate until you say how many items were completed in the window. Report the eligible count, the excluded count and why, and the number of items with at least one correction. A percentage without those three numbers is difficult to defend. Keep the definition visible beside the rate in every report. That habit keeps the review honest.

Discussion

Rework also has a time cost that the queue may not record. A corrected item can consume a second pass, an owner message, and a customer follow-up. If the team tracks time, separate first-pass time from correction time rather than blending them. Blended time hides the cost of the defect and makes a slow month look like a staffing problem.

The most useful cut is by cause, not by person. Group the reasons into missing source, unclear instruction, access problem, judgment call, and system error. A cause view points to a fix in the brief or the tool. A person view invites blame and usually produces fewer recorded reasons. Keep individual names out of the aggregate report.

Implications and limits

Sampling matters more than the size of the spreadsheet. Use a consecutive or systematic sample from the completion log, and include items closed near the end of the window. Items that are easy to find in a search are often the ones that were already discussed, which biases the review toward known problems. Record where collection stopped.

Read the result as a description of one queue in one window. The rate depends on the work mix, the reviewers, the acceptance rule, and the systems in use. It does not prove that an outsourcing partner is good or bad, and it should not be used to compare two teams that do different work. Use it to choose one control to improve and to check whether the change helped.

A second reader is the cheapest test of the definition. Give the same protected sample, the same acceptance rule, and the same source access to an independent reviewer. Compare the classification, the stated cause, and the close condition. Disagreements about policy go to the owner, while disagreements about fact go back to the source. Record both readings before resolving them.

A sampling plan for rework

Freeze the window and the inclusion rule before pulling the sample. Include items completed, reopened, and corrected in the window, and exclude items that never reached completion. Use a stable key across the queue and the destination system so a corrected item is not counted twice. Write the extraction date and the person who ran it.

Choose a sample size the team can actually review each month. A small consecutive sample reviewed carefully is more useful than a large export nobody reads. Include at least one adverse case, such as a missing source or an unavailable owner, so the review tests the hard path. Keep the working file in an approved location with access limited to the reviewers.

Reading rework without overclaiming

Separate first-pass acceptance from eventual completion. A queue can have a high correction rate and still close most items on time, which tells you the review catches defects before customers see them. The opposite pattern, low corrections with later complaints, suggests the review is too shallow. Report both acceptance and complaint signals.

Do not compare rates across queues with different acceptance rules. If one team writes a strict rule and another writes a loose one, the stricter team will look worse while producing better work. Publish the rule beside the rate and note any change to it during the window. A rate without its rule is not comparable to anything.

What to change after the review

Pick one cause and one control. If missing sources dominate, change the intake check. If unclear instructions dominate, rewrite the example set. If judgment calls dominate, narrow the role's authority or add a named decision owner. Give the change an owner, a date, and a retest window.

Retest with the same definition so the comparison means something. If the definition changes, treat the result as a new baseline rather than an improvement. Record what changed in the brief, the system, or the review process. A control that is not retested is only a suggestion.

Recording the review

Keep a short review sheet beside the sample so a later reader can follow the work. Record the window, the inclusion rule, the sample method, and the name of the person who extracted the data. List the correction reasons in the order they appear in the sample. A sheet that cannot be reproduced is only an anecdote with formatting.

Name the reviewer and the date on the sheet, and note any source that was unavailable. If a record was restricted, say so instead of treating it as clean. Record the second reader's classification separately before the two reviewers discuss the case. That order keeps the disagreement visible.

Store the working file in the approved location and limit access to the review group. Remove the file when the retention period ends. A rework review contains customer and employee details that should not circulate with the summary. Keep the aggregate report separate from the working sample.

Questions