Analytics tells you what happened. This tells you what to do about it.
Every reporting tool in hospitality has the same shape. It shows you numbers and leaves the thinking to you. That is fine on a Monday morning. It is close to useless at 20:47 on a Saturday, when you have eleven minutes of the break left, one duty manager on the floor, and no realistic chance of reading a dashboard, spotting the pattern in it, working out the cause and acting on it before the whistle.
At a live event, the window in which a decision is still worth making is minutes long. So the insight has to arrive already finished.
That is what the AI layer does. It reads what is happening across your venue as it happens, compares it against how your venue normally behaves, and tells you the specific thing worth doing, in plain language, while there is still time to do it.
During the event
Stock, before you run out rather than after. The platform tracks how fast each item is moving at each bar against what is actually behind that bar. When bar 3 is going to run out of its main draught eight minutes before the break ends, you hear about it at minute seven, along with where the nearest surplus is. Not when a bartender has to tell a guest there is none left.
Cancelled and failed orders, with the reason attached. A cancellation is not just lost revenue, it is a symptom. The platform groups them by cause: item unavailable, guest never collected, counter closed early, payment failed. One cancellation is noise. Eleven at the same counter for the same reason is an operational problem you can fix before the second half.
Underperforming sections, and why they are underperforming. The useful version of this is not "the east stand is down." It is "the east stand is doing two euro ten a head against a venue average of three euro forty, and its scan rate is completely normal, so the interest is there and something after the scan is losing it." Those are two different problems with two different fixes, and only one of them is worth acting on tonight.
Where the pressure is about to land. Ordering patterns build before queues do. When the platform sees demand shifting towards one bar faster than that bar can clear it, you get told while moving a person there still helps.
Ask it directly
Every venue has questions no dashboard was designed to answer. Why is bar 2 slower tonight than it was last week. Did the delayed kickoff cost us anything. Which item is quietly dying.
You can ask in your own words and get an answer built from your own event data, with the numbers behind it, rather than a generic one.
Between events, not only during them
The value compounds. After three or four fixtures the platform knows your venue rather than venues in general.
What a Tuesday cup night looks like next to a Saturday derby. Which sections reliably spend and which never have. How much stock a five thousand crowd actually consumes against how much you ordered. Which items earn their place on the menu and which are taking up a line. What last season says you should staff on the same fixture this season.
That is the difference between running an event on experience and running it on your own history, written down.
Controlled, and it does not act on its own
Two questions come up every time, and both are fair.
The first is what the model can see. It works on your event data, scoped to your venue. It is not pooled with anyone else's and it is not used to train a general model. If you are ever benchmarked against comparable venues, that is anonymised and you opt into it.
The second is what it can do. It recommends. It does not move your stock, change your prices or reassign your staff. Every suggestion arrives with the numbers that produced it, and a person makes the call. Your operations team should always be able to overrule it, and the reasoning should be visible enough that they know when they should.
See it running
Fifteen minutes on a screen share is a better explanation than any page. We will run through your venue, your sections and your bars.