A general manager asked me last week which of her sites had lost the most gross profit, and why.
Normally that question costs three days. Export from the POS. Clean it in Excel. Chase whoever owns the reporting. Get an answer that is already a week stale and does not quite answer what you asked.
She typed it into Claude instead. Nine seconds:
“Site 3, GP down 4.1 points. Driver: beef cost up 18% against a fixed menu price. 62% of the variance sits in two dishes.”
She then asked which two dishes. Then what the margin would be at a 50p price increase. Then whether the same exposure existed at the other sites. Four questions, under a minute, no analyst involved.
I want to be precise about what was interesting there, because it was not the AI.
What was actually built
Anyone can open Claude. That is not the achievement.
What made those answers real rather than plausible-sounding was a Model Context Protocol server connecting the assistant directly to the client’s Microsoft Fabric warehouse. MCP is an open standard for letting an AI assistant query live systems — not a copy of the data, not last month’s export, the actual warehouse.
The distinction matters more than anything else in this article. An assistant without that connection is guessing from general knowledge and whatever you pasted into the chat. An assistant with it is running a query against your numbers and reporting what came back.
One of those is a very confident colleague who has never seen your P&L. The other is a tool.
The part that takes the work
The connection is not the hard bit either. The governance is.
Three things we would insist on before letting any AI near live trading data, and which you should insist on from anyone who proposes this to you:
Read-only by default. The assistant queries. It does not write, update, or delete. There is no scenario in which a language model should be able to modify your trading records, and any architecture that permits it is wrong.
Permissions scoped per role. A site GM sees her site. A regional sees her region. Finance sees everything. The AI layer inherits your existing permission model rather than quietly bypassing it — which is the single most common failure mode when businesses bolt AI onto a warehouse, because it is much easier to connect with an admin credential and worry later.
Full audit trail, and no training on your data. Every query logged. Who asked what, when, and what came back. And a contractual guarantee from your model provider that your data is not used for training. Both of these are table stakes and both are frequently skipped.
Get those three right and this is safe enough for live commercial data. Get them wrong and you have built a very fast way to leak information across your own business.
What actually changes
Everyone expects the answer to be “speed”. Three days to nine seconds is a good headline. It is the wrong answer.
The real change is who gets to ask.
When a report takes three days and requires an analyst, questions are rationed. Only head office asks, and only about things important enough to justify the cost of asking. Everything below that threshold — the small operational curiosities that are actually where margin lives — never gets asked at all.
When a question costs nine seconds, the rationing stops. Your GMs start asking their own questions. And your GMs are the people who can act on the answer that shift, not in next month’s review.
That is the shift. Not faster reporting. Reporting that reaches the people who can do something about it.
Most hospitality businesses have spent a decade building dashboards for head office. The GM got a PDF on a Monday. This is the first technology that meaningfully changes that, because plain English is the only interface that does not require training.
Where this does not work
Two honest caveats, because this is being oversold everywhere right now.
It cannot fix bad data. If your revenue categories are inconsistent across sites, your recipes are out of date and two systems disagree about net sales, an AI layer will answer confidently from broken numbers — and it will sound more authoritative than the spreadsheet did. That is worse than no answer.
Anyone who tells you AI will fix your reporting problem is selling you something. AI amplifies whatever your data already is. If there is configuration debt underneath, this makes it faster and more convincing, not more correct. Fix the foundation first. That is genuinely most of the work, and it is much less exciting than the demo.
It is not a replacement for knowing your business. It answers what you ask. It does not tell you what you should have asked. The operators who get value from this are the ones who already had good instincts and were being slowed down by tooling — not the ones hoping the tool will supply the instinct.
Why now rather than in three years
Every component of this is finished and available today. Cloud warehouses are cheap. The connectors exist. MCP is an open standard, not a proprietary lock-in. The models are good enough and have been for a while.
The gap between what is technically possible in hospitality and what is actually installed in the average UK venue is roughly a decade wide. That gap has never been a technology problem. It is an installation problem — the tools arrived and nobody plugged them in.
Which is a much more solvable situation than it sounds, because installation is a job. It has a scope, a timeline and a price. Prophecy does not.
Your GM should not need SQL to ask a question about her own venue. She has not needed to for about two years now. Most venues just have not been connected yet.
Open Data Sphere builds AI and data infrastructure for UK hospitality operators — including custom MCP servers connecting Claude and ChatGPT to live operational data, with read-only access, role-scoped permissions and full audit trails. Get in touch.