OpenAI introduced Presence on July 22 as a managed product for enterprise voice and chat agents. One launch example is especially useful for support leaders: IAG is exploring AI support during severe-weather events, when customer demand rises precisely as the underlying business becomes harder to operate. OpenAI also says its own English-language phone agent resolves 75% of inbound issues without a person.
Those results make surge planning more important, not less. A chatbot that works at normal volume can still fail customers during an outage, product launch, recall, weather event, or viral campaign. Before the next spike, complete this surge card and keep it beside the support incident runbook:
| Field | Decision to record |
|---|---|
| Entry trigger | The traffic, latency, error, or queue threshold that activates surge mode |
| Event source | The canonical status page, incident note, policy, and named content owner |
| Customer promise | What the chatbot can confirm, what it cannot estimate, and when the next update is due |
| Enabled jobs | Answers and actions that remain reliable under pressure |
| Paused jobs | Risky, slow, or dependency-heavy workflows to disable |
| Human reserve | The cases that keep priority access to people |
| Exit trigger | The recovery evidence required before normal service resumes |
The card is deliberately short. During a surge, operators need decisions they can execute in minutes rather than a policy they have to interpret.
Separate the Event From Each Customer's Problem
A traffic spike is an operating condition. It is not a single intent.
Suppose an ecommerce checkout outage sends six times the usual number of visitors to support. Some want to know whether the site is down. Others have duplicate payment holds, time-sensitive delivery questions, unrelated returns, or ordinary product questions. Giving every visitor the same incident banner ignores real problems. Sending every visitor through the normal workflow overloads systems and people.
Classify each conversation on two axes:
Event relationship. Is the request caused by the active incident, possibly related, or unrelated?
Consequence. Can the chatbot safely answer, can it collect details for later work, or does someone need to intervene now?
That produces useful routing. A known status question gets a canonical answer. A duplicate charge gets identity-safe intake and priority review. A routine size question stays automated. A request to change an order may pause if the order system is unstable.
This classification belongs ahead of expensive generation and tool calls. It prevents a broad incident from turning every support path into the same overloaded queue.
Define Surge Thresholds Before Traffic Arrives
"We will know a surge when we see one" usually means the response begins after customers have already found it.
Start with thresholds that reflect the customer experience and your dependencies. The numbers below are illustrative starting points; replace them with baselines from your own traffic and support capacity.
| Signal | Watch | Enter surge mode | Begin recovery review |
|---|---|---|---|
| Conversations per 15 minutes | 1.5× normal for two intervals | 3× normal for two intervals | Below 1.25× normal for four intervals |
| P95 first-response time | Above 8 seconds | Above 20 seconds | Below 8 seconds for one hour |
| Chat error rate | Above 2% | Above 5% | Below 1% for one hour |
| Human queue age | Oldest case above 15 minutes | Oldest case above 30 minutes | Oldest case below 10 minutes |
| Integration failures | Two related failures in 10 minutes | Error budget exhausted or writes uncertain | Reconciliation complete and test writes pass |
Use more than traffic alone. A tenfold increase in simple status questions may be easy to absorb. A twofold increase in account changes can overwhelm identity checks, downstream APIs, or specialist queues.
Rate limits also need separate purposes. Abuse controls protect the endpoint from scripted traffic; surge controls preserve a fair service during legitimate demand. The chatbot rate-limit guide explains the cost boundary. Your surge plan adds customer-aware priorities, dependency health, and a path back to normal.
Degrade by Capability, Not by Channel
The blunt response to pressure is to turn the chatbot off. That sends every visitor to the most constrained resource: the human team.
A better design has named operating modes:
Normal mode. All tested answers, intake flows, and approved actions are available.
Surge mode. Canonical incident answers take priority. Slow or low-value actions pause. The chatbot still handles unrelated, well-grounded questions.
Safe-answer mode. The chatbot answers from a small set of current sources and exact Q&A pairs. Account writes, uncertain lookups, and dependency-heavy actions stop.
Intake-only mode. The chatbot explains the service condition, collects the minimum contact and case details, assigns urgency, and makes no promise it cannot keep.
Unavailable mode. If answers or intake cannot be trusted, show a plain status message and a tested alternative contact path.
Each transition should be a reversible configuration change with an owner. Do not make operators rewrite the system prompt in the middle of an incident. Prepare the incident instructions, Q&A answers, paused-action list, and customer messages before they are needed.
Worked Surge: Six Times Normal Traffic
Consider a hypothetical retailer that normally receives 100 chatbot conversations per hour. A payment incident raises volume to 600. Under normal routing, the chatbot resolves 80%, leaving 120 conversations for people. The support team can handle 45 cases per hour, so the backlog grows by 75 cases every hour.
The first response should reduce avoidable demand without hiding important cases. After reviewing the first 15 minutes, the team configures these routes:
- 55%, or 330 conversations, ask whether checkout is down. A pinned, timestamped incident answer resolves them and points to the status page.
- 25%, or 150 conversations, are unrelated product and policy questions. The chatbot continues answering from current sources.
- 12%, or 72 conversations, report a payment hold but no completed order. The chatbot collects the order attempt time, email, and payment reference for asynchronous reconciliation.
- 8%, or 48 conversations, involve duplicate completed charges, account lockout, accessibility needs, or another priority condition. These retain the human path.
The human queue now receives about 48 cases per hour, close to its capacity of 45. The three-case hourly gap is visible and manageable. The 72 reconciliation cases are not declared resolved; they enter a separate work queue with an honest update promise.
The arithmetic exposes an important constraint. A high containment rate can conceal a growing human backlog if the remaining cases are more complex. Capacity planning must count work after the chat as well as messages inside it.
Protect the Human Queue From Easy Cases
During a surge, "talk to a person" cannot be the only escalation rule. If every uncertain answer receives equal priority, urgent cases wait behind questions the chatbot could have handled.
Reserve immediate human capacity for explicit conditions:
- suspected financial loss or duplicate transactions;
- safety, accessibility, or vulnerable-customer needs;
- identity or account-access failures;
- deadlines that expire before the stated recovery time;
- credible legal, privacy, or security reports;
- repeated failure after the customer followed the published recovery step.
Other unresolved requests can enter structured follow-up. Capture only the fields the team will use, label the reason, preserve the transcript, and state the next checkpoint. The handoff design guide shows how to transfer context without making the customer repeat the conversation.
Human reserve is a policy decision. Document who can change it, which queue receives each class, and how overflow is handled. Otherwise, a well-meaning operator may open the floodgates and erase the capacity the policy was meant to protect.
Make Incident Answers Canonical and Time-Bound
An incident answer should come from one owned record, not a mix of old help articles, cached pages, and improvised prompt text.
Write the answer as a small set of fields:
status: Checkout is currently failing for some card payments. started_at: 2026-07-29T13:20:00Z affected: Card checkout; browsing and existing-order tracking remain available. customer_action: Do not retry if a payment authorization already appears. next_update_at: 2026-07-29T14:00:00Z source_owner: Incident commander prohibited_claim: Do not estimate refund or bank-release timing.
The chatbot can render those facts conversationally, but it should not invent missing times, scope, or remedies. Expire the record automatically after its review time so a forgotten incident answer cannot survive for days.
Source discipline matters outside incidents too. The AI support readiness checklist helps identify canonical policies and owners before increased volume makes stale content expensive.
Recover in Stages
Traffic returning to normal does not prove the operation is healthy. Queues may still contain old cases, writes may need reconciliation, and customers may retry actions after reading an earlier incident message.
Restore service in a controlled sequence:
| Recovery phase | Actions | Exit evidence |
|---|---|---|
| Stabilize | Keep surge message live; test reads and writes; stop new backlog growth | Error and latency thresholds hold |
| Reconcile | Check uncertain actions, duplicates, abandoned intake, and delayed notifications | Every uncertain side effect has an owner |
| Restore | Re-enable one paused capability at a time and run its smoke test | Tool result and customer message agree |
| Observe | Sample new and incident-related conversations | Queue age, repeat contacts, and error rate stay normal |
| Close | Remove incident content and preserve the case set | Review owner accepts the evidence |
Pay special attention to repeat contacts. A visitor may return because the incident answer was unclear, the promised update passed, or an apparently successful action never reached the backend. Resolution rate during the spike will miss that failure unless conversations are connected to later tickets and retries.
Turn representative surge conversations into regression tests: the plain status question, the unrelated FAQ, the priority exception, the uncertain write, and the request that arrives after recovery. The AI support SOP template can hold the roles and evidence rules; the surge card supplies the temporary operating state.
Leave the Next Surge Easier to Run
A useful post-incident review asks which demand was avoidable, which routing protected customers, which promises were missed, and which capability took too long to pause or restore. Update the thresholds and prepared answers while the evidence is fresh.
The goal is controlled usefulness under pressure. Keep reliable answers available, narrow risky capabilities, reserve people for consequences, and require evidence before returning to normal.
In Agentkit, exact Q&A pairs can pin the current incident answer, rate limits can protect public widgets, and conversation logs can supply the cases for the recovery review.
No credit card required.
