Running a festival bar: throughput, staffing and the fleet
What actually determines how much a festival bar sells - peak throughput, staff allocation, restocking under pressure - and how automation changes each of them.
- Events
- Operations
- Fleet
A festival bar’s revenue is decided in about ninety minutes: the set changeovers, when everyone leaves the main stage at once and every bar on site has a queue. Everything else is a rounding error against that.
So the operational question is not “how do we sell more”, it is “how many drinks can we physically hand over in the ninety minutes that matter”.
The throughput arithmetic
Work it out honestly before the event:
Serving points × drinks per hour per point = your ceiling.
A bartender making cocktails from scratch does perhaps 30 to 60 an hour depending on complexity. A bartender pouring beer does far more. A self-service machine on a three-ingredient cocktail does roughly 60 an hour per outlet, limited by pour time rather than by human speed - and it does not slow down at hour six.
Multiply by your peak window, compare to the number of people who will want a drink in that window, and you have your answer. If the ceiling is below demand, you have a queue, and the queue costs you every sale that walks away.
Where automation genuinely helps
It parallelises the slow part. A machine pouring a three-ingredient cocktail frees the bartender to take the next order, handle payment or serve beer. Two serving paths from one bar.
It removes the complexity penalty. For a human, a six-ingredient cocktail takes twice as long as a three-ingredient one. For a machine, barely longer. This changes what you can put on a festival menu - complex drinks stop being the ones you avoid at peak.
It does not get tired. Hour eight is the same as hour one. On a three-day event this is not a small thing.
It counts everything. Which matters more than it sounds - see restocking below.
Where it does not
Beer. Covered properly in what automation can and cannot do, but the short version is that beer needs a draught system and not a pump.
The human interaction. Some of your queue wants to be served by a person. On a site with several bars, having one that is entirely self-service and one that is entirely staffed serves both populations better than making every bar a compromise.
Bad site power. A machine needs reliable power. Festival power is generator power, and generator power has opinions. Plan the electrical supply as seriously as the bar layout.
Staffing around the machines
The reflex is to cut staff. The better move is to redeploy them:
| Role | Why it exists |
|---|---|
| Restocker | Bottles run out at peak. Someone whose only job is swapping them keeps every machine serving |
| Top-up staff | If you are running cashless, this queue is as important as the bar queue |
| Host / unblocker | One person who helps first-time users at the kiosk lifts throughput more than an extra bartender |
| Bartender | For beer, unusual requests and everyone who wants a human |
That host role is consistently underestimated. Every guest is a first-time user, and one person saying “just tap the picture” removes most of the hesitation that slows a queue.
Restocking is the real constraint
At peak, a popular ingredient empties fast. The bar that keeps selling is the one that knew the bottle was low ten minutes before it ran out.
This is what fleet monitoring is genuinely for. A consolidated view across every machine on site tells you:
- Which bar is about to run dry, and on what
- Which bar is quiet, so you can move staff
- Which drink is outselling forecast, so you can pull stock forward
- Which machine has stopped, before anyone radios it in
Without that, restocking is reactive: someone notices, radios it, someone walks a bottle across a muddy site, ten minutes of sales are lost. With it, restocking is scheduled during the quiet window before the changeover.
The cloud portal is built around this multi-machine view, and the events page covers the fleet setup.
The day-before checklist
Boring, and it is what separates a smooth event from a bad one:
- Every machine calibrated in position, at the temperature it will run at
- A full test pour of every recipe on every machine, not just one
- Spare tubing, spare wristbands, spare nozzle - all on site
- Power tested under simultaneous load, not one machine at a time
- Network tested at the actual bar locations, with a full-site crowd assumed to break it
- Everyone who will touch a machine shown how to change a bottle
- A written answer to “what do we do if a machine stops”
That last one matters most. On a busy site, the plan for a failed machine is worth more than any individual feature, because the failure will happen at the worst possible moment and the answer needs to already exist.
After the event
The data is the part most organisers underuse. What sold, when, at which bar, at what margin - that is next year’s bar layout, staffing plan and menu, decided from evidence instead of memory. Export it while the event is fresh and write down what surprised you. It is the cheapest improvement available to you.