Support chatbots that perform well most of the year degrade noticeably during American peak periods. The cause is a change in the mix of questions, not simply more of them.
The question distribution shifts
In a normal month, most contacts are routine: order status, password resets, billing dates. Those are exactly the cases a retrieval-backed bot handles well.
During a holiday rush or an open enrollment window, the routine cases are still there but they are diluted by exceptions. Late shipments, split orders, gift returns and eligibility edge cases arrive together.
Exceptions are the hardest category because they depend on facts the bot cannot see, such as a carrier delay or a manual adjustment made by an agent last week.
Context windows fill with account history
A peak season conversation often carries more history than an ordinary one. The customer has already contacted support twice and expects the bot to know it.
Loading that history consumes the space the model needs for policy text and current state. Something gets dropped, and what gets dropped is frequently the older part of the conversation.
The visible symptom is a bot that repeats a question the customer already answered. The underlying cause is a budgeting decision inside the prompt assembly.
Backend systems degrade first
Bots read live data from order systems, inventory services and billing platforms. Those systems are under their own peak load.
When a lookup times out, the bot has to answer without it. A well built system says so plainly, while a poorly built one answers from general knowledge and gets the specifics wrong.
Escalation paths saturate
The usual safety valve is handing the conversation to a human. During peak periods the human queue is the scarcest resource in the operation.
Companies respond by tightening escalation criteria, which keeps more difficult conversations inside the bot precisely when the bot is least equipped for them. The measured containment rate improves while satisfaction falls.
This is why containment alone is a misleading metric in December or during an enrollment deadline. It rises for reasons that have nothing to do with the bot answering better.
Preparation is mostly about scope
Teams that handle peaks well usually narrow the bot rather than expand it. They pre-write answers for the specific exceptions the season generates and route everything else to people early.
They also freeze changes. A model update or policy rewrite shipped mid-season removes the one thing the operation has, which is a system whose failure modes are already understood.
The lesson repeats every year: peak readiness is an operational design problem rather than a capacity problem, and adding servers does not address the part that actually breaks.