Handoff & service · Explore this field ↗ · Practice · 4 min read
Support capacity scenarios: do the arithmetic before promising automation savings
A transparent scenario worksheet turns contacts, automation completion, repeats, handoff time, and staff hours into assumptions a team can challenge—not a forecast or SLA claim.
Scenario arithmetic flow
- 01State inputs
- 02Calculate unresolved contacts
- 03Add repeat contacts
- 04Convert to workload hours
- 05Compare staffed hours
A scenario explores assumptions; it is not a forecast or SLA.
Original conceptual diagram · not a live trace or measured result.Call it a scenario, not a prediction
Capacity planning is useful when it makes assumptions visible. It becomes misleading when a small pilot ratio is presented as a promise about future staffing or service levels. This worksheet produces a workload scenario: given a hypothetical number of incoming contacts and stated behavior assumptions, how many human-handled contacts and handling minutes would follow? It does not forecast demand, prove an SLA, or determine a staffing decision. Label every input as observed, provisional, or hypothetical.
Amazon Connect’s documentation distinguishes forecasting from scheduling and capacity planning, and notes that its forecasts attempt to predict contact volume and average handle time from historical metrics. That is a much richer practice than the simple arithmetic here. Use this guide to expose a product hypothesis before adequate operating history exists, then replace weak assumptions with reviewed aggregate observations rather than treating a spreadsheet as evidence.
Define the terms before calculating
For one day, write daily contacts; completion fraction; repeat fraction; average minutes per human-handled contact; review hours; people; and productive work hours per person. Here, repeats means extra human contacts per initial unresolved contact, not a percentage of all bot contacts. The transparent formula is dailycontacts multiplied by one minus completion, multiplied by one plus repeat, multiplied by minutes, divided by sixty, plus reviewhours. Staffedworkhours equals people multiplied by productivehours.
That definition matters. It avoids quietly counting a repeat from a supposedly completed bot conversation as though it were part of the unresolved route. It also separates review, training, incident work, and knowledge maintenance from contact handling. If a team changes the definition, change the label and recompute all scenarios; do not compare numbers built from different denominators.
Use contrasting assumptions
Make at least three scenarios: cautious, expected, and stress. Change one or two assumptions at a time so readers can see the driver. The stress case might lower completion, increase repeats among unresolved contacts, and raise handle time because remaining cases are harder. A “best” case that assumes zero repeats and unchanged human complexity is usually a counterexample to good planning, not a decision basis. Add a short note describing why each value is hypothetical or where it was observed.
Worked example, hypothetical: 100 daily contacts, 0.55 completion, 0.10 repeats, 12 minutes per human contact, and 1 review hour yields 100 × (1 − 0.55) × (1 + 0.10) × 12 ÷ 60 + 1 = 10.9 human workload hours. This is arithmetic, not a claim that a real operation will receive one hundred contacts or resolve fifty-five percent automatically. It demonstrates how an increased repeat factor changes the human workload.
Read the output with humility
If workload hours exceed staffed work hours, the scenario signals a capacity gap under those assumptions. It does not identify the correct response automatically. Options may include narrowing scope, improving a high-repeat flow, changing hours, adding trained coverage, routing some work to asynchronous cases, or delaying rollout. Review which assumption is least evidenced before making a commitment. A gap can also indicate that review hours or productive-time estimates need better evidence.
Segment scenarios by job and channel. A support bot can reduce routine information contacts while increasing the average complexity of human handoffs. Blending them into one average handle time hides the change the operation needs to plan for. Google SRE’s overload guidance recommends quantifying work and warns that operational load can displace improvement work. That supports counting maintenance work, not borrowing its practices as staffing targets for a support team.
Acceptance criteria and limitations
A useful worksheet lets another operator recompute every result, identify each input’s source or hypothetical status, and see what work is excluded. Change the assumptions and verify the direction of the result before using it in a planning conversation. Refresh it after a pilot with observed, privacy-appropriate aggregates and a clear observation window. Keep historical scenarios rather than overwriting them, because a changed definition can make a later comparison misleading.
This is not an Erlang queue model, a workforce-management replacement, a forecast, or SLA proof. It does not account for arrival patterns, occupancy, shrinkage, skill routing, absenteeism, concurrency, or severe incident spikes. Its narrow contribution is honest workload arithmetic that resists the easy story that every automated contact becomes saved human time. A decision about staffing requires local constraints and accountable managers beyond this worksheet.
Take it into the review
Hypothetical daily capacity worksheet
| Input or output | Cautious | Expected | Stress | Assumption note |
|---|---|---|---|---|
| Daily contacts | 100 | 100 | 100 | Hypothetical volume |
| Completion fraction | 0.40 | 0.55 | 0.30 | Automated completion |
| Repeat per initial unresolved contact | 0.12 | 0.10 | 0.20 | Extra human contacts |
| Minutes per human contact | 12 | 12 | 12 | Handling and after-contact work |
| Additional review hours | 1 | 1 | 1 | Not already counted in handling |
| Human workload hours | 14.4 | 10.9 | 17.8 | Rounded to one decimal; formula plus review hours |
| Staffed work hours | 12 | 12 | 12 | People × productive hours |
A starting artifact to adapt to your service—not a ready-made policy, compliance certificate or test result.
Primary reading
Sources and limits
These links support the architecture, policy, or product behavior discussed above. Vendor documentation describes vendor features; it is not independent proof of performance. Current details should be rechecked before a production decision.
What the sources establish
Forecasting in Connect Customer
Amazon Connect says its forecasting feature attempts to predict future contact volume and average handle time from historical metrics.
Limits: This article’s scenario worksheet is not Amazon Connect forecasting and makes no prediction.
Checked 2026-09-19 · Amazon Web Services · source publication date not established.
Open original source ↗Identifying and Recovering from Overload
Google SRE describes operational load as ongoing maintenance work and recommends quantifying work when analyzing overload.
Limits: The examples concern SRE work and do not establish staffing ratios for support operations.
Checked 2026-09-19 · Google SRE · source publication date not established.
Open original source ↗Procedures and worked examples are editorial synthesis. Preparation/review dates are not claimed historical publication dates.