Coverage is a schedule

Headcount is the wrong unit

A week has 168 hours. One full-time person covers about forty of them, before breaks, training, meetings, illness and leave. Covering every hour of the week with one person on the queue takes several people, and covering it with two takes twice that. The roster grows in whole people; the demand it serves does not arrive in whole people.

Demand arrives by the hour, unevenly. It rises after a launch email, falls overnight, shifts with the customer's time zone, and spikes when a carrier is late across a region. A roster sized to the average hour is understaffed at the peak and idle at the trough, and the customer only ever meets the peak.

So the question an operator actually answers is not "how many people". It is "how many people, in which hours, against which arrival rate, for which kind of work" — four variables, of which headcount is the least informative.

The queue does not average

Queueing theory has a standard model for this. For a staffed queue it is Erlang C, which gives the probability that an arriving request has to wait instead of being picked up at once, and it is used to determine how many agents a contact center needs. Its inputs are the offered load — the arrival rate multiplied by the average handling time, measured in erlangs — and the number of people serving it.

The model assumes random arrivals, exponential handling times and a customer who never abandons the queue. Real customers do leave, which makes the formula conservative: it predicts more people than are strictly needed. Its shape, however, is the point, and the shape does not depend on the details.

Take an illustrative load of 8 erlangs — enough work to keep exactly eight people busy all the time — and compute the wait as the number of people changes. Waits are expressed in multiples of the average handling time, so the result holds for any channel.

The table is the whole argument in four rows. The relationship between people and waiting is not proportional. Near full occupancy, one person is the difference between a queue that clears and one that compounds. Removing one person of ten does not lengthen the wait by a tenth; it triples it. Removing two makes the queue unstable, growing for as long as the load lasts.

This is why a team that looks adequately staffed on a weekly average produces long waits on specific afternoons. The average hides the hours where occupancy approaches one, and those are the only hours in which the nonlinearity bites.

Pooled capacity beats split capacity

The same formula carries a second lesson. Hold occupancy fixed at 80% and change only the size of the pool. Five people on 4 erlangs, ten on 8, twenty on 16 — every person equally busy.

Larger pools absorb randomness better, because the chance that every person is busy at once falls as the pool grows. Splitting the same people into small queues — by channel, by shift, by product line — rebuilds the small-pool wait inside an operation that could have had the large-pool one.

For an in-house team, splitting is often unavoidable: two people cover email, one covers chat, and each queue is too small to absorb a burst. The design response is not to hire into each small queue. It is to change what the queue contains, and to define exactly when it is staffed.

Take the informational load out of the human queue

The offered load in the formula is the work arriving at the people. Every request that does not need a person, but reaches one anyway, raises occupancy for every request that does.

In Razviel's design, the boundary between the AI and a person is the nature of the case. Informational requests — where an order is, whether an item is in stock, what the warranty covers — are answered by the AI at any hour, by design, and are never routed to a person on the strength of a confidence score. Money cases the brand's policy delegates are resolved within its limits, each action checked by the deterministic Policy Gate. What reaches a person is the case that needs judgment.

That changes the human queue in two ways at once. The arrival rate falls, because the high-volume, low-judgment requests never enter it. And the content changes: the cases that do arrive are prepared, with the context already collected, so the handling time a person spends is spent on the decision rather than on looking things up.

The AI side runs continuously. Each brand has six AI agents, one per shift, three shifts across weekdays and three across weekends, aligned to the brand's time zone. The informational load that would otherwise pile into a Monday morning queue is answered as it arrives.

A defined window beats an open promise

With the informational load handled continuously, human coverage can be designed as what it is: a window. In the design, human coverage follows one model, the same for every brand. Monday to Friday, in two modules on Eastern Time: Atlas from 9:00 to 12:00, and Apollo from 13:00 to 17:00. That is 35 of the week's 168 hours, defined in advance and published.

The value of a defined window is that the system can tell the truth about it. When a case needs a person outside those hours, the AI does not promise a transfer that cannot happen. Overnight, it saves the case and tells the customer when a person will be available; on email, the case is picked up in the next window. During the midday gap, where the wait is about an hour, the customer can stay in the chat or come back with the case already saved. A known wait, stated plainly, is a different experience from an unknown one.

The window is staffed by Human Nodes, independent service providers under contract with Razviel, certified on the brand. Modules are confirmed in advance, which is what makes the schedule a schedule rather than a hope. When a module is missed or a connection drops, the design covers it in order: the tickets go to another Human Node active on the brand, the module is offered to others certified on it, and if no one takes it the cases go to the brand's own helpdesk. The design does not promise that a specific person is present at every moment. It specifies what happens when one is not.

The trade is deliberate. An unbounded promise of human availability is either expensive — staffing every hour to the peak — or false. A bounded one, with the AI answering what it should at any hour and the human window doing the judgment work it is sized for, can be both affordable and true.

The takeaway

Coverage is decided by who is available in each hour against what is arriving in it, and the queue punishes thin hours far out of proportion to their share of the week. Adding people is the most expensive way to change that arithmetic. Lowering the load that reaches people, pooling the capacity that remains, and defining the window it serves change it at the source.

What to check, in your own operation or in any vendor's:

1. Plot coverage by hour, not by head. Lay the schedule over the hourly arrival curve for a typical week. The hours where occupancy approaches one are where the waits come from.
2. Count what reaches people. Classify a week of human-handled tickets by nature. Every informational request in that sample is load a person did not need to carry.
3. Find the split queues. List every separate queue and its staffing at the peak hour. Small queues with one or two people waste capacity a pooled queue would have absorbed.
4. Read the after-hours message. Write in when no one is scheduled. The reply should state when a person will be available and keep the case. A promise of a callback that no schedule backs is a failure deferred.
5. Ask what happens when someone is missing. The answer should be a written sequence — who covers, then who, then where the case goes — not an assurance that it does not happen.

Headcount is what an operation pays for. The schedule is what its customers receive.