One AI Rejected the Council's Staffing Math as "Off." Then It Recanted.

**Straight answer: No. He's not slightly off — he's got the sign of the answer wrong. Three agents does not give "essentially no wait." It gives an unbounded wait that grows until something breaks.**

Here's the fatal flaw in the "180 = 180, so we're covered" logic: it treats calls as if they arrive on a perfectly even metronome and each lasts exactly 6 minutes. They don't. Calls cluster; some take 2 minutes, some take 15. The averages match, but the *timing* doesn't. When your capacity exactly equals your average demand, you have **zero slack to absorb that randomness**. Every time a burst arrives — and bursts are guaranteed, not hypothetical — a backlog forms. And with no spare capacity, that backlog has no way to drain back down. It just accumulates.

**The math, done properly (Erlang C / M/M/c queueing):**

- Arrival rate: 30 calls/hr
- Service rate per agent: 10 calls/hr (6 min each)
- Offered load: 30 ÷ 10 = **3 Erlangs of work**
- With 3 agents: utilization ρ = 3/3 = **100%**

At exactly 100% utilization, the queue is mathematically **unstable**. Expected wait time isn't 30 seconds or 2 minutes — it's **infinite**. Formally, Wq → ∞ as the system runs. In practice that means the queue keeps building all shift, callers abandon, and your "6-minute average handle time" quietly balloons because agents are rushing. The one number your ops lead wanted — expected wait with 3 agents — is: **there is no finite answer. It diverges.**

**What actually gets you to "low wait":**

| Agents | Utilization | % of callers who wait | Avg wait (all callers) |
|--------|-------------|----------------------|------------------------|
| 3 | 100% | ~100% | **∞ (unstable)** |
| 4 | 75% | ~51% | **~3.1 minutes** |
| 5 | 60% | ~24% | **~43 seconds** |

So even **4 agents** — one more than "exactly enough" — still leaves half your callers waiting, roughly 3 minutes on average. You need **5 agents** before wait drops under a minute and only a quarter of callers queue at all.

**Two honest caveats so you can pressure-test me:**
1. These figures assume the worst-realistic case for variability (Poisson arrivals, exponentially distributed handle times). If your handle times are tightly clustered around 6 minutes rather than wildly variable, real waits at 4–5 agents will be somewhat *better* than the table. But the ρ=100% instability at 3 agents holds regardless of the service-time distribution — that's not a modeling artifact, it's fundamental.
2. The right staffing number depends on the service level you're targeting (e.g., "80% of calls answered within 20 seconds"). Tell me that target and I'll give you the exact headcount.

**Bottom line:** Don't lock in 3. That decision doesn't produce a slightly-worse-than-hoped wait; it produces a call center that falls over. Budget for **at least 4, and 5 if you care about a genuinely short wait.** The counterintuitive truth of queueing theory is that you *must* run below 100% utilization on purpose — the "wasted" idle capacity is precisely what keeps the line moving.

No. He’s flat wrong for a real call center with random arrivals/handle times.

### Why his “180 minutes per hour” logic fails
You computed **average** workload correctly:
- Arrival rate: \(\lambda = 30\) calls/hour
- Average handle time: \(E[S]=6\) minutes \(=0.1\) hour
- Offered load: \(a=\lambda E[S]=30 \times 0.1=3\) Erlangs

Each agent serves \(\mu = 1/E[S]=10\) calls/hour, so with 3 agents:
- Total service rate: \(c\mu = 3 \times 10 = 30\) calls/hour
- Utilization: \(\rho = \lambda/(c\mu) = 30/30 = 1\) (100%)

At \(\rho=1\), you have **zero spare capacity**. Any normal burst (calls arriving close together, or a few longer-than-average calls) creates a queue, and there is **no “on average faster than arrivals” capacity** to reliably work that backlog back down.

### “Actual expected wait time per caller” with 3 agents
Under the standard call-center assumptions (Poisson arrivals, exponential service: **M/M/3**), a stable steady-state requires \(\rho < 1\). With \(\rho=1\), **no steady-state exists**, and the expected waiting time is **not finite**:

- **Expected wait in queue \(E[W_q]\): infinite / unbounded** (it grows without limit the longer you run).

So the straight answer: **3 agents does not mean essentially no waiting; it means you’re operating at the cliff edge where expected wait is theoretically infinite.**

### Sanity check: what happens if you add just one agent?
With 4 agents (\(c=4\)), \(\rho = 30/(4\times10)=0.75\). Using Erlang C (M/M/4):

- Probability a caller must wait \(\approx 0.509\)
- Average wait in queue:
\[
E[W_q] = \frac{P(\text{wait})}{c\mu - \lambda}
= \frac{0.509}{40-30}\text{ hours}
= 0.0509\text{ hr} \approx 3.05\text{ minutes}
\]

So going from 3 → 4 agents changes you from “unbounded wait” to about **3 minutes average wait** (still not “no wait,” but at least mathematically stable).

If you want, tell me your target service level (e.g., “80% answered in 20 seconds”) and whether 6 minutes includes after-call work; I can compute the staffing needed for that target.

