Peak Season Is a Capacity Problem, Not an Awareness Problem

Take a customer-service team that verifies identity before changing an account detail. In October, a verification takes four minutes and the queue is short. In the second week of December, the queue is three times longer, a third of the agents are seasonal hires in their first fortnight, and a supervisor has asked everyone to keep average handling time under three. Nobody has changed the policy. The verification step is still on the checklist. What it costs has changed.

Awareness does not fix this, because nobody in the story is unaware. The defect is arithmetic: the process was sized for a quiet month, and verification is the part that can be skipped without anyone noticing at the time.

What official and industry sources say about peaks

The CISA and FBI advisory AA21-243A (August 31, 2021), “Ransomware Awareness for Holidays and Weekends,” reported an increase in highly impactful ransomware attacks occurring on holidays and weekends, when offices are normally closed, and said this gives actors a head start because network defenders and IT support are “at limited capacity for an extended time.” It cites attacks around Mother’s Day, Memorial Day and the Fourth of July weekend in 2021. It also says the agencies had no specific threat reporting for the coming holiday; the advice rested on observed timing. Its recommendations include identifying IT security staff to be available and “on call” and reviewing backup schedules for holiday disruption.

That advisory concerns ransomware, not human verification, so we use it for one narrow point: attackers treat reduced capacity as an opening, and the government advises planning for it. The same logic applies to any control that depends on staff attention.

The retail sector’s information-sharing group, RH-ISAC, published a Holiday Trends Report 2024 from member answers. It says members saw increases in call-based social engineering and in loyalty and gift card fraud, that social engineering in stores had involved more threatening behavior and attempts to involve staff through collusion and bribes, and that social engineering by phone had “increased exponentially.” Members also reported using change freezes, staffing adjustments and on-call rotations for security staff. These are members’ reports and not a measured rate, and the report is from the 2024 season.

Why verification gives way first

When time per task is squeezed, steps do not shrink evenly. The visible parts of a job (answering, resolving, closing) are measured. The protective part (checking who is asking) is rarely measured and its omission produces no immediate complaint. Over weeks, the unmeasured step erodes.

This is our synthesis of the dynamic, informed by the sources above, and it does not rest on a measurement. We described the individual-level side of this in security decision overload and the newcomer side in new starters and unwritten rules. The point here is the planning one: a team can see all of these coming on the calendar.

A capacity model you can run on a spreadsheet

Invented numbers, to show the method; replace them with yours.

• Normal month: 600 sensitive requests a week (account changes, resets, payment-detail changes), 6 trained agents, verification at 4 minutes. Verification time needed: 600 × 4 = 2,400 minutes, or 40 hours a week.
• Peak month: 1,500 sensitive requests a week (2.5 times), 9 agents of whom 3 are new and take twice as long. Verification time needed: 1,500 × 4 = 6,000 minutes, or 100 hours a week, plus extra for the new staff.
• Capacity: if staff were only 40 hours a week each and spent a third of their time on verification, nine agents have 120 hours of verification time, which on paper covers 100 with little margin, before breaks, absences and the new staff’s slower pace.

The conclusion of such a sketch is not a number. It is the discovery that verification competes for the same minutes as everything else, and that the margin is thin. At that point a manager has three honest choices: add verified-contact capacity, reduce the number of requests that need verification, or accept that some will go through unverified. The third happens by default when no one chooses.

Decision rules to set before the surge

1. Separate the requests that need full verification. Not every contact is a risk. A password-reset, a payment-detail change and a delivery question differ. Decide which categories always require the full check and mark them in the tooling. Our article on the help desk and the reset process argues that the process, not the agent, is the boundary.
2. Make the slow path the safe path. If the quick route is the only one that fits the handling-time target, it will be used. Give sensitive categories a separate time budget so that the target cannot override the check.
3. Give temporary staff a narrower job. Let new hires handle categories without sensitive changes, and route the rest to experienced colleagues. That is a smaller cost than retraining everyone.
4. Name a delegate for every approver on leave. “Whoever is around” is what an impostor aims for.
5. Freeze the right things. A change freeze helps technical stability. It should not freeze fixes to a verification route that is known to be weak.
6. Plan for the escalation, not just the request. If an agent wants to pause a contact, the pause must be possible: a queue they can send it to, a supervisor who is reachable, and no penalty for the delay.

What to measure

If the aim is to protect verification under load, measure that, not handling time alone.

• Share of sensitive requests that completed the full check, by week.
• Number of contacts escalated or paused, and how long they waited.
• Time to resolution for paused contacts. A rise tells you the pause path is overloaded.
• The count of exceptions granted, and by whom.

The first number matters most. It is the one a peak week will move, and if you only learn about it afterward, it shows up as an incident review. Reviewing those weekly numbers after the season is a better use of an incident-review meeting than reconstructing a single bad day.

What we could not verify

Several vendor pages cite figures about the share of seasonal workers who receive no social-engineering training. We could not trace them to a primary source and have not used them. We also did not find peer-reviewed work on seasonal staffing and verification quality. The model above is an argument from structure and from the shared logic of the two sources about reduced capacity, not a measured effect.

Three scenarios

The same arithmetic plays out differently by sector. These are illustrations of the pattern, not accounts of any company.

In each, the safe design choice is to shrink the set of things that can be done in a hurry. A narrower queue or a blocked change window takes some requests out of the fast lane entirely. That is cheaper than asking every worker to hold the line under pressure. Compare the principle in two approvals are not independent if both trust the same email, which warns that a control can exist on paper and be thin in practice.

The cost of getting this wrong

The argument is not that surges cause fraud. It is that a team can ask for more speed and keep the same checklist, and never be told that those two instructions conflict. Each unverified request that passes without consequence teaches the queue that the check was optional. When one does cause harm, the review often finds a person who did what the day required. The capacity model exists to find that conflict before the season, when it is a spreadsheet and not an incident.

Sources

• Ransomware Awareness for Holidays and Weekends (CISA and FBI, AA21-243A, August 31, 2021): reduced capacity, examples, on-call recommendation.
• Holiday Trends Report 2024 (RH-ISAC): member-reported social engineering and operational changes.