AI for restaurants: what changes in the kitchen and what doesn't

AI for restaurants almost always arrives from the wrong end: a salesperson shows a screen that predicts Saturday's sales, the manager looks on with interest and nobody asks where the data comes from. Two months later the prediction is still there, nobody uses it to decide the supplier order, and the subscription renews out of inertia. In hospitality the margin is so thin that a tool which doesn't change a specific decision is simply a loss.

This guide is about the four or five things that genuinely move the P&L in a restaurant or a group of 2 to 30 sites: forecasting covers, keeping recipe costing alive, organising purchasing, and reading what customers say without spending a morning a week on it. Also which systems you have to touch — POS, kitchen display, purchasing software, delivery aggregators — and in what order, so each phase pays for the next.

A warning up front, because it saves money: in restaurants the bottleneck is never the model. It is that sales live in the POS, recipe costing in a spreadsheet the head chef maintains, delivery notes in a paper folder, and reviews scattered across four portals and two delivery apps. If that isn't joined up, any project stays a pretty demo.

Where does AI actually help in a restaurant?

There are four areas with a defensible return. The rest, today, is either peripheral or ordinary automation with the word "AI" stuck on top.

Forecasting covers and sales by dish. This is the one with most runway, because it touches three costs at once: purchasing, waste and labour. A restaurant that knows three days ahead that Thursday will be 30% quieter buys differently and builds a different rota.

Recipe costing and ingredient cost. This isn't prediction, it's constant arithmetic: the supplier price changes every week, and the costing done in January no longer describes October's margin. Here AI mostly helps by reading delivery notes and keeping prices current without typing.

Purchasing and stock. A suggested order per supplier, built from the forecast, actual stock and lead time. What a restaurant notices isn't saving 2% on the buy: it's no longer throwing out fresh produce and no longer running out of the signature dish on a Friday.

Reviews and guest contact. Classifying thousands of comments by topic (service, waiting time, food temperature, noise, price) and answering the repetitive ones. The volume is high, the text is short and mistakes are cheap because a human always checks before publishing.

If you don't yet have clean ticket history joined to purchasing data, the project you need isn't an AI project: it's a data project. It costs less, and it's the precondition for everything else.

Which systems do you have to touch: POS, kitchen display and purchasing?

No use case works in a vacuum. All of them read from or write to systems you already have, and that's where it gets decided whether the project lands in six weeks or six months.

| System | What data it provides | What to check first | |---|---|---| | POS | Line-level ticket: dish, quantity, time, table, server, discount | Whether it exports via API or only a daily PDF; whether it keeps more than 12 months of history | | Kitchen display / order pad | Prep times per dish, cancellations, time out of the pass | Whether it records order time and service time, not just the total | | Purchasing software | Delivery notes, price by supplier and date, buying units | Whether historic prices get overwritten on update (very common, and it destroys the data) | | Recipe costing | Dish composition, theoretical yield loss, allergens | Whether it lives in the system or in someone's personal spreadsheet | | Bookings | Confirmed covers, no-shows, lead time, party size | Whether cancellations and walk-ins are recorded, not just honoured bookings | | Delivery aggregators | Orders, commissions, incidents, ratings | Whether you can access line detail or only a monthly aggregated settlement | | Rotas and clock-ins | Planned hours versus actual hours per service | Whether the clock-in is tied to the shift and the site |

The question that decides the project is always the same: can your POS export the ticket line by line with a timestamp? If it only gives the daily total you can still work, but the forecast will be of overall sales and you won't know which dish to buy more of. Better to know that before signing, not after. If past integrations got messy on you, the pattern we describe in integrating ERP and CRM without breaking things applies here too.

How do you forecast covers, and what do you do with the forecast?

A forecast nobody turns into a decision is an expensive chart. The useful sequence has three steps, and it's worth demanding them separately.

The forecast. Estimate covers and sales by dish family for each future service. A decent model uses the last two years of history, day of week, local public holidays, the weather forecast, bookings accumulated as of today and nearby events (a match, a conference, a trade fair). A poor model uses the average of the last four Thursdays and fails precisely on the unusual dates, which is where the money is.

Translating it into purchasing. A forecast in covers is useless in the stockroom. It has to pass through the recipe costing to become kilos of each ingredient, minus current stock, and then a suggested order per supplier respecting lead times and minimum order. This is where most tools fall short: they predict nicely and never reach the delivery note.

Translating it into a rota. Covers by time slot become people per shift. It isn't automatic — there are contracts, labour agreements and people with lives — but having expected load by hour changes the conversation from "put two more on, just in case" to "the peak runs 21:00 to 22:30".

What to expect realistically: the first effect is usually not selling more, but throwing away less fresh produce and no longer paying for hours you didn't need. It's a margin gain, not a revenue gain, and it shows up in the waste percentage before it shows up in the till. The underlying mechanics are the ones we explain in demand forecasting, applied to stock that expires in days rather than months.

A typical mistake: judging the model only on the monthly total. In restaurants the total can look right while the daily numbers miss in both directions and cancel out. Always ask for error measured per service, not aggregated.

Can AI keep recipe costing up to date?

This is by far the least glamorous part and the one that recovers the most margin. In most restaurants the costing was done properly once and gets updated "when there's a moment", which there never is.

What can be automated today with confidence:

