Two businesses, one company
A seasonal business is really two: a quiet one where manual handling is fine, and a peak one where the same processes collapse. Automation should be sized for the peak and cheap when idle.
That changes both what to build and how to pay for it. Usage-based infrastructure suits seasonal businesses considerably better than fixed capacity.
The timing rule
- Quiet season: scope and build, when people have time to specify properly
- Shoulder season: parallel running at moderate volume
- Several weeks before the peak: freeze changes
- During the peak: nothing new deploys, and the manual fallback is documented
- Immediately after: review while the experience is fresh
Deploying anything new during a peak is the most avoidable risk in a seasonal business. We will decline to do it, and we will say so at scoping rather than at the deadline.
Automate what multiplies
- Order and enquiry intake, which scales directly
- Customer communication, which scales faster than orders
- Scheduling and dispatch, where the combinatorics worsen
- Payment and invoicing, where a backlog becomes cash flow
Monthly reporting, supplier management and annual compliance stay flat at the peak. Leave them.
Design for the temporary workforce
Seasonal staff arrive with no context and little training time. Systems must be usable on a first shift, with validation preventing the errors inexperience produces.
Design for the newest person in the building, not for the person who has done it for ten years.
Watch where the bottleneck moves
Automation removes one constraint and reveals the next. If intake is automated and dispatch is not, the queue simply relocates.
Model the whole chain at peak volume before deciding what to build, or you will spend money moving the constraint rather than removing it.