I joined Ometis about 12 months ago as Head Hospitality Data Strategist. Before that I was at New World Trading Company, and I've spent 20 years working in hospitality.
So I'll start with what I actually see happening right now, not what the slides say.
Operators are scared. One third of hospitality businesses were running at a loss by May 2025, according to a joint survey from UKHospitality, the BII, the BBPA and Hospitality Ulster, an eleven percentage point jump on the previous quarter. The sector is carrying £3.4bn in extra annual costs: £1.9bn in wages, £1bn in employer NICs, £500m in business rates. Between October 2024 and May 2025, hospitality lost 69,000 jobs, where in the same period a year earlier, it created 18,000.
The only sensible question for an operator right now is: what can I actually control, and am I using the data I already have to do it properly?
That's what this piece is about, because in my experience, most operators aren't using their data badly. They're using it three weeks too late.
There are three main places margin gets won or lost: labour, cost of goods, and energy. Everything else is either downstream of those or outside your control entirely.
At New World we had to prioritise them in that order, not because the others didn't matter, but because labour is the biggest line on the P&L and the one where small daily decisions add up fastest. Cost of goods is second because it's tied to demand, so you can't fix it without fixing your forecast first, and energy is third: the unit cost is fixed, the consumption isn't.
Most operators I talk to know all this. What's missing is the ability to act on it before the moment has passed, and that's where data should be doing the heavy lifting.
The instinct when costs rise is to take a hatchet to the rota, and I've watched plenty of operators do exactly that. The danger is that the only person who really suffers is the customer, and then you suffer too because they don't come back. Loyalty is hard-earned and easy to lose, and right now customers are going out less, so when they do, they expect more.
The real lever isn't cutting hours. It's getting the forecast right so you don't waste them in the first place, because if your forecast is wrong, your scheduling is wrong, your prep is wrong, your stock is wrong.
At New World we used six to twelve weeks of trading history to build forecasts the operators could actually trust. The bigger win was being able to alert them when actual trade started deviating from forecast on the day, not a month later in a period review, because sitting in a meeting four weeks after period close, looking at something that happened eight weeks ago, is a terrible place to make decisions from.
This is where machine learning earns its keep in hospitality, and I'd say it's the most underused capability in the sector right now. Not chatbots: forecasting and anomaly detection on top of data you already have.
Every operator has done a menu engineering exercise in the last year: re-layout the menu, push the high-margin dishes, drop the low performers. It's fine in theory, but the problem is the customer mostly knows what they want before they sit down, so re-layouts move the needle less than people think.
What actually shifts margin is granular product-level data combined with what your team are doing at the table, and I've got two stories on this.
Chris Fletcher, who founded Tech on Toast and ran operations at Carluccio's, Hard Rock and PizzaExpress, shared one on a recent webinar of ours. At Carluccio's they nearly took pasta fagioli off the menu based on negative feedback from five or six sites, but when they finally looked at the actual data properly, it turned out to be one of the best-performing dishes in the company. They'd almost cut a winner because they'd listened to a small sample instead of looking at the numbers.
I had a version of the same problem at New World, but the other way round. We found that around 40% of all olive sales across an estate of over 35 sites were coming from one server in one site, and nobody at head office had any idea. The data was sitting in the EPOS, but nobody was looking at it that way.
The point isn't the olives. The point is that the things that move your margin are usually invisible from the centre, and they stay invisible if your data lives in five different systems with nobody pulling it together. Once you can see them, the interventions are cheap. We didn't redesign the menu, we rebuilt the training based on what that one server was doing.
The same applies to drinks per cover, which is about as close as hospitality gets to a holy grail. There's only so far you can push starters, sides and desserts, and the drink with the meal is where the real spend lift sits. But you can't manage it unless you can measure it at site, daypart, even quarter-hour level and compare server to server, and most EPOS systems won't give you that out of the box. You have to build the logic on top, and when we did at New World, it told us exactly where the gap was: the drink that was meant to go with the dish simply wasn't being suggested.
This is the simplest of the three, and my advice here is straightforward. You can't negotiate your way to a meaningfully better unit price right now, but what you can do is look at consumption by site, by day, by hour, and find the kit that's left on, the fridges that are failing, the kitchens over-prepping into the bin. The data is usually already there, but it's just not sitting next to your sales data, so nobody can see the relationship between trade and waste.
If all of the above is so obvious, why isn't every operator doing it? Because the data is trapped.
Your EPOS is one system, your rota is another, your stock platform is a third, your finance system is a fourth. Guest feedback sits somewhere else too.
Chris calls it "tech stacks built on tech stacks", and he's right. Most operators have bought good point solutions over the years, but the integration layer underneath, the bit that pulls it all together and surfaces what matters, is missing. So finance spends six hours a week stitching reports, operators get information three weeks late, and the insight that would actually have moved the needle never reaches the person who could have acted on it.
There's a second problem on top of that. The way teams talk about the data is broken too: WhatsApp groups, scattered email threads, meeting notes nobody reads. Even where the report does get to the right operator, there's no structured way to discuss it, agree what to do and track whether the action worked. That sounds like a soft point, but it isn't. If you don't have a way to communicate around the data, the data becomes wallpaper.
When we work with hospitality groups at Ometis, the architecture we end up with is straightforward. Source systems stay where they are, and we build an integration and automation layer underneath that pulls the data together. On top of that sit role-based dashboards: one view for the GM on a tablet, one for the area manager on a phone, one for finance on a laptop, all working off the same numbers. This is the engine behind Tahola AI, the hospitality-specific platform we've built over more than two decades working with operators in this sector.
Three things make this work in real operations, and I'd say the first one is the most underestimated.
Mobile-first matters more than people think. GMs and area managers are not behind a laptop. They're walking into the building with a phone, ten minutes before a shift handover. As Chris put it on the webinar, today's operators grew up with an iPhone, and their patience for clunky systems is zero. If the information takes more than seconds to get to, they won't use it, and you'll be back to gut feel.
Reporting needs to work by exception, because nobody running 100 sites wants to look at 100 sites. They want to look at the five that are off-trend and the five that are exceeding forecast, and the system should tell them which.
Decisions also need to be pre-made wherever possible, not "here's a report, draw a conclusion" but more like "based on your forecast and your current stock, you'll run out of your top-selling beer on Saturday: here's the action." That's a tool, not a report.
Chris and I both came at this from operations, so we're aligned on this: do not buy AI in hospitality unless you have a use case.
The real value of AI in our sector isn't chatbots or auto-generated marketing copy. It's machine learning on top of the data you already have: forecasting demand, predicting stock shortfalls, flagging anomalies, shortlisting CVs out of 400 applicants. Narrow, useful, measurable.
If a supplier is pitching you AI without being able to tell you in one sentence which operating decision it improves, I'd say walk away. The cost of getting it wrong isn't the licence fee, it's the distraction, and none of us have spare bandwidth for that right now.
A lot of operators I talk to have been burned before: tech that didn't integrate, customer service that disappeared after go-live, road maps that never materialised. The result is healthy scepticism, and that makes the next decision harder than it should be.
My advice is to think about two things. First, Chris uses an 80/20 rule for technology buying and I think it's right. Aim for 80% of the features you actually need to be there now, and accept that 20% might still be on a road map, because no vendor builds for you specifically. Pushing for 100% on day one usually ends in disappointment.
Second, and this is one for those of us on the supplier side as much as buyers: we have to be more honest. Simon Blackbourne, Business Development Director at Ometis, made this point on the webinar and I agree with it. The reason operators are asking us to prove we can do everything is that they've been promised everything before and didn't get it, and the only fix for that is straight conversations about what a partner can and can't do.
A few examples from operators we've worked with at Ometis:
GDK removed 35 spreadsheets from their weekly reporting cycle and saved more than 300 hours a year of finance time, and that time now goes into analysis rather than data entry.
PizzaExpress, operating across more than 300 restaurants, was hitting performance walls with reporting because of the sheer volume of data. With the right architecture underneath, they're now saving close to 30 days a year of reporting time and getting to site-level granularity that simply wasn't possible before.
Red Engine, the group behind Flight Club and Electric Shuffle, had sales and bookings data spread across different systems in the UK and the USA, which made revenue reporting and sales mix analysis slow and complex. We built a data lake in Microsoft Fabric that brought everything together, giving them a single source of truth and a foundation for more advanced analytics across both markets.
None of these are AI stories. They're integration and automation stories: the work that has to happen first.
If you take one thing from this, take this: you don't need a 12-month transformation programme. Pick one cost lever, prove it works, and expand from there.
The honest first step is usually a hard look at what you've got: which systems hold what data, where the gaps are, which decisions are being made on gut feel because the data isn't accessible. That tells you which fight is worth picking first.
If you want to see what good looks like in a working hospitality business, the easiest way is to book a demo of Tahola AI. We'll walk you through how it pulls EPOS, rota, stock, feedback and finance data into one view, what the dashboards look like on a phone for an area manager, and how the forecasting and exception alerts work in practice. No prep needed from your side. Email info@ometis.co.uk or use the demo link below:
A few questions I get asked a lot at the moment:
Fix the forecast first, because most rota overspend comes from scheduling against a poor demand forecast, not from having too many staff on principle. A forecast built on six to twelve weeks of trading history, broken down by day of week and daypart, will usually find efficiency without touching service levels. Cutting hours blindly tends to cost more in lost repeat custom than it saves.
Making decisions on small samples of feedback rather than actual transaction data. The classic version is removing a dish because a handful of sites complain, when the data shows it's a top performer group-wide, and I'd say the second biggest mistake is leaving data trapped in individual source systems instead of bringing it together so you can actually see the patterns.
Yes, but only for specific use cases. Machine learning on demand forecasting, stock prediction, anomaly detection and recruitment shortlisting all have a clear return, but generic AI pitches without a defined operating decision attached rarely pay back. My advice is to treat AI as a feature, not a strategy.
It depends on the size of the business. Best-in-class gives you better functionality in each area but more integrations to manage, while all-in-one is simpler but harder to swap out of later, because if you take one part out you usually have to take others out with it. Chris calls it land-locking and it's a real risk. For smaller operators, fewer systems is often the right call, but for larger groups with the resource to manage integrations, best-in-class usually wins, provided there's a layer underneath pulling the data together.
A platform on its own, Qlik, Power BI, Tableau, is the dashboard layer. The work that determines whether it's actually useful is everything underneath: integrating the source systems, cleaning the data, automating the pipelines, building the right models, and designing dashboards for the people who'll actually use them. We do that end-to-end work, hospitality-specific, with a UK-based team.