The invoice is ready. Who can clear the review queue?

“Anything uncertain goes to a person.”

That can be a sensible boundary for an AI workflow. It still leaves an operating question unanswered: which person, with how much time, and what happens while the case waits?

Imagine an accounts-payable team preparing its next payment run. An assistant matches invoices to purchase orders and receipt records. One invoice matches the agreed price, but the receipt has not been recorded. It goes to a review queue.

The requester who can confirm delivery is away. Accounts payable can see the invoice and the order, but cannot confirm that the goods arrived. The person covering the queue can forward the notification; they have not been given a route to someone who can record the receipt.

The cut-off for the payment run approaches. The invoice remains blocked, alongside unrelated price discrepancies. Processing more incoming invoices does not resolve this one: someone needs to establish whether the delivery took place and record the answer before the payment decision.

Start at the desk, not the dashboard

Before estimating the capacity of a review queue, watch someone resolve representative exceptions.

An invoice with a missing purchase-order number might take a short lookup. An invoice for work outside the agreed scope may require a contract, a conversation with the requester and a commercial decision. Counting both as one review conceals the difference.

Ask the reviewer what they need to open, whom they need to contact and which decisions they can make themselves. Separate time actively spent on the case from time waiting for an answer. Both affect the service, but they call for different changes.

Do this with ordinary cases as well as the memorable difficult ones. A capacity estimate built entirely from the easiest demonstration will be optimistic. One built entirely from rare disasters will be unhelpful in another way.

Put incoming work beside available capacity

A rough calculation is useful if its assumptions remain visible.

For illustration, suppose a queue receives 30 cases in a day and a particular class of case takes an average of eight minutes of active handling. That class would require four hours of handling time if all 30 cases belonged to it. This is a planning assumption to check against the actual mix of cases, not a staffing ratio.

Now ask where those four hours exist. A named reviewer who already has a full workload does not contribute four spare hours because a project plan lists them as the owner.

Real queues are less tidy. Arrivals bunch together, case types vary and missing information can force several visits to the same file. Use the calculation to expose the assumption, then measure a limited real workflow before making staffing promises.

The relevant question is not simply how many cases the assistant completes automatically. It is whether the remaining work can be handled within the deadlines the business has agreed.

The oldest case deserves a visible reason

A queue can look healthy by average waiting time while one important case sits untouched.

Show the age of unresolved cases and the reason they are waiting. “With finance” is often too broad. Waiting for a supplier document, waiting for an authorised decision and waiting because no reviewer is available are different states.

Give each state a next action and an owner. Where a deadline exists, make it visible to the person managing the queue. An internal service target should reflect the consequence of delay, not a convenient colour threshold chosen by the dashboard designer.

This does not mean the oldest case always goes first. A payment due today and a low-impact record correction may deserve different treatment. Define the priority rules with the people who carry the consequences. Otherwise the queue's default sorting order becomes an accidental business policy.

Cover the absence before it happens

Who handles the case when the usual reviewer is away?

For the missing receipt, identify who can check the delivery record and enter or confirm receipt in the requester’s absence. For a price difference, the buyer may need to resolve the purchase-order terms instead. An accounts-payable colleague with access to the queue cannot automatically replace either role. Record the cover for each decision, including what remains blocked when no authorised substitute is available.

For decisions that cannot be delegated, define a safe waiting state. Perhaps the instruction remains unsent. Perhaps the supplier receives an accurate acknowledgement that the invoice is under review. Do not let an assistant invent a payment date simply to keep the conversation moving.

Check holidays and overlapping duties before launch. A rota is not evidence of coverage if everyone on it attends the same meeting or depends on the same unavailable approver.

Decide what overload changes

When arrivals exceed handling capacity, the workflow needs a response other than “send more notifications”.

Possible responses include slowing intake for the affected action, routing a defined class to a trained backup or temporarily returning a portion of the work to the previous process. Which response is appropriate depends on the service and the consequence of waiting.

Preserve the safety boundary. A busy queue does not justify silently lowering the threshold for an irreversible action. If the team wants a different delegation rule, it needs an explicit business decision and a tested implementation.

Also inspect the source of the load. A poorly extracted field may send hundreds of easy cases to review. A genuine change in customer behaviour may create difficult cases that the original design never considered. The first problem calls for a technical correction; the second may require a different operating rule.

Run a small absence exercise

In a safe test, remove the usual reviewer from the simulated workflow. Introduce cases with different deadlines and one missing document.

Can the backup identify what to do? Does the waiting case remain visible? Can the queue owner tell a capacity problem from a missing-information problem? Does the customer or supplier receive a truthful status?

Then restore normal staffing and inspect recovery. A queue that survives the afternoon but loses decisions during handover has not passed the useful part of the exercise.

The broader distinction between usage and completed work is covered in Why AI use and operational results need separate evidence. Here, the practical starting point is one queue, its actual workload and the people available to handle it.

If your proposed workflow includes a box labelled “human review”, bring that queue to a Strategy Session. We can begin with what arrives there and who is expected to make it move.