On this page
Key takeaways
- A cost spike noticed during service is a decision you can act on; the same spike explained next month is history.
- First rule out the boring explanations, such as a large group, a pricing change or a till error.
- A spike concentrated in one product, hour or section is an execution problem happening now; an even spread usually is not tonight's problem.
- Try the cheapest intervention first, since many spikes have an equipment or setup cause that takes thirty seconds to fix, then give one specific instruction to one named role.
- Record what the spike was and what was done, and set alert thresholds high enough that alerts are not ignored.
Most cost problems in bars are discovered in retrospect, at which point the only available response is to be more careful in future. The alternative is noticing while the conditions are still running, which changes the question from why did that happen to what do we do now.
That change is worth more than it sounds, because a live problem usually has a live cause, and live causes can be removed.
The first question: is it real?
Before acting, rule out the boring explanations, because acting on a measurement error damages trust in the whole system.
A large event or a big group can move a night's numbers without anything being wrong. A pricing change or a new product can move the mix. A till operator error can create a spike that exists only in the data. Check those first, and check them quickly.
The second question: where is it concentrated?
A spike spread evenly across the night and across products is usually a pricing or recipe issue, and it is not tonight's problem.
A spike concentrated in one product, one hour or one section is an execution problem happening right now, and it has an intervention. This is the distinction that decides whether anything is worth doing in the next hour, and it is invisible at the venue level.
The third question: what is the cheapest intervention?
The instinct is to intervene visibly: gather people, announce the problem, apply scrutiny. That is almost always the wrong move mid service. It costs pace, it alarms the team, and it produces a defensive response to something that may turn out to be a delivery error.
Cheaper options first. Check the physical thing: is the pourer missing from that bottle, is the ice machine failing, has the specials board not been changed. A surprising share of spikes have an equipment or setup cause that takes thirty seconds to fix and would never be found by talking to anyone.
Then one instruction to one person
If it needs a human intervention, it should be a single specific instruction to a single named role, not a general appeal to the team. "Put the jigger back on the well gin for the rest of tonight" is an instruction someone can carry out. "Watch the pours" is noise.
This is where most alerting fails. Products in this category are good at raising a flag and poor at saying who does what, so the alert lands on everyone, which means it lands on nobody.
Afterwards: record what it was
The part everyone skips. An hour after service, write down what the spike turned out to be and what was done. Two lines.
The value is not tonight. It is that the fourth time this happens you can see it is the same cause, and a recurring cause with a name is a fixable process problem rather than an unlucky run of nights.
The uncomfortable trade off
Live alerting has a real cost: false positives interrupt a service that is already busy. A system that cries wolf will be ignored within a fortnight, and correctly so. Hospital safety research has a name for this, alert fatigue: busy workers become desensitised to alerts and ignore them, largely because of how many there are.
The right threshold is therefore higher than a vendor demo tends to suggest. Fewer, more certain, more specific. A tool that raises three alerts a night is not more useful than one that raises three a week, it is less useful, because the three a night will be dismissed unread.
CoreTAP is built around the routing half of this: the finding goes to the role that owns it, and whether it was actioned is recorded. The comparisons cover what the alerting products in this category do and do not do.
Frequently asked questions
What should I check first when costs spike during a shift?
Whether it is real. A large event or big group, a pricing change, a new product or a till operator error can all move the numbers without anything being wrong, so check those quickly before acting.
How do I know if a spike needs action tonight?
Look at where it is concentrated. A spike spread evenly across the night and across products is usually a pricing or recipe issue. One concentrated in a single product, hour or section is an execution problem happening now, and it has an intervention.
Should I gather the team and tell them about the problem?
Almost never mid service. It costs pace, alarms the team and can produce a defensive response to something that may turn out to be a delivery error. Check the physical setup first, then give one specific instruction to one named role if a person needs to act.
What should happen after service?
Write down what the spike turned out to be and what was done, in two lines. The value is that when it happens again you can see it is the same cause, which makes it a fixable process problem.
Are more alerts better?
No. False positives interrupt a busy service, and a system that cries wolf will be ignored within a fortnight. Fewer, more certain, more specific alerts are more useful than many that get dismissed unread.