Peak-season readiness checklist

Use this checklist to get a support team through a known volume spike — Black Friday, a product launch, tax season, an enrolment window — without burning out the team or blowing your SLAs. It is built as a countdown: start six to eight weeks out and work forward. If you're reading this closer to the peak, don't skip ahead — do the earlier sections fast rather than not at all, because staffing and hiring have the longest lead times.

How to use it: copy the whole thing into a shared doc, assign an owner and a due date to every section (not every box — sections), and run a weekly stand-up against it. Replace anything in [brackets] with your real numbers, tools, and names. A box is only ticked when it's done, not planned.

The countdown at a glance

---

1. Forecast the peak (T‑8 to T‑6 weeks)

You can't staff or stock what you can't size. Get to a number, even a rough one, and write down the assumptions so you can correct it later.

• Pull last year's same-period volume by day and by hour (or the last comparable peak). Note the peak day and the peak hour — you staff to the peak, not the average.
• Adjust for year-over-year growth: apply your current active-customer or order growth rate to last year's curve. State the rate you used.
• Layer in known events: launch date, marketing sends, promo windows, price changes, migrations. Mark each on the calendar with its expected volume bump.
• Forecast by channel (email/ticket, chat, phone, social) — they don't scale the same way and chat/phone need concurrency limits, not just headcount.
• Forecast the issue mix, not just the total. What broke or spiked last peak? Shipping delays, "where's my order," password resets, refund requests, capacity errors? Rank the top 8–10.
• Estimate contacts-per-order (or per signup / per active user) and sanity-check your total against it.
• Write down a best-case / expected / worst-case range. Plan staffing to expected, and have a documented trigger for the worst-case surge plan (see §2).
• Name a single owner for the forecast who updates it weekly as real numbers arrive.

No clean historical data? Forecast from proxies — orders, signups, email sends, marketing's own projections — and widen your worst-case buffer to cover the uncertainty. A rough forecast you revise beats no forecast.

---

2. Staff to the forecast (T‑6 to T‑4 weeks)

Convert the forecast into hours, then into people, then into named shifts. This is the longest-lead item — start it first.

Size the gap

• Convert peak-day volume into required agent-hours: contacts ÷ (resolutions per agent-hour) ÷ target occupancy. Use realistic handle times for peak (they usually rise).
• Compare required hours to your current team's available hours (minus planned leave). The difference is your gap.
• Decide how to close the gap, in this order of preference: overtime → temps/seasonal → outsourcer/BPO → borrowed internal hands. Cost and ramp time go up as you go down the list.

Fill it

• Freeze non-essential PTO across the peak window and communicate the freeze dates now, in writing, with the reason.
• Confirm overtime budget and voluntary sign-ups before you assume you have them.
• If hiring seasonal/temp staff: start recruiting now, and book their onboarding (product basics, tools, top macros, escalation rules) to finish at least 3–4 days before peak — not on day one.
• Line up borrowed internal helpers (engineers, CSMs, product, even founders) for the worst-case surge. Give them a narrow scope: a few safe macros, tagging, and "escalate everything else." Don't hand them the hard queue.
• Build the peak shift schedule covering your real peak hours and time zones — including early mornings, evenings, and weekends if the data says so. Every shift has a name and a backup.
• Schedule breaks and shift overlaps so coverage doesn't dip at handover. Protect breaks — tired reps make expensive mistakes.
• Define surge triggers: "if queue depth > [N] or oldest ticket > [N] min for 30 minutes, we activate the borrowed-hands plan / open overtime / turn off proactive outreach." Write the exact thresholds and who has authority to pull the trigger.

Staffing readiness check

• Every peak day/hour on the calendar has coverage at or above the forecast requirement.
• PTO freeze is communicated and acknowledged.
• Seasonal hires are booked to finish onboarding before peak.
• Surge plan and its numeric triggers are written and the trigger-puller is named.

---

3. Macros & KB for the issues you know are coming (T‑4 to T‑2 weeks)

You already ranked the top issues in §1. Now make sure a great answer exists for each — pre-written, tested, and fast to reach.

