Restaurant management software

At twenty to twelve on an October Saturday, in a restaurant-pizzeria in the Veneto with seventy covers and eleven employees, the owner has three things in front of him. The first is the booking list in a notebook, where the "Rossi, eight people, 8.30 pm" table is written twice with two different times. The second is a floor tablet that sends orders to the kitchen but knows nothing about the stockroom: the burrata ran out yesterday and it is still on the menu. The third is the fish supplier's delivery note on the counter, with a price per kilo nobody has compared with Tuesday's order. At the end of the night the till balances and the stock does not, and at the end of the month the food cost is two points above what the recipe cards say, with nobody able to say where they went.

Restaurant management software exists to remove that Saturday, but not every restaurant needs it, and those that do usually buy the till first and discover later that the problem was elsewhere. You will find what the term really means, the number that says whether you need it or whether a better stocktake is enough, the yearly cost of working by eye, the price difference between a product, a module and a custom piece, and the threshold above which building makes sense. The case that follows is a typical case, reconstructed from restaurants, small chains and staff canteens, with rounded numbers.

A fair warning: I have been building software for companies since 1999, and I built and sold LegalDesk, a program for law firms where a missed deadline is damage. A restaurant has the same problem with another raw material: it does not lack work, it lacks the thread that ties booking, order, stock and supplier together, which today lives in the head of whoever is there that night. Unlike other articles in this series, for most restaurants the conclusion will be: buy a product, do not build anything. I explain when not.

What is restaurant management software, and what is it not?

It is a system that keeps in one place the five things a restaurant touches every day: the booking, the order, the recipe card of each dish, the stock with its suppliers and the till. The value is not in any of the five, it is in the link between them: when the waiter enters a dish, the system knows how many grams of each ingredient it uses, takes them from stock and, at the end of the week, compares theoretical consumption with the real one.

It is not the till: the fiscal register issues the receipt and is compulsory, but it knows what you took, not why Monday's margin differs from Saturday's. It is not an order-taking app, which carries the order to the kitchen and stops. It is not a generic business management system for invoicing and accounting, which does not know that a kilo of sea bass becomes four portions or that the price changes every week. The test is one question: "what did the dish I sold last night really cost me?" If answering takes a spreadsheet, three invoices and the last stocktake, you have a set of tools, not a management system. That is not necessarily bad, and sometimes it is the right choice.

Why does a restaurant lose money when nobody makes a mistake?

Because each step, taken alone, works. The damage sits in the gaps between steps, where information passes by word of mouth or disappears: between booking and table (a table promised twice, another left empty by a no-show), between order and stock (the finished dish is still on sale), between purchase order and delivery note (the fish price rose sixty cents and nobody saw), in the kitchen (a hundred and twenty grams of pasta instead of a hundred, over eight thousand dishes a year, is a hundred and sixty kilos) and at month end, when the stocktake says the food cost is two points above theory and nobody knows whether it is waste, theft, generous portions or errors. Nobody is to blame, which is exactly why it costs so much. My rule is simple: if answering "where did the two points go?" takes more than ten minutes, the information does not exist in the restaurant, it exists only in someone's head.

How much does it cost every year to run a restaurant by eye and on paper?

Five items. The case: seventy covers, eleven employees, about 64,000 covers a year, 1.4 million euros of revenue and purchases of 34 per cent of sales, about 476,000 euros. Food cost deviation: 2.4 points of revenue, 33,600 euros. Wrong or lost orders: six a day over 310 days, 1,860 dishes remade at twelve euros, 22,320 euros. No-shows: 9 per cent of about 4,400 bookings, 396 empty tables of 2.8 people at fourteen euros of gross margin per cover, 15,523 euros. Suppliers without price control: 1.8 per cent of purchases, 8,568 euros. Time: nine hours a week of a manager at twenty-eight euros, 12,600 euros.

The total is about 92,600 euros a year, 6.6 per cent of revenue, and the first two items alone weigh 60 per cent. Below 2 per cent of revenue the problem is not a priority; above 4 it almost certainly is. The assumptions are prudent but they are assumptions, and must be redone with your figures.

What is the number that decides whether you need restaurant software?

It is the gap between theoretical and real food cost, in percentage points of revenue. For each dish sold you multiply the quantity by the cost on its recipe card, add up, and compare with real consumption: opening stock plus purchases minus closing stock. The difference divided by revenue is the number. Below one point the restaurant is under control and a good monthly stocktake is enough. Between one and two the problem is method: portions, unrecorded waste, a supplier to review. Between two and four a system pays for itself. Above four you do not know what happens in your kitchen. The case sat at 2.4. Two free checks go with it: the share of dishes sold with a recipe card updated in the last six months (38 per cent in the case) and the share of bookings confirmed the day before (20 per cent, with a no-show rate of 9, against under 3 where confirmation is nearly total).

How do you build a recipe card that calculates the cost of the dish?

You list each ingredient in net grams with its purchase price per kilo, corrected for yield: if you buy a whole sea bass and get forty per cent fillet, the fillet costs two and a half times the price per kilo. Most people skip this step, and it explains half of the deviation in the case. A minimal version, in C# that compiles and can be tested:

public record Ingrediente(string Nome, decimal GrammiNetti, decimal PrezzoAlKg, decimal ResaPercento);

public record SchedaTecnica(string Piatto, decimal PrezzoVenditaNettoIva, IReadOnlyList<Ingrediente> Ingredienti);

public static class FoodCost
{
    public static decimal CostoPiatto(SchedaTecnica s) =>
        s.Ingredienti.Sum(i => i.GrammiNetti / 1000m * i.PrezzoAlKg / (i.ResaPercento / 100m));

