Student term dates and what they do to a UK delivery estate
Restaurant chains with sites in university cities run two businesses in one estate, and the second one disappears for four months of the year. That seasonality is manageable on its own. What makes it expensive is that it destroys your ability to read a soft week, because during vacation a collapse in orders is exactly what you expect. An outage in a student area in July produces the same numbers as a working listing, and nobody investigates a quiet week that was forecast to be quiet.
Why does seasonality make outages harder to find?
Because the usual detection method in most groups is noticing that orders look wrong, and seasonality removes the baseline that word depends on.
A city centre site with steady demand produces a visible dip when its listing goes down. A site whose demand legitimately halves in July produces a dip that matches the forecast. The signal and the noise become the same shape.
That is not an argument for better forecasting. It is an argument for measuring availability directly instead of inferring it from sales, because sales cannot answer the question in a seasonal site at all.
Which weeks are actually the risky ones?
The transitions rather than the troughs, and the arrival week above all.
Vacation itself is low and predictable. The dangerous weeks are the ones where demand changes fast: the return in late September, the collapse in mid December, the exam period, and the sudden end in June. In each of those a listing problem is masked by a real change happening at the same time.
Arrival week is the worst case because it is the single highest demand week of the year in those sites, and because sites are often understaffed and improvising while it happens.
What breaks specifically in these sites?
The same failures as everywhere, plus two that are seasonal.
Hours set for vacation trading and never reverted, which keeps a site closing early into term. And devices that were switched off or left uncharged during a quiet period and are not reliably back before demand returns.
Both are administrative, not technical, and both are invisible until somebody looks at the storefront.
How should the calendar be used?
As a schedule for verification and not only for forecasting.
Term dates differ between institutions in the same city, so the useful list is per site, not per city. Two weeks before each transition, check the published hours, check the devices, and check that the listing is orderable at the hours you intend to trade. That is three checks, four times a year, per site.
Kitchain (kitchain.co) reads the listings continuously, so the check never has to be timed to a term date, and continuous reading earns most exactly here, in the sites where sales are least able to stand in for it.
Does the seasonality itself hurt platform metrics?
Order volume criteria are the exposure. Availability criteria are not, provided the hours are honest.
Just Eat’s Local Legend programme asks for an “Average of 90+ orders per week” alongside “Time offline at 10% or below”, both held “for two consecutive quarters”. A student site can hold the availability criterion comfortably and fail the volume one every summer through no fault of its own.
Knowing that in advance is worth something. It tells you which sites will cycle in and out of programmes seasonally, and stops that being investigated as a problem every year.
What should a group do with sites like these?
Treat them as a separate segment with their own expectations, and give them tighter availability monitoring rather than looser.
The instinct runs the other way, because a seasonal site looks less important during vacation. But a site whose sales cannot tell you whether it is working is the one that most needs something else that can.