Most support surges arrive without warning — an outage, a viral complaint, a botched release. But a whole class of surge is different: you can see it coming on a calendar, sometimes a year out. Black Friday for a retailer. Tax season for accounting software. The renewal month when half your annual contracts come up at once. The January flood after a December sign-up spike. These are seasonal peaks, and they are the easiest support crises in the world to prepare for and the ones teams most reliably get blindsided by anyway — because "we know it's coming" quietly becomes "we'll deal with it when it gets here," and then it gets here. A seasonal peak is not bad luck. It is a scheduled event you chose not to plan for.

Know your calendar before you plan your staffing

Every business has a shape to its year, and support feels it a beat after the rest of the company does. The first job is to find your peaks in the data, not in your gut. Pull twelve to twenty-four months of ticket arrival volume and look for the recurring swells: the months, weeks, and even days where inflow reliably spikes. This is the same staffing and forecasting discipline you'd use for ordinary planning, but pointed at the calendar's fixed dates instead of the weekly rhythm.

The peaks are rarely a surprise once you look. A launch-driven business spikes after launches. A subscription business spikes in its heaviest renewal months and again a beat later when the renewed customers start using what they paid for. An e-commerce tool spikes in November and December and then again in January when the returns and "where's my order" wave lands. Name your two or three biggest annual peaks, put dates on them, and everything else in this article is about not being surprised by dates you already knew.

Forecast the size, not just the date

Knowing when is half the job; knowing how big is the other half. Look at last year's peak: how many tickets per day arrived at the top of the wave versus a normal day? A peak that doubles your daily volume is a very different plan from one that quadruples it. Then adjust for growth — if you have 40% more customers than last year, last year's peak is a floor, not a forecast.

Do the arithmetic honestly. A backlog is inflow minus outflow, and a seasonal peak is simply a bounded window where inflow jumps. If you know the peak will run three weeks at roughly double volume, you know exactly how much extra outflow you need for those three weeks to keep the queue from ballooning. The number is knowable. Refusing to calculate it is a choice.

Deflect before you staff

The cheapest peak ticket is the one that never arrives. Before you scramble for bodies, spend the weeks before the peak shrinking the wave at its source:

  • Pre-write the answers to the questions you know are coming. A seasonal peak is unusually predictable in its content, not just its volume — the same holiday-shipping questions, the same renewal-billing confusion, the same tax-deadline panic every year. Update or write the knowledge base articles for those exact questions now, while you have time to do it well.
  • Put the answers where the surge will hit. A great article nobody finds deflects nothing. Surface the seasonal answers on the help center home page, in the product at the moment of confusion, and in your self-service deflection flows so the peak's most common questions get answered before they become tickets.
  • Get ahead of the wave with proactive messaging. A well-timed status banner or email — "holiday shipping cutoffs are X," "your renewal will process on Y" — is proactive support that prevents a flood of near-identical tickets. One message can outperform a dozen extra agents.

Every ticket you deflect before the peak is a ticket you don't have to staff for during it. Deflection is the lever with the best return, and it's the one that requires the most lead time — which is exactly why it has to come first.

Add capacity for the window, not forever

Once you've shrunk the wave, staff for what's left. The rule is the same as any predictable surge: add outflow for the window, not permanently.

  • Line up surge capacity in advance. Cross-trained employees from adjacent teams, a short-term contractor arrangement, or a BPO partner who can flex up for your peak. The time to arrange this is weeks before, not the morning the queue explodes — surge help you scramble for mid-peak is expensive and undertrained.
  • Protect today's tickets from the peak. Wall off part of the team to keep new, normal tickets inside your first-response-time target while the surge crew attacks the seasonal volume. If you let ordinary tickets rot while everyone fights the wave, you trade a seasonal backlog for a permanent one.
  • Freeze the non-urgent. A peak is the wrong time to ship a risky release, run a migration, or launch a feature that generates its own tickets. Many mature teams run a light change freeze around their biggest peaks so support isn't fighting a self-inflicted surge on top of the seasonal one.

Protect the team, or pay for it in January

The hidden cost of a badly run peak isn't the backlog — it's the burnout. A team that white-knuckles through a three-week surge on mandatory overtime doesn't bounce back the day the peak ends; it limps into the new quarter exhausted, and agent burnout quietly raises your ticket volume as quality slips and customers come back. Plan the recovery, not just the peak: rotate the surge load so nobody carries it alone, protect time off after the wave, and treat the post-peak week as part of the plan rather than a return to business as usual.

Run a post-peak retro every year

The single highest-leverage thing you can do for next year's peak is a thirty-minute retro right after this year's. What did we underestimate? Which questions did we fail to deflect? Where did the queue back up first? Write it down while it's fresh and file it with the peak's date on it. A seasonal peak is the one crisis you get to rehearse annually — a team that captures its lessons gets a little less surprised every year, and the same peak that was a fire drill in year one becomes a routine, well-drilled operation by year three.

The honest test

You planned a seasonal peak well if, when it hit, it felt like a busy stretch rather than an emergency — the extra hands were already in place, the top questions were already deflecting, the normal tickets kept moving, and the team came out the other side tired but intact. If instead the peak arrived as a shock you scrambled to survive, the problem was never the volume. The volume was on the calendar the whole time. The failure was treating a scheduled event as a surprise.