Field note
AI Chatbot Usage Limits: Business Continuity Plan
Map critical work to a documented fallback before a limit appears, and keep model switching separate from access-control decisions.
Map critical work to a documented fallback before a limit appears, and keep model switching separate from access-control decisions.
What a limit looks like when it hits
There are three different events that a team will describe as "the AI has stopped working", and they need different responses.
- A plan usage limit. Consumer and team subscriptions to ChatGPT, Claude and Gemini all cap how much you can use in a window. The message says something like "you have reached your limit" and gives a reset time. The exact caps change often; check the vendor's plan page at the time it happens rather than relying on what was true at purchase.
- An API rate limit. Applications built on the OpenAI or Anthropic APIs receive an HTTP 429 response when they exceed requests or tokens per minute, or a monthly spend cap. The vendors document how these tiers work and how to raise them.
- A capacity or outage event. The provider itself is degraded. The status pages for OpenAI and Claude show current incidents. No amount of retrying on your side will help.
The first thing a continuity plan does is tell the person hitting the wall which of the three they are looking at. Our notes on ChatGPT rate limits and team capacity and the Claude five-hour usage limit go into the vendor-specific detail.
Map the work that actually matters
Most AI use in a small business can wait an hour. Some cannot: a proposal due today, a customer-facing bot, a month-end reconciliation that depends on an assistant. List the tasks where a limit or outage causes a real business problem, and for each one write down:
- the tool and plan currently used;
- the data class involved (public, internal, customer, special category);
- the acceptable delay before it becomes a problem;
- the fallback; and
- who decides to invoke it.
Expect the list to be short. If it is long, the business has become dependent on a single vendor faster than it has built controls, and that is a finding in itself.
Fallback tiers
Write the fallback for each task as one of these, in order of preference:
| Tier | What it means | When it is safe |
|---|---|---|
| Wait | Do the task later or by hand | Delay is acceptable |
| Switch model | Use a different model on the same vendor and plan | Almost always; quality may drop |
| Switch account | Use another licensed seat on the same business plan | When seats and data settings are identical |
| Switch vendor | Use an approved second vendor with a business agreement in place | Only for data classes the second vendor is approved for |
| Manual process | Do the work without AI | Always, if the process is written down |
The dangerous fallback is the one nobody wrote down: a staff member pastes customer data into a personal account on another service because the work account is capped. That is a data breach caused by a usage limit, and it happens because the plan did not give them a legitimate option.
Keep model switching separate from access control
Switching from one model to another within the same vendor and plan does not change where data goes or who can see it. Switching vendor, or switching from a business seat to a personal one, does. Treat those as different decisions with different owners.
A practical rule: anyone can switch model. Only the named owner can approve a switch of vendor or account, and only for the data classes already approved for that destination. Put the approved list in the plan so nobody has to decide it at 16:45 on a deadline.
Reduce how often you hit the wall
- Put shared, high-volume work on a business plan with pooled or higher limits rather than on individual consumer seats.
- For applications on the API, implement backoff on 429 responses, monitor usage against the tier, and request a limit increase before launch, not after.
- Keep prompts and attachments lean. Uploading a 200-page document for a two-line answer burns the allowance.
- Give the team a way to see how much of the allowance is left where the vendor exposes it.
The runbook
One page, kept where the team can find it when the tool is down:
- Check the vendor status page. If there is an incident, wait or use the manual process.
- Check whether the message is a plan limit. If so, note the reset time and switch model or seat as approved.
- For API applications, check the error code and the usage dashboard, then apply the documented backoff or spend adjustment.
- If the task is on the critical list and the delay exceeds the acceptable window, invoke the approved fallback and tell the owner.
- Never move data to an unapproved account. If in doubt, do the task by hand.
Review the runbook after each incident and whenever a plan changes. The AI rollout diagnostic includes continuity and data-boundary questions if you want a structured check of where the business stands.