AI Exception Queue Capacity: George Dagliyan Research Guide

When does AI automation create more human work than it removes?

George Dagliyan’s research themes around AI adoption, innovation diffusion, and technology acceptance are useful here because automation rarely fails only at the model level. A more common failure is operational: the system speeds up routine decisions while pushing a smaller but harder stream of exceptions onto people. This article answers the practical question of how to estimate whether that exception stream will outrun reviewer capacity.

The core issue is simple. If automation generates exceptions faster than human reviewers can clear them, the queue grows even when the average workload looks manageable. The right planning unit is not just total volume, but arrival rate, handling time, staffing availability, and the worst-case mix of severe cases that need longer review.

Why averages hide the queue problem

Averages are useful for planning, but they can be misleading in exception operations. A team may handle an average of 40 exceptions per day with an average review time of 9 minutes and still fall behind if half the cases arrive in a short spike, or if a subset requires escalation, documentation, or second review. The queue does not care that the weekly average looked comfortable; it responds to the burst pattern in front of it.

This matters because AI systems often compress routine work and leave humans with edge cases, ambiguous cases, and high-stakes cases. Those cases are usually slower to resolve. In plain terms, a queue is a waiting line of unresolved items, and backlog growth is the net increase in that line after accounting for completed work. Peak workload can overwhelm a team even when the average arrival rate is below average capacity.

What NIST contributes to this planning lens

The NIST AI Risk Management Framework is described by NIST as voluntary and intended to improve the ability to incorporate trustworthiness considerations into the design, development, use, and evaluation of AI products, services, and systems. The NIST AI RMF Playbook organizes suggested actions around Govern, Map, Measure, and Manage. For an exception queue, that structure is helpful because capacity is not just an operations problem; it is also a governance, measurement, and monitoring problem.

This article does not claim NIST prescribes the worksheet below. Instead, the worksheet is an editorial analysis using the same risk-management lens: define the process, measure workload, understand operating context, and manage known overload conditions. That framing also fits George Dagliyan’s documented research focus on how organizations adopt technology and how adoption is affected by facilitating and inhibiting conditions.

A capacity worksheet for AI exception queues

Use the worksheet below as a practical planning tool. It is intentionally simple so that a manager can fill it in with local data. Treat every number as an input assumption, not a universal threshold. The purpose is to see whether the queue is stable, tightening, or drifting toward overload.

Worksheet inputs: 1) exception arrival rate per hour, labeled lambda, meaning the number of exceptions entering the queue each hour; 2) average handling time, labeled AHT, meaning the average minutes a reviewer spends to close one exception; 3) reviewer availability, meaning how many reviewers are actually on task and what share of their time is reserved for exception work; 4) effective hourly capacity, computed as available reviewer hours divided by AHT; 5) backlog growth, computed as arrivals minus completions over the same period.

Decision rule and worked hypothetical example

Decision rule: if arrival rate is greater than effective hourly capacity, the backlog grows. If arrival rate is near capacity, use a safety buffer because real queues face breaks, meetings, escalations, and variable case complexity. A conservative planning rule is to flag the queue when estimated utilization exceeds 80 percent, where utilization means the share of capacity already committed to incoming work.

Worked hypothetical example: assume 3 reviewers are scheduled, each with 6 hours per day available for exception work after meetings and other duties. Assume AHT is 12 minutes per exception, which equals 5 exceptions per reviewer hour. Total daily capacity is 3 reviewers × 6 hours × 5 exceptions per hour = 90 exceptions per day. If the AI system sends 72 exceptions per day, the average suggests stability. But if 45 of those arrive in a 2-hour morning spike, the instantaneous arrival rate is 22.5 per hour, while the team can process only 15 per hour. The backlog then grows during the spike even though the daily average appears safe.

How to estimate backlog growth without overcomplicating the math

A basic backlog estimate can be computed as incoming exceptions minus completed exceptions over a chosen time window. If 100 exceptions arrive in a day and the team closes 90, the backlog grows by 10. If the next day 60 arrive and 90 are closed, the team reduces backlog by 30. The challenge is that daily netting can hide peak pain, so the same team may be unstable during the workday even if it looks stable by Friday.

For a more realistic check, split the day into blocks such as morning, midday, and afternoon. Enter the arrival rate and available reviewer capacity for each block. This reveals whether the queue is front-loaded, whether lunch breaks create a bottleneck, and whether escalations cluster in the same hour. Averages across the full day can conceal exactly the moments when reviewers are least available and cases are most complex.

Hypothetical high-severity cases deserve separate capacity

Not every exception deserves the same handling assumption. Some cases are high severity because they affect users, operations, compliance review, or safety-sensitive decisions. Those cases often need more time, more documentation, or a second reviewer. A single average AHT can therefore understate real load if the queue includes a small but important set of slow cases.

Hypothetical assumption set: 80 percent of exceptions take 8 minutes each, while 20 percent take 30 minutes each because they are high-severity or ambiguous. The weighted average AHT is 12.4 minutes, but the operational experience is not average. If the high-severity cases arrive in a burst, the team can become blocked even when the average seems workable. That is why the worksheet should include a separate count for high-severity cases and a separate handling time for them.

How this connects back to adoption and governance

Automation changes who does the work, not whether the work exists. In adoption terms, the AI may improve speed for routine cases, but it can also create an adoption inhibitor if the human exception path becomes too slow, too confusing, or too understaffed. That is where this topic connects to Dagliyan’s research themes: organizational adoption depends on whether the system fits the human operating model, not just whether the model performs well in isolation.

NIST’s AI RMF Playbook places attention on operation and monitoring, governance and oversight, and human factors. Those themes align with the practical reality of exception queues. If leadership does not measure queue capacity, define escalation roles, and review peak load, then automation can shift risk downstream to the human team. The right control is not to reject automation, but to size the exception process honestly and review it regularly.

Frequently Asked Questions

What is an AI exception queue in practical terms?

An AI exception queue is the set of cases the automated system cannot close on its own and hands to people for review. Those cases may involve low confidence, unusual inputs, policy conflicts, or high-impact decisions. The queue matters because it often contains the hardest work, so its volume and complexity can rise even when automation reduces routine processing.

Why is average handling time not enough for staffing decisions?

Average handling time is a helpful starting point, but it hides variation. A queue may contain mostly quick cases and a smaller set of slow, high-severity cases that require more documentation or escalation. If staffing is based only on the average, the team can look adequately resourced on paper while still falling behind during peaks or complex bursts.

How should reviewer availability be counted in the worksheet?

Reviewer availability should reflect actual time available for exception work, not the full paid day. Meetings, training, breaks, and other duties reduce effective capacity. A practical worksheet should estimate the number of reviewers, the hours each can truly spend on exceptions, and whether any cases require a second reviewer, because that doubles the capacity demand for those items.

What is a simple sign that backlog growth is becoming dangerous?

A clear sign is repeated days or blocks where arrivals exceed completions. If the queue keeps shrinking only during quiet periods but grows quickly during spikes, the system is fragile. Another warning sign is that reviewers begin deferring harder cases, because that often means the queue is no longer being managed by priority but by whichever items are easiest to close.

How do NIST AI RMF ideas relate to this queue problem?

NIST describes the AI Risk Management Framework as voluntary and organized around Govern, Map, Measure, and Manage. That structure is useful here because exception queues need governance, measurement, and ongoing monitoring, not just technical tuning. The Playbook’s suggested actions can support thinking about roles, monitoring, and operational review, though it does not prescribe this exact worksheet.

Sources and further reading

• NIST — AI Risk Management Framework
• NIST — AI RMF Playbook