• Reading supplier delivery notes and invoices. Extracting product, quantity, unit and price from a PDF or a photo and pushing it into purchasing software. This is textbook document extraction, with a human checking anything doubtful. How it's built and what error rate to expect is in document data extraction.
• Price reconciliation. Flagging when the invoiced price doesn't match the agreed one, or when it rises above a threshold. It sounds minor; across a group with 200 SKUs and six suppliers it is money leaking out unseen.
• Recalculating dish cost. If oil goes up 18%, which dishes eat the margin and which hold up. That list, every month, on the table.
• Spotting theoretical-versus-actual drift. The costing says that loin yields 14 portions and the tickets say it yielded 11. The difference is waste, over-generous plating or shrinkage. The system won't tell you which; it tells you where to look.

With real dish cost up to date you can finally talk menu pricing with evidence instead of habit. The framework for doing that without burning the customer is in data-driven pricing. And if the problem sits more with suppliers than with the menu, the logic for vendor qualification and drift detection is in AI in procurement.

What does AI do with reviews and delivery orders?

A five-site group can accumulate 2,000 to 6,000 reviews a year across review portals, maps and two delivery apps. Nobody reads them all. The usual approach is watching the average score, which moves slowly and never tells you what to fix.

What AI contributes here is concrete:

• Classifying each comment by topic, site and sentiment. The output is a monthly dashboard where you see that negative mentions of "waiting" cluster in one site, on Friday nights, and started when the floor manager changed. That is actionable; a 4.2 average is not.
• Separating the kitchen problem from the delivery problem. In delivery, half the "cold" or "late" complaints aren't yours, they're the courier's. Telling them apart changes the decision: one is kitchen training, the other is renegotiating or dropping the channel.
• Drafting replies in the house tone, referencing what the customer actually said, always with a human check before publishing.
• Cross-referencing reviews with operations. If waiting-time complaints coincide with services that had fewer staff per cover, you have a hypothesis to test next week.

How classification works, and where it gets things wrong, is in sentiment analysis. What it does not do, and this is worth saying plainly: it does not invent reviews, solicit them covertly or filter out the bad ones. Beyond breaching portal policies, it gets detected and penalised.

On bookings and contact, an assistant that answers opening hours, gluten-free options, whether dogs are welcome or whether there's a table for four at nine removes half the Friday phone calls. The real conditions of that channel, with its costs, are in WhatsApp chatbots for business. The rule we always give: the route to a human has to be visible from the first message.

Where do you start, and in what order?

An order that works in independent restaurants and small groups, designed so each phase pays for the next:

| Phase | What happens | Typical timeline | What you have at the end | |---|---|---|---| | 0. Data | Join POS tickets, purchasing and bookings in one place; clean duplicate SKUs | 3-5 weeks | A single source you can trust | | 1. Visibility | Dashboard of sales, average ticket, ingredient cost and waste per site | 2-4 weeks | The argument about which number is right ends | | 2. Delivery notes | Automatic extraction of supplier invoices and live recipe costing | 4-6 weeks | Real dish cost, updated on its own | | 3. Forecasting | Model of covers and sales by dish family, per service | 4-8 weeks | You know which services will be quiet, in advance | | 4. Assisted decisions | Suggested order and proposed rota, with human approval | 4-6 weeks | Less waste and fewer stockouts | | 5. Guest contact | Review classification and automated replies to the repetitive stuff | 3-5 weeks | Front of house with a shorter message queue |

Two rules about this timeline. First: you don't skip phase 0, however much the vendor says their tool "connects by itself". It does connect, and it learns from whatever dirty data you have. Second: phase 1 looks unambitious and is the one that changes management meetings the most, because it's the first time every site looks at the same metric defined the same way.

On budget: the range depends mostly on how many systems have to be read and whether the POS has an API. Ranges by project type, and what inflates them, are in what an AI project really costs. If the business also includes rooms, much of the revenue logic is covered in AI for hotels.

What shouldn't you automate in a restaurant?

A short, honest list, because getting this wrong is paid for on the floor:

• Handling a complaint at the table. An upset customer needs a person with authority to comp something. An automated message makes it worse.
• The final supplier order without review, at least for the first quarter. The system proposes; the head chef approves. A buying-unit error (cases versus kilos) is very visible in fresh produce.
• The menu. Which dishes come and go is a culinary call, not an optimisation. The model can tell you the margin each one leaves; it can't tell you what restaurant you want to be.
• The public reply to a one-star review. Automatic draft yes; automatic publishing no.
• The whole rota. Forecast load is one input; reconciling contracts, agreements and people is still the floor manager's job.

Frequently asked questions

How much sales history do I need to forecast covers?

Two full years is the reasonable minimum for the model to separate seasonality from noise and learn local holidays. You can start with one year, but it will miss on the unusual dates, which is exactly where the money is.

Does this make sense for a single restaurant, or do you need a group?

It makes sense for a single site, starting at the bottom. Live recipe costing plus a dashboard with sales, waste and ingredient cost is a few weeks of work and already changes decisions. Fine-grained per-dish forecasting pays back sooner the higher the volume and turnover.

Do I need to change POS to use AI in a restaurant?

Usually no, but you do need to check whether it exposes line-level tickets with timestamps. If it only gives daily totals you can work in weekly cycles; what you won't have is per-dish detail. Changing POS for this reason only makes sense if you were already considering it anyway.

Does forecasting work for delivery too?

Yes, and it's worth treating it as a separate channel. Delivery's hourly pattern, average ticket and dish mix look nothing like the dining room's, and mixing them into one model makes both worse. Two simple models beat one complicated one.

---

If you're weighing up where to start and don't want to buy a tool before the use case is clear, an audit leaves you with a map of what data you have, what's missing and which project pays back first. And if you'd rather test it in half an hour, looking at your POS and your last costing sheet, let's talk.