On this page
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 actionable. "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.
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.