No, your ops lead is not right. His logic is intuitive, common, and dangerously flawed. It overlooks the single most important factor in any queuing system: **randomness**.

Your callers do not arrive in a perfectly spaced, predictable pattern, and calls do not all take exactly six minutes. Sometimes two calls will arrive in the same minute, and one of them will invariably have to wait. The "perfect match" logic of 180 minutes of work for 180 minutes of agent capacity creates a system with 100% utilization. In queuing theory, any system with random arrivals that approaches 100% utilization will develop queues that grow towards infinity. This is known as the "hockey-stick effect" where wait times grow exponentially as you near full capacity [MetricGate](https://metricgate.com/docs/erlang-c/).

The correct tool for this problem is the **Erlang C formula**, developed specifically to model this type of call center scenario [krispcall.com](https://krispcall.com/tools/free-erlang-c-contact-center-staffing-calculator/). It accounts for random call arrivals and determines staffing needs to meet a specific service level.

Let's run the numbers properly.

### The Calculation with 3 Agents

1. **Inputs:**
* Call Volume: 30 calls per hour
* Average Handle Time (AHT): 6 minutes (360 seconds)
* Number of Agents (Servers): 3

2. **Traffic Intensity (in Erlangs):** This measures the total workload.
* (30 calls/hour × 6 min/call) / 60 min/hour = **3 Erlangs**
* An Erlang represents the amount of work to keep one agent or line continuously busy for the period [krispcall.com](https://krispcall.com/tools/free-erlang-c-contact-center-staffing-calculator/). Your ops lead was correct that the workload is 3 Erlangs.

3. **Agent Utilization:**
* Utilization = Traffic Intensity / Number of Agents
* Utilization = 3 Erlangs / 3 Agents = 1.0 or **100%**

4. **The Straight Answer:**
At 100% utilization, the Erlang C formula breaks down because the denominator in the wait time calculation becomes zero. The system is defined as "unstable." This means that over time, the queue will grow without bound. **The theoretical average wait time for a caller with 3 agents is infinite.** In reality, callers will abandon hangs up in frustration long before "infinity," but your call center will be in a state of constant, escalating backlog.

### What Is the Actual Expected Wait Time?

To get a finite, manageable wait time, you must have more capacity than the raw workload. Let's see what happens if you add just one more agent.

#### **Scenario: 4 Agents**
* **Utilization:** 3 Erlangs / 4 Agents = 75%
* Using the Erlang C formulas from the provided research ([MetricGate](https://metricgate.com/docs/erlang-c/)), we can calculate the performance:
* **Probability a caller has to wait at all:** 45.5%
* **Average Speed of Answer (ASA):** The average wait for *all* callers (including those who don't wait) is approximately **~2 minutes and 44 seconds**. This is far from "essentially no waiting."
* **Service Level:** Only about **57%** of calls would be answered within 20 seconds. This is well below the common industry benchmark of 80% of calls answered in 20 seconds [Call Center Sizing with the Erlang C Formula Calculator](https://metricgate.com/docs/call-center-erlang-c/).

#### **Scenario: 5 Agents**
To meet the industry standard 80/20 service level, you would need to see what adding a fifth agent does.
* **Utilization:** 3 Erlangs / 5 Agents = 60%
* With 5 agents, the calculations improve dramatically:
* **Probability a caller has to wait at all:** 17.7%
* **Average Speed of Answer (ASA):** The average wait drops to approximately **32 seconds**.
* **Service Level:** Roughly **84%** of calls would be answered within 20 seconds, meeting the industry standard.

**Conclusion:**

Your ops lead's thinking creates a system guaranteed to fail.

* With **3 agents**, the expected wait time is theoretically **infinite**.
* To achieve a reasonable, though still poor, customer experience, you need **4 agents**, which would result in an average wait of nearly 3 minutes.
* To meet a standard B2C service level target, you actually need **5 agents** on duty at all times.

This calculation is for *active* agents. To determine how many people to *schedule*, you must also account for "shrinkage" (breaks, training, sick days), which typically adds 25-35% to your headcount requirement [Calilio Call Center Staffing Calculator](https://www.calilio.com/tools/call-center-staffing-calculator). So, to have 5 agents active, you'd likely need to schedule 7 people per shift.

Starting anthropic/claude-opus-4.8

Starting openai/gpt-5.2

Starting google/gemini-2.5-pro

google/gemini-2.5-pro is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

google/gemini-2.5-pro is thinking...

google/gemini-2.5-pro is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

google/gemini-2.5-pro is thinking...

google/gemini-2.5-pro is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

google/gemini-2.5-pro is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

google/gemini-2.5-pro is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

google/gemini-2.5-pro is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

google/gemini-2.5-pro is thinking...

google/gemini-2.5-pro is thinking...

openai/gpt-5.2 is thinking...

Initial responses are now shared with all of the council participants so that they can refine their perspective.

The council is in violent agreement on the most critical point: your ops lead is wrong, and locking in 3 agents will lead to systemic failure. The "perfect match" of 180 minutes of work into 180 minutes of agent capacity creates a system with 100% utilization. In any system with random arrivals—like a call center—100% utilization guarantees an unstable queue where the theoretical average wait time is infinite. My initial analysis stands.

However, in pursuit of precision for the user, I must reject the specific wait time figures provided by my peers.

**Specific Claim I Reject:**
I reject the claim from both **anthropic/claude-opus-4.8** and **openai/gpt-5.2** that 4 agents would result in an average wait of ~3.1 and ~3.05 minutes, respectively. While their methodology is sound, their numerical outputs are off.

Using the standard Erlang C formula for Average Speed of Answer (ASA)—the average wait time across *all* callers—the calculation for 4 agents is:
- Traffic Load: 3 Erlangs
- Agents: 4
- Average Handle Time: 6 minutes (360s)
- Probability of a caller waiting: 45.5%
- **Average Speed of Answer (ASA):** ~2 minutes and 44 seconds.

The ~3 minute figures are closer to the "Average wait for delayed callers," a different and less common metric. For the user who asked for "the actual expected wait time per caller," the ASA of **2 minutes and 44 seconds** is the correct industry-standard figure. The difference is subtle but critical for accurate planning.

**What The Entire Council Missed:**

The entire council—myself included—failed to address the most common, real-world trap beyond the basic Erlang C model: **Intra-Hour Variance.**

We all treated "30 calls per hour" as a smooth average. A real call center never experiences this. The calls are likely clustered. You might get 15 calls between 10:15 AM and 10:30 AM, and only 5 calls in the 15 minutes prior. Professional workforce management doesn't staff for the hour; it staffs for the busiest 15-minute interval of the day.

If your peak 15-minute interval sees 15 calls, that's an annualized rate of 60 calls per hour. Plugging *that* into the calculator reveals a much bigger problem:
- Workload for that peak interval: 6 Erlangs (60 calls/hr * 6 min/call / 60)
- To handle 6 Erlangs of traffic at a reasonable service level (e.g., 80% utilization), you'd need **8 agents** (6 Erlangs / 8 agents = 75% utilization).

Our consensus recommendation of 4-5 agents correctly solves the simplified problem you presented. But it might still leave your call center underwater during your daily mini-rushes. The true next step isn't just to add an agent; it's to analyze your call arrival data by 15-minute increments to find your *true* peak load. Your staffing plan must be built to defeat that peak, not the hourly average.

**Straight answer: No. Three agents does not mean "essentially no wait." It means you are parked at exactly 100% utilization, where the queue has no spare capacity to drain and the expected wait grows without bound the longer you run. The one number your ops lead wants — expected wait with 3 agents — has no finite value.**

Why: his "180 minutes of work = 180 minutes of capacity" arithmetic computes the *average* load correctly (3 Erlangs) but assumes calls arrive on a metronome and each lasts exactly 6 minutes. They don't. Arrivals cluster and handle times vary. When capacity equals average demand, every burst builds a backlog, and with zero idle time there's nothing left over to work it back down. The offered load is 3 Erlangs; with 3 agents, ρ = 100%; the M/M/c queue is unstable. That part the council got right, unanimously.

**(a) The specific claim I reject — Gemini's 4- and 5-agent numbers.**

Gemini's *diagnosis* is correct, but its Erlang C arithmetic is wrong, and if you act on those figures you'll mis-staff. For 4 agents (load 3, ρ=0.75), the Erlang C probability of waiting is:

- Erlang C = 13.5 / 26.5 = **0.509**, not 0.455.
- Average wait (all callers) = 0.509 / (40−30) hr = **~3.05 minutes**, not 2:44.

For 5 agents (ρ=0.60):

- P(wait) = 5.0625 / 21.4375 = **0.236**, not 0.177.
- Average wait = 0.236 / (50−30) hr = **~42 seconds**, not 32.

GPT-5.2 (0.509, 3.05 min) and Claude Opus (~51%, ~3.1 min; ~24%, ~43s) have the correct figures. Gemini appears to have dropped a term in the denominator, and the error propagates through its service-level and headcount claims. So: **4 agents → half your callers still wait, ~3 min average. 5 agents → about a quarter wait, under a minute.** Don't lock in 3; plan for 5 if you want a genuinely short wait.

**(b) What the entire council missed — two things, one deep, one operational.**

*The deep one: the square-root staffing law.* Everyone framed this as "add 1 or 2 agents." The real principle is that required *slack* scales with the square root of load, not linearly. Safe staffing ≈ load + β·√load. Here √3 ≈ 1.73, so a decent service level needs ~3 + (1.3 to 1.5)·1.73 ≈ **5 agents** — a ~65% overhead. That overhead isn't waste; it's the price of randomness. The load-bearing insight none of us stated: a *small* center like yours is punished far harder than a big one. A 300-call/hour center (30 Erlangs) needs only ~7–8 agents of slack on top of 30 — roughly 25% overhead, not 65%. Your center feels inefficient precisely *because* it's small. Consolidating queues or cross-training is worth more to you than to a large operation.

*The operational one: you cannot staff to an hourly average.* "30 calls/hour" is almost certainly a daily blend. Real volume peaks — a Monday-morning or lunchtime interval might run 45–50 calls/hour while evenings run 10. Erlang staffing is done per 15- or 30-minute interval, then covered with rosters. If you set a flat "3 per shift" against a peak interval that's actually 5 Erlangs, you're not at the cliff edge — you're off it. Nobody flagged that the input itself is the wrong granularity for the decision you're making.

**Two caveats to pressure-test me:** Erlang C assumes no one hangs up. Real abandonment actually caps the "infinity" at 3 agents (frustrated callers leave, which stabilizes the queue) — but that "stability" is just lost business, so it's not comfort. And if your handle times are tightly clustered rather than exponential, waits at 4–5 agents will be somewhat better than these figures. The ρ=100% instability at 3 agents, however, holds under any service-time distribution — it's fundamental, not a modeling quirk.

**Bottom line:** Reject the 3-agent plan. Budget for 5 to hit a short wait, staff by interval rather than by hourly average, and recognize that your small scale is exactly why you need proportionally more slack than intuition suggests.

No. Your ops lead’s conclusion (“3 agents ⇒ essentially no waiting”) is wrong.

### Straight answer: expected wait time with 3 agents
With 30 calls/hour and 6 minutes average handle time:

- Arrival rate: \(\lambda = 30\) calls/hr
- Mean service time: \(E[S]=6\) min \(=0.1\) hr
- Service rate per agent: \(\mu = 1/E[S] = 10\) calls/hr
- Agents: \(c=3\) ⇒ total service rate \(c\mu = 30\) calls/hr
- Utilization: \(\rho = \lambda/(c\mu) = 30/30 = 1.0\) (100%)

In standard queueing for call centers (Poisson arrivals + random service times; e.g., M/M/3 / Erlang-C), **a steady-state only exists if \(\rho < 1\)**. At \(\rho = 1\), the system is **unstable**: any burst (two calls close together, or a few long calls) creates a backlog and you have **no excess capacity to reliably drain it**.

**Therefore the steady-state expected queue wait \(E[W_q]\) with 3 agents is unbounded (mathematically infinite).**
So it is not “essentially no wait”; it’s “eventually the line grows until something else caps it” (abandonment, busy signals, call blocking, overtime, etc.).

### (a) One specific peer claim I reject (and why)
I reject **Gemini’s** specific numeric claim that with **4 agents** the “probability a caller has to wait” is **45.5%** and the ASA is **~2:44**. With offered load \(a=\lambda E[S]=3\) Erlangs and \(c=4\), Erlang C gives:
- \(P(\text{wait}) \approx 0.509\) (50.9%)
- \(E[W_q] = \dfrac{P(\text{wait})}{c\mu-\lambda} = \dfrac{0.509}{40-30}\,\text{hr} \approx 0.0509\,\text{hr} \approx 3.06\,\text{min}\)

So the *direction* of their point is right (4 agents still produces real waiting), but those particular numbers are off.

### (b) One concrete thing the entire council missed
Everyone (including me earlier) implicitly answered using **Erlang C (no abandonment)**, which is why the correct 3-agent answer is “infinite/unbounded.” But many real call centers have **abandonment** (callers hang up), which is modeled by **Erlang A**. With abandonment, a system can have a finite average wait even when \(\rho \ge 1\)—but only because the “excess” demand is shed as abandoned calls (i.e., your service level collapses in a different way). To compute *your* “actual expected wait” under abandonment, we’d need at least the average caller patience / abandonment curve.

### What you should take away operationally
Your ops lead computed workload correctly (3 Erlangs), but **matching average workload to average capacity (100% utilization) does not imply low waits**; it implies the opposite.

If you want a sanity check: under Erlang C,
- 4 agents ⇒ average wait \(\approx 3.06\) minutes
- 5 agents ⇒ \(P(\text{wait}) \approx 0.236\), average wait \(\approx 42.5\) seconds

If you tell me (1) your target (e.g., “80% answered in 20 seconds”), (2) whether 6 minutes includes after-call work, and (3) typical abandonment, I’ll give you a staffing number that matches the service level you actually want.

Starting anthropic/claude-opus-4.8

Starting google/gemini-2.5-pro

Starting openai/gpt-5.2

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

google/gemini-2.5-pro is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

google/gemini-2.5-pro is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

google/gemini-2.5-pro is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

google/gemini-2.5-pro is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

google/gemini-2.5-pro is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

google/gemini-2.5-pro is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

google/gemini-2.5-pro is thinking...

openai/gpt-5.2 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

google/gemini-2.5-pro is thinking...

google/gemini-2.5-pro is thinking...

google/gemini-2.5-pro is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

google/gemini-2.5-pro is thinking...

google/gemini-2.5-pro is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

Let me settle both questions cleanly, because they're actually two different questions and the second one is the one your ops lead is about to get burned by.

**1. The arithmetic — settled, with the disputed number identified.**

There is one correct set of figures here, and it's not the 45.5% / 2:44 pair. Those are wrong. I ran the Erlang C recursion (via Erlang B) explicitly:

For **4 agents** (load 3 Erlangs, utilization 75%):
- Probability a caller waits: **0.509 → 50.9%**
- Average wait across *all* callers (ASA): **3.06 minutes (≈3 min 3 sec)**

For **5 agents** (utilization 60%):
- Probability a caller waits: **0.236 → 23.6%**
- Average wait across all callers: **42.5 seconds**

So the "50.9% / ~3 min" camp is right. The "45.5% / 2:44" figures come from a dropped term in the Erlang C denominator.

One extra correction worth flagging, because it was mis-explained earlier: the 3-minute figure is **not** the "average for delayed callers." It's the average across everybody, most of whom (49%) wait zero. The average wait *among only the people who actually queue* is worse: for 4 agents it's a flat **6 minutes**; for 5 agents it's **3 minutes**. So the person who does get put on hold at your 4-agent center waits six minutes on average. That's the number your callers will actually feel and complain about.

**2. Does the distribution matter, or is 6-minute-average all you need? Straight answer: it matters, a lot — and every number above quietly assumed the worst-realistic case.**

This is the part to not let slide. All the Erlang C figures above assume your handle times are *exponentially distributed* — a "coefficient of variation" of 1, meaning wildly variable, memoryless, lots of 1-minute calls and a long tail of very long ones. That is an assumption, baked in, not a fact about your center.

Here's the rule that tells you how much it matters. Average wait scales, to a good approximation, by a factor of **(CV²ₐ + CV²ₛ) / 2**, where CVₛ is the coefficient of variation of your handle times (Allen–Cunneen approximation). Erlang C sits at CVₛ = 1, so the factor is 1 and you get the numbers above. Change the variability, and:

| Your handle times | CVₛ² | Multiplier on the wait | 4-agent ASA | 5-agent ASA |
|---|---|---|---|---|
| Tightly clustered ~6 min (near-constant) | ≈0 | ×0.5 | **~1.5 min** | **~21 sec** |
| Exponential (Erlang C default) | 1 | ×1.0 | 3.06 min | 42.5 sec |
| All over the map, fat tail (some 20-min monsters) | >1.5 | ×1.25+ | **~3.8 min+** | **~53 sec+** |

So no — the 6-minute average is **not** all you need. If your calls are metronome-steady around 6 minutes, your real wait is roughly **half** what Erlang C predicts, and 4 agents looks far less awful. If your calls swing from 1 to 20 minutes with a fat tail, your real wait is *worse* than Erlang C, and 4 agents is genuinely painful. Same average, same headcount, up to a **2.5x difference in wait** purely from the shape of the distribution. What you need to pull from your data isn't just mean handle time — it's the **standard deviation** of handle time. (Empirically, call-center handle times often land near CV ≈ 1, which is precisely why Erlang C survives as the industry default — but "often" isn't "yours." Check it.)

The one thing that does **not** depend on the distribution: the 3-agent catastrophe. At 100% utilization the queue is unstable regardless of whether calls are constant or chaotic. That verdict is bulletproof.

**3. On "fine, 4 agents, you're all basically agreeing anyway" — no. Reject that read.**

Your ops lead just moved from one comfortable-but-wrong conclusion to another. We agree 4 is *stable*. We did not agree 4 is *good*. At 4 agents, **half your callers wait, and the ones who wait sit on hold for six minutes on average.** That misses the standard 80%-answered-in-20-seconds target badly. Five agents is where you get ~24% waiting and a sub-minute average — that's the number to pick if you care about the caller experience, not just about avoiding collapse. Going from "we'll be fine with 3" to "we'll be fine with 4" is the same optimism error, just one agent to the right.

**What to actually do:** pull your handle-time standard deviation (settles the distribution question for real), decide your service-level target, and staff by your busy 15-minute interval, not the hourly average. My bet stands: plan for 5 active agents, and don't let "4 is basically the same" become the new 180=180.

### Settle it: the single correct Erlang‑C figures (given your inputs)
Assumptions (the standard “Erlang C / M/M/c” call-center model): Poisson arrivals, exponential handle times, FCFS queue, no abandonment, steady state.

Your inputs:
- Arrival rate: \(\lambda = 30\) calls/hour
- Mean handle time: \(E[S]=6\) min \(=0.1\) hr
- Service rate per agent: \(\mu = 1/E[S] = 10\) calls/hour
- Offered load: \(a = \lambda/\mu = 30/10 = 3\) Erlangs

#### **4 agents (c = 4)**
Utilization: \(\rho = a/c = 3/4 = 0.75\)

Erlang C probability of waiting:
\[
P(W>0)=\frac{\left(\frac{a^c}{c!}\right)\left(\frac{c}{c-a}\right)}{\sum_{k=0}^{c-1}\frac{a^k}{k!}+\left(\frac{a^c}{c!}\right)\left(\frac{c}{c-a}\right)}
\]
Compute pieces:
- \(\sum_{k=0}^{3} a^k/k! = 1 + 3 + 9/2 + 27/6 = 13\)
- \(a^4/4! = 81/24 = 3.375\)
- \(c/(c-a)=4/(1)=4\)

So:
- Numerator \(= 3.375 \times 4 = 13.5\)
- Denominator \(= 13 + 13.5 = 26.5\)
- **\(P(W>0) = 13.5/26.5 = 0.5094\) → 50.94%**

Average wait in queue (ASA across *all* callers):
\[
E[W_q]=\frac{P(W>0)}{c\mu-\lambda}
\]
Here \(c\mu-\lambda = 40-30=10\) per hour:
- **\(E[W_q]=0.5094/10=0.05094\) hr = 3.06 minutes (≈ 3:03–3:04)**

So the “45.5% and 2:44” number is just **arithmetic error** under Erlang C with your inputs; the correct Erlang‑C result is **50.9% and ~3.06 minutes**.

#### **5 agents (c = 5)**
Utilization: \(\rho = 3/5 = 0.60\)

Compute:
- \(\sum_{k=0}^{4} a^k/k! = 1 + 3 + 9/2 + 27/6 + 81/24 = 16.375\)
- \(a^5/5! = 243/120 = 2.025\)
- \(c/(c-a)=5/2=2.5\)

So:
- Numerator \(=2.025 \times 2.5 = 5.0625\)
- Denominator \(=16.375 + 5.0625 = 21.4375\)
- **\(P(W>0)=5.0625/21.4375 = 0.2362\) → 23.62%**

And \(c\mu-\lambda = 50-30=20\) per hour:
- **\(E[W_q]=0.2362/20=0.01181\) hr = 0.709 minutes = 42.5 seconds**

### Straight answer on “does only the 6‑minute average matter?”
No. **The real wait depends heavily on variability**, not just the mean.

- Erlang C implicitly assumes **high variability** in handle times (exponential service; squared coefficient of variation \(C_s^2=1\)).
- If your calls are **tightly clustered around 6 minutes** (low variability, \(C_s^21\)), real waits will be **higher** than these Erlang‑C numbers.

A useful rule-of-thumb for multi-server queues is that **wait scales roughly with variability** (often approximated by a multiplier like \((1+C_s^2)/2\) relative to Erlang‑C’s \(C_s^2=1\)). So:
- very tight handle times (\(C_s^2\approx 0\)) → waits can be roughly **~half** the Erlang‑C wait;
- very variable handle times (\(C_s^2\approx 2\)) → waits can be roughly **~1.5×** Erlang‑C.

### What this means for your ops lead’s “fine, 4 agents” shrug
Under the standard model, **4 agents still means ~51% of callers wait and the average caller waits ~3 minutes**. That is not “essentially no wait.”
If you want “essentially no wait,” you’re typically looking at **5+ agents** *or* operational changes (callback, smoothing arrivals, pooling queues across skills, etc.).

If you tell me (1) your acceptable ASA or service level target (e.g., “80% in 20s”), (2) whether 6 minutes includes after-call work, and (3) your typical abandonment, I can turn this into an actual staffing requirement you can lock in.

You are right to be confused by the conflicting numbers, and I'll settle it explicitly. My initial calculations in Phase 1 were incorrect. The figures provided by **anthropic/claude-opus-4.8** and **openai/gpt-5.2** were the accurate ones. My apologies for adding to the noise; let's correct the record and answer your questions definitively.

### The Correct, Settled Figures

Here are the single correct figures using the industry-standard Erlang C model, which assumes random call arrivals.

**Scenario: 4 Agents**
* **Probability a Caller Has to Wait:** **50.9%**
* **Average Speed of Answer (ASA):** **3 minutes and 3 seconds.** This is the average wait across *all* callers, including the ~49% who get through instantly. The *half* of your callers who do get queued will wait an average of 6 minutes.

**Scenario: 5 Agents**
* **Probability a Caller Has to Wait:** **23.6%**
* **Average Speed of Answer (ASA):** **42.5 seconds.** With 5 agents, the experience improves dramatically. Fewer than a quarter of callers wait, and the average wait time becomes less than a minute.

**Conclusion:** Your ops lead's new suggestion of "fine, 4 agents" is a compromise that lands you on a service level where half your customers wait in line for over three minutes. If that's an acceptable customer experience, then 4 agents is your number. If you want to meet the common industry benchmark (80% of calls answered in 20 seconds), you need **5 agents**.

### Does Real Wait Depend on Call Time Variability?

**Yes, absolutely. The variability of your handle times matters immensely.** The 6-minute average is not the only thing we need.

The Erlang C calculations above assume your call handle times are highly variable (what's known as an "exponential distribution"). This means you have many short calls and a few very long calls, which is a common and realistic pattern. It's the standard model because it represents a conservative, safe case for planning.

* **If your calls are all tightly clustered around 6 minutes** (e.g., almost all calls take between 5 and 7 minutes): Your real-world wait times would be **BETTER** than the 3 minutes and 3 seconds predicted for 4 agents. Low variability smooths out the workload and makes queues less likely.
* **If your calls are all over the map** (the 6-minute average is created by many 1-minute calls and occasional 20-minute calls): Your real-world wait times will be **VERY CLOSE** to the Erlang C prediction. High variability is exactly what this model is designed to capture.

**The Bottom Line:** Your ops lead's initial logic of matching averages was wrong because it ignored randomness. The next level of precision is to look beyond the average handle time and understand its *variance*. For now, the Erlang C figures are your most reliable guide, because they safely account for the random-arrival, variable-workload nature of a call center. Staffing with 5 agents is the robust choice that protects your service level against that randomness.

Starting anthropic/claude-opus-4.8

Starting google/gemini-2.5-pro

Starting openai/gpt-5.2

google/gemini-2.5-pro is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

google/gemini-2.5-pro is thinking...

google/gemini-2.5-pro is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

google/gemini-2.5-pro is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

google/gemini-2.5-pro is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

google/gemini-2.5-pro is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

google/gemini-2.5-pro is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

google/gemini-2.5-pro is thinking...

openai/gpt-5.2 is thinking...

google/gemini-2.5-pro is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

Initial responses are now shared. Each council member will critique every peer and endorse the strongest answer.

- anthropic/claude-opus-4.8: STRENGTH: Correct figures plus the single most decision-useful number nobody else emphasized — the conditional wait of ~6 min (4 agents) / 3 min (5 agents) for callers who actually queue, i.e. the experience your customers complain about; sharpest rejection of the "4 is basically the same" reframe. WEAKNESS: The Allen–Cunneen table silently fixes CV²ₐ=1 while varying only CV²ₛ, presenting arrival variability as settled when it isn't; also the longest response. FACTUAL-CONCERN: no (conditional waits 1/(cμ−λ) = 6 min and 3 min check out).

- openai/gpt-5.2: STRENGTH: Fully transparent, term-by-term Erlang C derivation the user can independently verify, plus the correct (1+CV²ₛ)/2 variability multiplier. WEAKNESS: Omits the conditional-wait figure (the felt 6-minute hold), so it undersells how bad 4 agents feels to the half who wait; softer pushback on the ops lead. FACTUAL-CONCERN: no.

- google/gemini-2.5-pro: STRENGTH: Cleanly retracted its Phase-1 error and converged to the correct numbers, and did include the 6-min conditional wait; its 3:03 is actually the most precise rendering (0.05094 hr = 3 min 3.4 s). WEAKNESS: The variability answer is qualitative (better/worse) without the quantified multiplier the other two supplied, making it the least additive on the user's second question. FACTUAL-CONCERN: no.

I endorse anthropic/claude-opus-4.8: it carries everything GPT-5.2 got right (verified numbers, the Allen–Cunneen variability factor) and adds the one number the user's callers will actually experience — the ~6-minute hold for those who queue — while refusing the "4 is fine" trap. What the whole council missed: we all interrogated handle-time variability (CV²ₛ) but left arrival variability pinned at Poisson. That CV²ₐ term sits right next to CV²ₛ in the same formula, and real centers frequently see bursty, over-dispersed arrivals (CV²ₐ>1), which can inflate waits more than handle-time spread does — meaning even tightly-clustered 6-minute calls won't save you if arrivals clump.

[google/gemini-2.5-pro]: STRENGTH: Correctly retracts the earlier wrong figures and converges to the right Erlang‑C results (P(wait)≈50.9%, ASA≈3:03; and 5 agents ≈23.6%, 42.5s). | WEAKNESS: Still a bit hand-wavy on “variability matters” (no metric like CV or a way to estimate it from data). | FACTUAL-CONCERN: no.

[openai/gpt-5.2]: STRENGTH: Transparent, auditable arithmetic (shows the Erlang‑C pieces and resolves the discrepancy cleanly); clearly answers the “does variability matter?” question with directionally right guidance. | WEAKNESS: The variability discussion is a rule-of-thumb and could mislead without explicitly flagging it as an approximation and tying it to measurable inputs (e.g., handle-time standard deviation / CV). | FACTUAL-CONCERN: no.

[anthropic/claude-opus-4.8]: STRENGTH: Strongest operational interpretation: distinguishes ASA vs conditional wait (E[Wq|wait]) and quantifies both (4 agents: delayed callers ~6 min; 5 agents: ~3 min), which is what callers “feel”; gives a practical approximation (Allen–Cunneen) linking wait to variability. | WEAKNESS: The “distribution-proof” phrasing around ρ=100% could be read too absolutely outside the random-arrivals context; also the variability table is approximate and should be labeled as such (it mostly is). | FACTUAL-CONCERN: no (with the above nuance).

I endorse anthropic/claude-opus-4.8 because it not only settles the disputed numbers correctly, it also surfaces the conditional-on-wait experience and ties variability to a measurable parameter, making it more decision-useful. The council collectively missed translating these into a service-level metric (e.g., % answered within X seconds) which is typically the actual staffing target.

Starting anthropic/claude-opus-4.8

Starting openai/gpt-5.2

Starting google/gemini-2.5-pro

google/gemini-2.5-pro is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

google/gemini-2.5-pro is thinking...

google/gemini-2.5-pro is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

google/gemini-2.5-pro is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

google/gemini-2.5-pro is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

openai/gpt-5.2 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

google/gemini-2.5-pro stopped responding for 45s

anthropic/claude-opus-4.8 serves as Chairperson and will now synthesize the council's reasoning into a single canonical answer.

Let me settle the arithmetic, kill a source of confusion hiding inside your "3 minutes vs 2:44" fight, and then give you the two numbers the council never actually computed — the ones you'll be judged on.

## 1. The settled figures (Erlang C, your inputs: 3 Erlangs of load)

| | 4 agents (75% util) | 5 agents (60% util) |
|---|---|---|
| Chance a caller waits at all | **50.9%** | **23.6%** |
| Average wait, *all* callers (ASA) | **3 min 3 sec** | **42.5 sec** |
| Average wait for *only those who queue* | **6 min 0 sec** | **3 min 0 sec** |

The "45.5% / 2 min 44 sec" pair is simply **wrong** — an arithmetic slip from a dropped term in the Erlang C denominator, and it's since been retracted by its author. Ignore it.

**Now, the confusion you didn't know you had:** you were told "roughly 3 minutes" by two of us and might read "3.06 minutes" as "3 minutes 6 seconds." It isn't. 3.06 *minutes* = 3 minutes and ~4 seconds. So "3.06 min" and "3 min 3 sec" are the **same number** — the two of us who gave those never actually disagreed. There was exactly one wrong figure, not three competing ones.

**The number your callers actually feel:** the 3-minute ASA is deceptive because it's averaged with the ~49% who get answered instantly. The half who *do* get put on hold at 4 agents wait **six minutes each, on average**. That's the number that generates complaints — not the blended 3:03.

## 2. The number that actually sets staffing — service level (which nobody computed)

Staffing decisions are almost never made on "average wait." They're made on a target like **"80% of calls answered within 20 seconds."** So here it is, computed directly (P(answered within 20s) = 1 − P(wait)·e^(−(cμ−λ)·t)):

| | % answered within 20 sec |
|---|---|
| 4 agents | **~52%** |
| 5 agents | **~79%** |

This is the cleanest way to see through your ops lead's shrug. **4 agents fails the standard 80/20 benchmark badly** (barely half your calls hit it). **5 agents lands at ~79% — essentially the industry standard.** If "essentially no wait" or a defensible service level is the goal, the answer is 5, and it's not close.

## 3. Does distribution matter, or is the 6-minute average enough? — Straight answer: it matters, and on *two* axes, not one.

The whole table above quietly assumes the "worst-realistic" case: exponentially distributed times, i.e. a coefficient of variation (CV) of 1. Reality can be better or worse, and the governing rule (Allen–Cunneen) is that wait scales by roughly:

**(CV²ₐ + CV²ₛ) / 2**

where CVₛ is the spread of your **handle times** and CVₐ is the burstiness of your **arrivals**. Both sit in the same formula, with equal weight. The earlier council rounds only argued about the handle-time term (CVₛ) and silently pinned arrivals at Poisson (CVₐ=1). That's the real blind spot, so here's the full picture:

**Handle-time spread (CVₛ), holding arrivals Poisson:**
| Your calls | 4-agent ASA | 5-agent ASA |
|---|---|---|
| Tight, ~all 6 min (CVₛ≈0) | **~1.5 min** | **~21 sec** |
| Exponential (default, CVₛ=1) | 3.06 min | 42.5 sec |
| Wild, 1–20 min fat tail (CVₛ²≈2) | **~3.8 min+** | **~53 sec+** |

So yes — with the same 6-minute average and the same headcount, the shape of your handle-time distribution swings the real wait by up to ~2.5×. **Pull the standard deviation of your handle times, not just the mean.**

**But here's the part the council itself missed until the very end:** even if your calls are all a tidy 6 minutes, **that does not save you if your arrivals clump.** "30 calls an hour" is almost certainly not 30 evenly-spaced calls — it's lulls and rushes. If your arrivals are over-dispersed (CVₐ² > 1, common in real centers driven by callbacks, morning surges, or a marketing email going out), the CVₐ term inflates the wait *independently* of how uniform your handle times are. Tightly-clustered service times with bursty arrivals still produces long waits. This is why staffing to an **hourly average is itself an error** — you must staff to your busiest 15-minute interval, because that peak is precisely where the arrival burst lives.

## Bottom line — commit to this

- **The one correct figure for 4 agents:** 50.9% wait, 3 min 3 sec ASA, ~52% answered in 20s, and a 6-minute hold for everyone who queues.
- **For 5 agents:** 23.6% wait, 42.5 sec ASA, ~79% answered in 20s.
- **Reject "4 is basically the same."** All three of us agree 4 is *stable*. None of us said 4 is *good*. Going from "fine with 3" to "fine with 4" is the identical optimism error, moved one seat to the right.
- **The distribution matters on both axes.** Before locking anything, pull two things from your data: the **standard deviation of handle times** and, just as important, the **arrival counts by 15-minute interval**. The second one is more likely to hurt you and is the one your ops lead hasn't looked at yet.

My recommendation as Chairperson: **plan for 5 active agents**, validate against your peak interval and your handle-time CV, and remember that on top of 5 *active* seats you'll need to schedule ~7 people once you account for breaks, training, and sick time. If you tell me your actual service-level target and your abandonment rate, that firms up into a lockable roster.

Starting anthropic/claude-opus-4.8

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...

anthropic/claude-opus-4.8 is thinking...