Restaurant automation: what to automate.

Order intake, every time. It's the job with the most repetitions, the most channels and the highest cost per mistake.

The usual picture in an independent takeaway is a counter till, a phone with a notepad, a website that emails you, and two or three tablets from the delivery apps propped on a shelf. Somebody keys each app order into the till by hand, or worse, doesn't, so the stock numbers and the sales report are both fiction by Sunday. Every one of those transcriptions is a chance to get an address, a modifier or a total wrong.

Pulling every channel into one queue that prints or displays in the kitchen on its own removes the transcription entirely. It saves a minute or two per order, which sounds small until you multiply it by 80 orders on a Friday, and it makes every number downstream true. Do this before anything else, because most other automation depends on the data it produces.

The parts customers can feel, and the parts where being wrong is expensive.

Nobody should get an automated reply to a complaint. An allergy question needs a person who knows what's in the sauce, and a system that answers it for you is a liability. The regular who comes in on a Wednesday wants to be recognised by a human, not greeted by name on a screen. Hiring, the last look at a plate before it leaves the pass, and the decision to comp a table are all judgement calls that shouldn't be handed to a rule.

There's a softer version of the same mistake: automating the message but not the thought. A birthday text with the wrong name, or a win-back offer sent to somebody who stopped ordering because their last delivery was cold, does more damage than silence. Set the rules, then read what actually goes out for a fortnight before you leave it alone.

Partly, and this is the one people oversell, so here's the honest version.

Software can deduct ingredients as items sell, once you've told it what's in each dish. It can hold a par level per line and flag when you'll run out before Thursday. It can draft a supplier order from what's actually sold, and it can log waste by reason so you find out whether you're binning prep, spoilage or mistakes.

What it can't do is fix bad inputs. Recipes have to be accurate and kept accurate when the chef changes a portion. Deliveries have to be entered, including the short ones. Waste has to be logged honestly rather than at the end of the week from memory. Skip that discipline and the system will confidently tell you that you have nine kilos of chicken while the walk-in is empty. Start with your twenty highest-volume ingredients rather than the whole store, get those right, and extend from there.

Almost all of the repetitive part, which is the part that never gets done manually.

Set a handful of triggers and leave them: a thank you after a first order with a nudge towards a second, a message when a regular hasn't ordered in three or four weeks, something on a birthday, a note when a dish somebody orders every time comes back on. These fire off individual behaviour rather than a calendar, which is why they read as attention rather than as a mailshot.

What still needs you is the judgement: what the offer is, how often anybody can be contacted, and whether the tone sounds like your restaurant. Write those rules once, then let the sending happen without you. If you want the mechanics, they're in restaurant marketing ideas.

All of it, honestly. Reporting is arithmetic on data you already have, and doing it manually on a Sunday is how it stops getting done in March.

A short daily summary should land without being asked for: takings by channel, order count, average order value, and anything outside the normal range. A weekly version should compare to the same week last month and flag the movers. Labour as a percentage of sales should be visible while the week is still running, not after it's paid, because that's the only point at which you can do anything about it.

The point isn't the report, it's the alert. Knowing on Thursday that voids are running at three times normal is worth something. Discovering it in a quarterly review is a story, not a fix.

The admin around it, yes. The rota itself, only as a first draft.

Clock-in and clock-out on the till kills the paper timesheet and gives you real hours instead of remembered ones. Those hours can feed a payroll export instead of being retyped. Holiday requests, availability and shift swaps can sit in one place where nobody claims they never saw the message.

A system can also propose a rota from last year's demand for the same week, which is a useful starting point and a bad final answer. It doesn't know that your best closer is sitting an exam on Thursday, that the new kitchen porter can't be left alone on a Saturday yet, or that the forecast is for rain. Take the draft, then have a human fix it in ten minutes rather than building it from scratch in an hour.

Two ways to price it, and only one of them is on the invoice.

The invoice side is the platform subscription and whatever hardware it needs. That's usually a monthly figure per site, sometimes with extra per till or per screen, so ask for the year-one total including hardware rather than the headline rate. The other side is your own time. Add up the daily admin honestly: keying app orders in, writing the end-of-day figures into a book, building next week's rota, chasing the stock count. Forty-five minutes a day is five hours a week and a working month over a year.

Two costs people forget. Setup takes real hours in the first fortnight, mostly loading menus and recipes and getting them checked. And there's a discipline cost that never ends: somebody has to enter the deliveries and log the waste, or the numbers rot.

In this order, because each step makes the next one useful.

First, one order queue: every channel into the till and out to the kitchen with nobody retyping anything. Second, reporting, which now works because the data is complete. Third, customer capture and the two or three marketing triggers, which now work because you have names attached to orders. Fourth, stock, which is last because it needs the most discipline and pays back most slowly. Rotas and payroll fit wherever the pain is worst.

Do them one at a time, a fortnight apart, and check each one is actually being used before you add the next. The commonest failure isn't the software, it's four changes landing on a kitchen in the same week. Most of the steps above sit in one place on Eclyde, which saves the integration work, but the order still matters.