• For each top 8–10 expected issue, confirm there is either a macro/saved reply, a KB article, or both. Fill the gaps.
• Write peak-specific macros for the situations only this peak creates: shipping delays, "order by X to arrive by Y" cutoffs, out-of-stock, promo-code failures, launch-day errors, higher-than-normal wait times.
• Draft a "we're slammed" holding reply that sets an honest expectation ("we're seeing high volume, you'll hear back within [X]") without sounding canned — reps personalize the first line.
• Review every macro for accuracy against this peak: dates, prices, policy exceptions, return windows. A macro quoting last year's shipping cutoff is worse than no macro.
• Add temporary promo/return/extended-hours policies to the KB and to macros so answers are consistent across every rep.
• Test the top macros end to end — insert them into a real draft, click every link, check every variable renders. Broken merge fields at 10x volume is a bad time to find out.
• Confirm search and tagging surface the right macro fast — reps shouldn't hunt. Pin the peak macros or prefix them (PEAK — …) so they sort together.
• Put a one-page "peak cheat sheet" in front of every rep: top issues, the macro for each, what to escalate, today's shipping cutoff / known issues.

---

4. Self-service & deflection (T‑4 to T‑2 weeks)

The cheapest ticket is the one the customer never has to send. Deflection built before the peak is worth ten agents during it.

• Make sure your top expected questions are answered publicly — help center, FAQ, product UI — and that those pages are current for this peak's dates and policies.
• Put a peak banner on the help center / contact page: current shipping cutoffs, known issues, expected response times, and links to self-serve for the top 3 issues.
• Ensure order/shipping status is self-serve (tracking links, an order-status page, or a "where's my order" flow). "WISMO" is the classic peak volume killer — deflect it hard.
• Update the contact form / bot to route by issue type and offer the relevant KB article before creating a ticket.
• If you run a chatbot / help widget, load it with the peak FAQs and test the top 10 intents; make the handoff-to-human path obvious so it doesn't trap frustrated customers.
• Set honest expectations at the point of contact: show current response times before someone submits, not after. Under-promise here.
• Consider proactive messages for known pain (a shipping-delay email, a status-page notice) to head off the tickets before they arrive — and pre-write them so they're ready to send.
• Verify the status page exists, is discoverable, and someone is responsible for updating it during incidents.

---

5. Escalation paths under load (T‑2 to T‑1 weeks)

At 10x volume, "ask someone" stops working. Every hard ticket needs a named destination and a clock.

