Why task batching breaks down in outsourced operations

Research findings

Batching is appealing because it reduces switching. Instead of answering messages one at a time, a coordinator sets aside a block and works through a list. The logic is sound for some kinds of work. The trouble begins when a batch is treated as a delivery promise, and a request that arrived at nine in the morning waits for a block that starts at four.

This review looks at batching as a queue design choice rather than a personal habit. The population is recurring tasks assigned to an outsourced role, and the unit is one task with its arrival time, start time, and completion time. The aim is to identify when a batch improves throughput and when it simply moves waiting out of sight. The same method can be repeated for another queue without changing the definitions.

The first distinction is between independent and dependent work. A batch of data clean-up items can be processed in any order because each item stands alone. A batch of customer replies is different, because one reply may change what the next customer needs. When dependencies exist, a large batch can carry an early mistake through every item before anyone notices.

The second distinction is between a batch and a backlog. A batch has a planned size and a planned review. A backlog is whatever accumulated because no one set a limit. Teams often describe a backlog as batching to make it sound intentional. The test is simple: can the coordinator state the batch size, the start time, and the review step? If not, it is a backlog.

Batching also affects the handoff. A coordinator who works through a batch may finish at the end of a shift with several items half done. The next person inherits a list without knowing which items were reviewed. A batch should end at a clean boundary, with completed items recorded and open items named. Otherwise the efficiency gain is paid for by the next shift.

The right batch size depends on the cost of switching and the cost of waiting. If switching takes ten minutes and the customer expects a reply within an hour, a small batch may be the only workable option. If switching is cheap and the work is independent, a larger batch can be efficient. Write the trade-off down instead of assuming one answer fits every queue.

Time zones add another constraint. A batch that starts at the end of an offshore shift may land in the client's morning with no one available to answer questions. A batch that starts too early may fragment the day into waiting. Plot the batch against the overlap window and the reviewer's availability, not only against the coordinator's preference.

Measure the effect with arrival time, start time, and completion time for each item. A batch that improves completion time but increases the oldest waiting item may be trading one problem for another. Report the age of open items at the end of each block, because that number shows whether the batch is clearing the queue or just processing the easy items. Plot the oldest open item beside the average so the tail is not hidden.

Discussion

A useful compromise is a rolling batch with a size cap and a time cap. The coordinator processes up to a set number of items or until a set time, whichever comes first, then records the state and moves to the next priority. The cap prevents an endless block, and the time limit protects the oldest item. Review the caps after two weeks with real arrival data.

Batch size also affects the reviewer. A large batch produces a large review at the end, which is exactly when attention is lowest. Smaller batches spread the review across the day and make it easier to catch a drift before it repeats. The reviewer's capacity is part of the design, not an afterthought.

Write the batch rule where requesters can see it. A note that says requests received after three will be handled in the next block sets an expectation and reduces repeated follow-ups. The note should also name the urgent path, so a genuine exception does not feel like a rule violation. Review the note after a month to see whether requesters still follow it.

Do not copy another team's batch size without checking the task. A finance team processing invoices may tolerate a daily batch, while a support team answering live customers may not. The right size follows the arrival pattern, the switching cost, and the promise made to the customer. Test the size against your own arrival pattern before making it a rule.

Review the batch after a volume change. A size that worked at twenty items a day may fail at sixty, and a block that worked in a quiet month may collapse during a launch. Recheck the caps when the volume or the task mix moves, not only on a calendar schedule. Keep the old caps in the record so the comparison is visible.

Implications and limits

A batch also needs a visible end state. At the close of the block, the coordinator should record what was completed, what was reviewed, and what remains open. That short note lets the next person start without reconstructing the list. A batch that ends in silence is only a pause in an invisible backlog.

The review should include the handoff between shifts. A batch that ends at the shift boundary can leave a list of half-finished items for the next coordinator, who then spends the first hour reconstructing context. End the block earlier, or record the open items in a form the next person can use without a conversation. A short end-of-block note is usually enough to preserve the context.

Batching is not the enemy of good operations. Unstated batching is. Once the size, the timing, and the review are visible, the team can decide whether the trade-off is acceptable. That decision belongs to the manager who owns the service level, not to the coordinator who is trying to finish a list.

A simple batching test

Take ten recent items and record when each arrived, when work started, and when it was completed. Group them by the block in which they were handled. If the wait time is concentrated in a few blocks, the batch is shaping the service more than the volume is. That is the first fact to bring to the review.

Ask the coordinator what happens when an item cannot be finished inside the block. If the answer is that it waits for the next block, the design has a built-in delay. If the answer is that it moves to a holding state with a named owner, the design has a recovery path. The difference matters more than the batch size.

Setting a batch that fits the work

Choose a size cap and a time cap together. The size cap keeps the block predictable, while the time cap protects the oldest item. Test both for two weeks and adjust one at a time. A change to both makes it impossible to tell which one helped.

Protect the review step. A batch that is completed but not checked is not finished work. Build a short sample review into the end of the block, and record the result. If the review is always skipped under pressure, the batch is too large for the available time.

When batching should stop

Stop batching a task when the wait becomes the dominant customer complaint or when the work depends on a fast response. Move that task to a flow model with a small queue and a visible due time. Keep batching for independent, low-urgency work where the efficiency is real. Explain the change to requesters so the new due time is not treated as a delay.

Also stop when the batch hides errors. If a mistake discovered at the end of a block requires rework across every item, the batch is too large or the review is too late. Shrink the batch or add a checkpoint. A process that only works when nothing goes wrong is not a process.

Limits of the method

The method describes waiting and completion in one queue. It does not prove that batching is the only cause of delay, because staffing, system speed, and request complexity also matter. Use the timestamps to locate the delay before changing the schedule. Report the other causes beside the batch finding so the reader sees the full picture.

A small sample can miss rare cases. If the queue has a few high-value items, review them separately rather than relying on the batch average. The goal is a decision that fits the work mix, not a universal rule for every task. Name the high-value items you reviewed separately so the coverage is visible.

Questions