Research · · Verified
What Happens to Exception Aging When an Offshore Team Adds a Client?
An event-window study for measuring how a new client changes exception inflow, aging, and recovery time in an existing queue.
On this page
Research question and decision supported
The question is how adding a client changes the age of exceptions in an existing offshore queue, and how long the queue takes to return to its prior pattern. The decision supported is whether to add capacity, stage the onboarding, change the exception threshold, or protect a review lane during the transition. A new client adds volume, but it also adds new instructions, new tools, and new exception types. The method measures the queue before, during, and after the onboarding window. It separates the new client's own exceptions from the effect on existing clients.
State whether the decision is about capacity, launch staging, exception thresholds, or review coverage. The same data can support different choices, so name the one the study is meant to inform. Report the other effects as context. This keeps the analysis from becoming a general post-launch narrative.
Define the event window
Mark the date the new client's work enters the live queue, not the date the contract was signed. Record the preparation period, the first live week, and the stabilization period. If the client is onboarded in stages, define each stage and the volume that came with it. Use the same queue and the same exception definition throughout the comparison. State whether the new client's exceptions are included in the main queue or held in a separate lane. The window should be long enough to cover at least two full review cycles after the first live week. A short window can capture the initial spike but not the recovery.
Record the first live date for each work stream and the date the client's volume reached its planned level. If those dates differ, use both and explain the choice. A launch that ramps over several weeks has more than one event. The comparison should reflect the ramp rather than a single day.
Set the comparison period
Use a baseline period with a stable client mix and a comparable season. Match the baseline to the event period by weekday count and holiday exposure, because a month with an extra working day will look different. Record the volume, the staffing, the reviewer count, and the exception threshold for both periods. If the team also changed a tool or a process at the same time, note it as a confounder. A before-and-after comparison is only useful when the surrounding conditions are described. Do not compare a quiet summer month with a peak launch month without saying so.
List the known differences between the baseline and the event period, including holidays, volume, staffing, and tool changes. If a difference is large, consider a second baseline or a matched week. A simple before-and-after is acceptable when the differences are stated, not hidden. The reader should be able to judge whether the comparison is fair.
Measure inflow and aging together
Report the number of new exceptions, the open count at the end of each week, the median age, and the 75th percentile age. A stable inflow with rising age suggests a capacity or release problem, while a rising inflow with stable age may mean the team is absorbing the work. Show the oldest open item and the number of items older than the team's service target. Break the aging down by client so the new client's items do not hide the effect on existing clients. Use business days where the service clock uses business days, and state the time zone.
Show the weekly inflow, the open count, and the age percentiles in one table. A stable open count can hide a rising age if the mix changed. Add the number of items that breached the service target. The table should make the queue's behavior visible without a long explanation.
Separate new-client exceptions from existing-client exceptions
A new client will generate its own exceptions because the instructions, access, and data are unfamiliar. Report those separately from exceptions in established lanes. Compare the existing-client aging with the baseline, because that is where the spillover appears. If existing-client aging rises while new-client aging is stable, the team may be protecting the new work at the expense of the old. If both rise, the constraint may be shared review capacity. If neither rises, the onboarding may have been well staged. The split is essential for deciding where to add support.
Report the two groups with separate denominators and separate age measures. If the new client's exceptions are held in a different lane, say so and explain how they are counted. Check whether a shared reviewer serves both lanes. The spillover is most likely to appear in the shared resource, not in the new client's own queue.
Watch for queue starvation and priority shifts
A new client often arrives with a priority rule that pushes its items ahead of established work. Check whether the queue order changed, whether reviewers were reassigned, and whether the new client received a dedicated lane. Look at the age of low-priority items in the existing lanes, because starvation can appear there before it shows in the average. Review the escalation log for items that were raised only after a deadline slipped. Ask the team which work they deferred during the first two weeks. A new client can improve the average while making a subset of work much worse.
Read the escalation log and the oldest-item list, not only the average. Ask the team which work was deferred and whether the deferral was approved. Check whether the new client's due dates were used to reorder the whole queue. A priority change can improve the headline age while making a subset much worse.
Measure recovery time
Define recovery as the first week when existing-client aging returns to the baseline range and stays there for two consecutive reviews. Record the time from the first live week to that point. If the queue does not recover within the planned window, identify whether the constraint is volume, review capacity, access, or instruction quality. Compare the recovery with the onboarding plan and the capacity that was added. A recovery that depends on overtime or a temporary reassignment is not stable. Report the recovery time with the conditions that produced it.
Define the baseline range before looking at the post-launch data. Use the same definition for every launch so the recovery times are comparable. State whether recovery required overtime or a temporary reassignment. A recovery that depends on an unsustainable measure is not a stable result.
Use the result to change one onboarding decision
Choose one change for the next client launch. If existing-client aging rose, stage the volume or reserve a review lane for established work. If new-client exceptions dominated, improve the intake or the instruction pack before go-live. If recovery took too long, add capacity earlier or narrow the first scope. Assign an owner and a review date, and repeat the same measurement for the next launch. Do not change the exception definition between launches if the team wants to compare. The result should make the next onboarding decision more specific, not just more cautious.
Choose a change that can be tested at the next launch, such as a staged volume or a protected review lane. Write the expected effect and the measure that will show it. Keep the same exception definition and the same baseline method. The next launch then becomes a deliberate test rather than another uncontrolled change.
Limitations
The method is observational and cannot isolate the new client from every other change in the period. Queue records may not capture informal reprioritization, and a small team may have too few exceptions for a stable percentile. The baseline may differ in seasonality, staffing, or client mix. Recovery depends on the definition used and the review cadence. Report the confounders, the sample size, and the baseline conditions. Use the finding to plan a staged launch or a capacity buffer, not to prove that adding a client always causes a specific delay.
The study is observational and the launch may coincide with other changes. Queue records may not capture informal reprioritization, and a small team may have too few exceptions for stable percentiles. Recovery depends on the definition and the review cadence. Report the confounders and use the result to plan a staged launch or a capacity buffer.