• Confirm the escalation matrix is current: for each severity and issue type, who owns it, target response, and where it goes next. (If you don't have one, build it before peak — this is when you'll need it most.)
• Get engineering / product / billing / payments to commit to peak on-call coverage and response times in writing — including nights and weekends if you operate then.
• Define what a Sev1 / "all hands" incident looks like for this peak (payments down, checkout broken, site outage, data issue) and the exact steps to declare and run one.
• Pre-agree decision authority for peak-only calls: refund/credit limits, goodwill gestures, when to extend a promo, when to pause outbound marketing. Reps shouldn't wait on a manager for a $20 credit at midnight.
• Set up a live incident channel (#peak-warroom or similar) with support, eng on-call, and a duty manager, agreed before peak — not created mid-fire.
• Define the "never sits in the queue" list for this peak: security/data issues, legal-bearing language, payment failures at scale, VIP/contractual accounts, anything already breaching SLA. Route these straight to a named owner.
• Confirm every escalation destination is a named human or on-call rota, not a team name with nobody attached.

---

6. On-call & coverage (T‑2 to T‑1 weeks)

Peaks don't respect business hours. Make sure there's always a human who can act.

• Build the support on-call rota for the whole peak window, including nights, weekends, and holidays. Every slot has a primary and a backup.
• Publish the escalation contact list: support lead, eng on-call, payments, comms/PR, and an exec decision-maker — with how to reach each (phone, not just Slack) and their hours.
• Confirm alerting works: queue-depth, SLA-breach, and outage alerts actually page the right person. Test one alert end to end.
• Set coverage handoff rules: what gets logged at end of shift so the next person isn't blind — open incidents, watch-items, pending customer promises.
• Make sure on-call people have access and permissions to actually do the job (admin tools, refund rights, status-page access) — not access requests to file at 2am.
• Agree compensation / time-off-in-lieu for on-call and holiday shifts up front. Goodwill runs out fast when it's unpaid.

---

7. Comms plan (T‑2 to T‑1 weeks)

Half of peak survival is people knowing what's happening — customers, the support team, and the rest of the company.

To customers

• Pre-write customer-facing messages for the likely scenarios: high volume / slow responses, shipping delay, outage, out-of-stock, promo ended/extended. Get any needed legal/brand sign-off now.
• Agree who can publish a status-page update or mass email during an incident, and the approval path (kept short — one backup approver).
• Set response-time expectations publicly and update them as reality changes.

To the team

• Schedule a daily peak stand-up (10 min): yesterday's volume vs forecast, today's known issues, today's shipping cutoff, staffing gaps, one thing to watch.
• Set up a real-time updates channel for the team: new known issues, macro changes, policy calls — so nobody's answering from stale info.
• Name a duty manager per shift who owns the floor: watches the queue, makes the surge call, unblocks reps.

To the rest of the company

• Brief leadership and adjacent teams (marketing, product, ops) on the plan, the surge triggers, and how they'll be asked to help.
• Get marketing to coordinate send times with you — a big email blast into an already-full queue is self-inflicted.
• Agree an exec escalation and reporting cadence for the peak (e.g. a short daily numbers post).

---

8. Freeze & dry-run (T‑1 week / go-live)

• Declare a change freeze: no non-critical deploys, macro rewrites, tool migrations, or policy changes during the peak window. Publish the freeze dates and the exception process.
• Run a dry-run / tabletop: walk the team through "volume just doubled," "checkout is down," "shipping carrier failed" — who does what, in what order. Fix the gaps it exposes.
• Confirm tooling headroom: helpdesk seats/licenses, chat concurrency limits, phone lines, and any per-plan send/API limits won't cap you at peak.
• Verify logins and access for everyone on the peak roster, including seasonal and borrowed staff — the day before, not the morning of.
• Print/pin the peak cheat sheet, escalation matrix, and on-call list where the team can see them.
• Confirm reporting dashboards show live queue depth, oldest ticket, and SLA status so the duty manager can see trouble early.
• Do a final macro + link spot-check and a test ticket through each channel.

---

9. Post-peak review (T+1 to T+2 weeks)

The peak isn't over when volume drops — it's over when you've captured what to fix. Do this while memory is fresh, ideally within two weeks.

• Pull the numbers vs forecast: actual volume by day/channel, handle time, SLA attainment, backlog peak and drain time, CSAT. Note where the forecast was off and by how much.
• List what broke and what saved you: the top new issue types, the macros that got hammered, the deflection that worked, the escalations that stalled.
• Run a blameless retro with the team who worked it. Ask: what did you not have that you needed? What did you waste time on? What should we automate before next time?
• Review staffing accuracy: were you over/under, and when? Which surge triggers fired, and did they fire early enough?
• Harvest new macros and KB articles written under fire — clean them up and keep the good ones for the permanent library.
• Feed a backlog-triage plan for any residual queue so the post-peak tail doesn't rot (see the related backlog-triage template).
• Log product/eng fixes for the root causes that generated the most volume — the cheapest peak is one where the top issue no longer exists.
• Thank the team specifically, pay out what you promised, and write next year's plan now while it's fresh — a one-pager of "keep / change / add" is enough to make the next peak easier.

---

Keep it honest

• Staff to the peak hour, not the daily average — a queue that's fine on average can still leave customers waiting two hours at 8pm.
• Deflection and macros beat headcount — every ticket you prevent or auto-answer is worth more than one you staff for.
• The surge plan only works if the trigger is a number. "We'll add people if it gets bad" is not a plan; "queue > [N] for 30 min → open overtime" is.
• If a section here has no owner and no due date, it won't happen. Assign both, today.