Owner Switch Cost in Outsourced Exception Handling

Research findings

This protocol asks what happens to an outsourced exception when its owner changes before the case closes. Define the population as exceptions that changed owner at least once during a declared window in one workflow. The unit is one exception linked to every owner period, handoff note, decision, and close event. Record the inclusion rule before extracting records.

Owner switches are not inherently defects. A case may move to the right specialist, a backup may cover an absence, or a manager may take a policy decision. The study separates ordinary routing from switches that repeat, stall, or lose evidence. It does not assume that fewer switches are always better.

Build the frame from the exception log and the assignment history. Include cases that moved between people, teams, and queues. Exclude cases that were reassigned before any substantive review only if the protocol says so, and report the number excluded. Keep a stable key so a case that changes systems does not become two cases.

For each owner period, record the start and end time, the owner role, the handoff note, the pending decision, and the evidence available at the switch. Preserve the note as written and note whether the receiving owner acknowledged it. A switch without an acknowledgement is a different event from a switch with one.

Define the measures in advance: switches per exception, repeated switches, time to first substantive action after a switch, evidence lost or recreated, owner wait, and reopen rate. A switch that transfers a complete packet may cost little; a switch that forces the new owner to rebuild the case may cost a great deal. Report the distribution, not only the average.

Discussion

Reconstruct a protected sample of cases across one-switch, multi-switch, and same-owner comparisons. Separate time spent waiting for the previous owner, the new owner, a customer, or a system. Do not count parallel intervals twice. When the handoff note is missing, mark the interval as unclassified rather than assigning it to a cause.

Use an independent reviewer to classify the same cases with the same codebook. Compare whether the switch was necessary, whether the note was sufficient, and whether the new owner repeated work. Disagreements about necessity return to the workflow owner. The study can describe patterns but cannot prove that a particular switch caused a later error.

Implications and limits

Protect the extract and the handoff notes. Handoff text can contain customer, employee, or commercial details, so keep only the fields the study needs and restrict access. NIST privacy and access concepts support the handling design; they do not make the notes accurate. Report the fields that were unavailable or redacted.

Owner-switch cost is sensitive to workflow, case mix, staffing model, and the definition of a substantive action. Test the results with a narrower window and with cases that have complete handoff notes. If the direction changes, present both results and explain which decision depends on the choice. Avoid turning a descriptive finding into a claim about worker quality.

The practical output is a short list of repair options: require an acknowledgement for high-consequence switches, standardize the handoff packet, name a backup before absence, or reduce the number of queues a case can enter. Each option needs an owner, a success signal, and a review date. The study supports a decision; it does not make it.