    public static decimal Percentuale(SchedaTecnica s) =>
        CostoPiatto(s) / s.PrezzoVenditaNettoIva * 100m;

    public static decimal Scostamento(decimal consumoTeorico, decimal consumoReale, decimal ricavi) =>
        (consumoReale - consumoTeorico) / ricavi * 100m;
}

Example: 120 grams of net fillet at 40 per cent yield and 18 euros a kilo cost 5.40 euros of fish alone, not 2.16. At 22.73 euros net of VAT the fish is already 24 per cent of the price. Start with the twenty dishes that make eighty per cent of sales.

How do you keep the thread between booking, order, kitchen and till?

By giving everything one place to live: a single booking diary fed by phone, website and platforms; orders that leave the tablet already split by kitchen or bar station; every dish sold taking its ingredients out of stock; and at the end of service, till and stock that balance together. The piece that changes the evening most is availability: when stock knows two portions of burrata are left, the dish stops at the third order and the customer never discovers at the table that it is gone. Staff rotas should talk to the system too; see the articles on shift scheduling software and, for stock, warehouse management software.

How do you order from suppliers and check delivery notes and prices?

You order from a minimum stock level calculated on the previous forty days of consumption, and you compare three documents: order, delivery note and invoice. The system flags articles under the threshold and prepares an order for a person to approve. When the invoice arrives it compares each price with the last order and flags rises above, say, five per cent. In the case, 1.8 per cent of purchases leaked this way, mostly because nobody looked. Goods that expire are tied to a batch, so that after a recall you know in five minutes which dishes used it. For the general side of supplier relations see the article on supplier management software.

How do you reduce no-shows and fill the tables?

You ask for confirmation the day before, with a message that can be confirmed in one tap, and for groups and costly evenings with a card guarantee. In the case 9 per cent of bookings did not turn up; an automatic reminder usually brings that under 4, which recovers about 8,600 euros a year at the same covers. Add a waiting list that warns the first in line when a table is cancelled, and a simple customer record with allergies and consent in the right place. Names, phones and allergies are personal data, and health data needs special care: ask your privacy adviser once how to write the notice and where to record consent.

What must restaurant software do about fiscal rules, allergens and hygiene checks?

Three things that are not negotiable. Fiscal documents: the software talks to a fiscal register and must be compatible with yours. Allergens: European rules list fourteen allergens to declare, and if ingredients already sit in the recipe cards, the allergen list of a dish comes out by itself and warns you when a supplier changes a product. Hygiene self-checks, the so-called HACCP: fridge temperatures, blast chilling, sanitising, batch labelling, recorded on a tablet instead of a sheet nobody fills in until the day before an inspection. For the wider subject of documentation see quality management software.

How much does restaurant management software cost: product, module or custom?

A ready-made product costs between sixty and one hundred and eighty euros a month per workstation, three to nine thousand euros a year for three or four workstations, with a setup between five hundred and four thousand euros. The module of a system you already have costs between three and ten thousand euros. A custom piece costs between thirty and sixty thousand euros plus fifteen per cent a year. A complete system with central kitchen and several sites sits between ninety and one hundred and forty thousand.

In the case, a product costs 4,500 euros to set up and 6,500 a year: recovering 40 per cent of the bill, about 37,000 euros a year, it pays for itself in under four months. The custom piece costs 42,000 plus about six thousand of maintenance and, recovering 45 per cent, pays for itself in about ten months against no solution, but not against the product: over five years it costs 36,500 euros more and recovers about 23,000 more. The crossing point is around 100,000 covers a year, about 2.2 million euros of revenue. Below that, and almost always below three sites, buy a product. The rules no product knows are few: a central kitchen supplying several outlets, a caterer with price lists per customer, a canteen with budgets per department, a hotel with breakfasts and banquets on the same stock. Before signing anything, ask how recipe cards, sales history and customer records are exported.

Where does artificial intelligence help in restaurant software, and where not?

It helps where it prepares work for a person who then checks: reading delivery notes and invoices from a photo, proposing an order from recent consumption, writing a confirmation message or a reply to a review. It must not decide allergens (a "gluten free" dish is guaranteed by someone who knows what is in the sauce and that the fryer is shared), nor set prices, nor calculate expiry dates or storage temperatures. One criterion for every smart feature: who answers for the mistake? If the answer is "a person who checked", fine. If it is "nobody, the system decided", no.

Which mistakes should you avoid, and where do you start in thirty days?

Six mistakes: buying the till before measuring, not writing the recipe cards, migrating the whole menu on day one instead of the twenty dishes that count, naming nobody to own the system, not training the floor staff (if the waiter enters "pizza, various" nothing is taken from stock) and starting on the worst day, a December Saturday. In thirty days: in the first week, calculate the deviation on seven days; in the second, write the cards for the twenty dishes that count and look at the ten raw materials that weigh most; in the third, ask two or three vendors for a demo with your dishes and your delivery notes; in the fourth, decide, start on a quiet Monday, and fix the date when you measure again to see whether the number has dropped.

What if the number says it is not your problem?

It may be that the deviation is under one point, bookings are confirmed and the cards are updated. That is good news, and in that case you do not need restaurant software, and whoever tells you otherwise is selling something. The bottleneck is then elsewhere: prices, dish mix, rent, labour cost above 35 per cent, or simply a shortage of staff, which no program solves. Before watching any demo, take one week of sales and purchases and calculate the deviation. If it is over two points, or fewer than one table in two is confirmed, you already have your answer. The rest is a project, not a product choice.

If you want a second look at your case, the road is a conversation through the contact page. For the method of reading the margin of a whole company, from above, there is the article on management control software.