A seasonal business needs processes that hold five times the volume for two months and then relax. What to build, what to freeze in the quiet, and what breaks first.
Key takeaways
- What breaks at the peak is always the same thing: responding to enquiries, not production.
- Build in the quiet, but test against last year's peak numbers.
- Not every automation needs to run all year - some are right to switch on for the season only.
- Temporary staff are part of operational planning, so procedures have to be written before they arrive.
- The most important preparation is the list of what you freeze, not the list of what you scale.
A seasonal business lives in two entirely different states: two months where volume doubles or grows fivefold, and the rest of the year where there is time to think. The common mistake is building processes in the quiet - when everything is calm - and then discovering at the peak that they were not designed for it. The opposite mistake is just as common: building mid-season, when there is no time to test anything.
What breaks first
Not production and not supply - responding. At the peak, enquiry volume grows faster than order volume, because every order brings questions, changes and status checks. Businesses preparing for a peak add operational staff and leave responding with the same people, and that is where the gap opens.
It also explains why most negative reviews in a seasonal business come from the peak rather than the quiet - not because the product was worse but because nobody replied. The automation priority follows from that.
Why load is not spread evenly across the season
Inside the season there is a peak within the peak, and it is usually predictable: the first days after a campaign, the week before a particular date, or the days after a long weekend. Businesses planning to the seasonal average discover the average does not exist in practice.
The way to know is looking at last year's numbers daily rather than monthly. What usually emerges is that around a third of the volume concentrates into roughly a tenth of the days - and that changes staffing plans entirely, along with what has to work without a person.
It is also why automatic responding is worth more here than in any other situation: it is the only thing that holds on exactly the day everything else is occupied.
What to build before the season
| What | Why this specifically |
|---|---|
| Automatic first reply | Holds several times the volume with no extra person |
| Status the customer checks themselves | Cuts most "what is happening" calls |
| Prepared answers to common questions | Shortens handling on every enquiry |
| An enquiry queue with statuses | Prevents enquiries falling through |
| A daily open-items report | Catches a backlog within a day rather than a week |
The last row separates a managed peak from one that runs away. In the quiet you can check weekly; in season, a three-day backlog is already a service crisis - and the logic of a report that sends itself is in scheduled reports instead of asking.
Five checks before the season starts
- The tools - whether their limits cover the expected volume.
- The messages - whether templates are approved and ready to send.
- Permissions - whether temporary staff will have access on day one.
- The alerts - whether anyone receives them, and on which channel.
- The manual fallback - whether what to do if something falls over is written down.
The second check catches a particularly common trap: a message template requiring prior approval will not be approved mid-season, and discovering that gap in the first week of the peak means there is no way to send the message at all. The same trap exists in any channel requiring pre-approval.
Test against last year's numbers
An automation built and tested in the quiet was tested on a tenth of the volume. That is enough to know it works and not enough to know it will hold - rate limits, queues and response times only appear at scale.
So it is worth taking the previous season's data and running against it. If running is not possible, at least calculate: how many messages a day, how many records an hour, and how that sits against the limits of the tools in use. The logic of the volume question is in scoping an automation project.
What runs in the quiet and should not stop
The opposite mistake to overload is switching everything off in the quiet. Some processes should specifically keep running then, because they are what prepares the next season: capturing enquiries, renewal reminders, and following up customers from the previous season.
The second is the most commonly missed opportunity. A customer who bought last season is the cheapest audience for the next one, and one reminder at the right time works better than any cold outreach - provided the list exists and somebody kept it.
The quiet period is also when to do what is impossible in season: clean data, update price lists, write the procedures, and test the automations against last year's volume. All of those need a clear head, which is exactly what only exists now.
What to freeze during the season
This is the list almost no business prepares, and it is more useful than the scaling list. In season there are things better stopped: campaigns bringing enquiries you cannot serve, internal projects, system changes, and "small" improvements to existing processes.
The third is critical. A system change during the busiest week is the reliable way to discover a bug at the worst moment, so it is worth declaring a freeze window - a date after which nothing gets touched until the season ends. The broader logic of peak preparation is in preparing for a seasonal peak.
Temporary staff: what has to exist before they arrive
Somebody joining for two months will not learn the business. What they need is one page per task, access limited to exactly what they do, and one person to ask - and all of that has to exist before they arrive, not on the first day of the season.
This is also where writing procedures pays back in practice: a one-page procedure written in the quiet makes a temporary worker useful on day two rather than in week two, and its logic is in writing SOPs for a small team.
What do you do once the season ends?
This is the point that separates a business improving year on year from one returning to the same state. A week after the peak, while everything is still remembered, it is worth an hour with three questions: what broke, what did we do manually that we had not planned, and what did customers ask about most.
Those answers are the work plan for the quiet period. The third question usually produces the biggest gain - five recurring questions become prepared answers, a field on the website or a line in the order confirmation, and next season they simply do not arrive.
What does not help is postponing that conversation by a month. Details fade fast, and the impression that remains - "it was busy" - is not enough to fix anything.
Sources
Frequently asked questions
Should automations stay active all year?
It depends on what they cost. If pricing is usage-based, you can switch them off in the quiet and on before the season - provided there is a calendar date for switching on, and they get tested before the volume arrives.
When should preparation start?
Three months before, while there is still time to test. A month before allows only scaling, not changing a process - and building in the week before is more dangerous than not building at all.
What if the season starts early?
Switch on what is ready and build nothing new. The simple rule for unexpected load is not to touch what works, and to add people to responding - where it has immediate effect.
Should you increase stock or push supply faster?
An operational question that depends on the business, but for planning it is worth knowing it derives from supplier lead times - and those are assessed from what was measured, as covered in [supplier order cadence](/blog/supplier-order-cadence-and-terms).
Keep reading
Related service
Business Automation
I build custom automations that remove repetitive work end to end.
About the author
Yehonatan Saadia
Freelance automation, web & MVP developer
I'm Yehonatan Saadia, a senior developer who builds business automation, custom websites, and MVPs for small and mid-sized companies across the US, Europe, and Israel. These guides come from real client work, not theory.
Work with meHave a project like this?
Tell me what you're trying to automate or build and I'll tell you the fastest reliable way to ship it.