How many systems does it take to seat one table?

Every French restaurateur is looking at their admin this week, whether they wanted to or not. From 1 September 2026, every VAT-registered business has to be able to receive supplier invoices electronically through an approved platform, whatever its size. Large and mid-sized companies must issue them from the same date, with smaller businesses following in September 2027. It is a narrow obligation, and for most independents it means choosing a platform and connecting it. But it forces a question worth asking properly at the rentrée: how many separate systems is your restaurant now running, and how many of them know anything about each other?

Why does a restaurant end up with so many systems?

Nobody decides to run a dozen tools. It happens one sensible decision at a time.

The till came first, because you needed a till. Then a booking platform, because the phone was not enough. Then a QR menu during a period when printed cards were awkward. Then a scheduling app when the rota outgrew a WhatsApp group. Then a delivery tablet, then a second one for the other marketplace. Then a mailing tool for the newsletter, a review platform, a supplier ordering portal, and now an invoicing platform because the calendar says so. Each one solved a real problem on the day it arrived.

The figures suggest this is normal rather than a local failing. Industry surveys through 2026 put most operators on a long list of disconnected systems covering ordering, payments, loyalty, stock and marketing, and 37% of restaurants name fragmented systems and data as a leading barrier to giving guests a better experience. Roughly half of brands plan to spend more on technology this year, with digital guest experience the stated priority. Adding another tool is the easy move. Making the existing ones agree is the harder one.

What does fragmentation actually cost you?

Not the subscriptions. Software licences are usually the smallest line, and owners tend to over-focus on them because they are the visible number on the bank statement.

The real cost is attention, and it is paid by the people you can least afford to distract. Count the re-keying in an ordinary week. A booking arrives by phone and is written into the reservation system. The allergy note goes on a paper sheet because that is where the kitchen looks. The guest's email is typed again into the mailing tool. The deposit is taken separately and reconciled by hand on Monday. A menu change is made on the printed card, then again in the QR menu, then again on the delivery listing, then not at all on the third platform, which is where a guest reads it. Each step is a minute. Ten minutes a day across a small team is around fifty hours a year of someone typing something a computer already knew.

Then there is the dropped detail, which costs more and shows up as service. The allergy that stayed on the paper sheet. The regular whose history sits in a system the person on the floor does not open. The table that was quietly combined for a large party and never recorded, so the plan lives only in one manager's head and collapses on their day off.

And there is the decision you cannot make. If bookings, guest history and spend sit in three places that do not join up, you cannot answer plain questions. How many of last month's covers were returning guests? Which nights are actually loss-making once you strip out commissions? Which of your regulars have not been in since June? Any one system holds a fragment of the answer, so nobody bothers asking.

Which systems actually need to talk to each other?

The point is not to collapse everything into one tool. That is not realistic, and any supplier who tells you otherwise is selling. Your till is a till, and in France it has to be a certified one. Your accountant has their own software. Delivery marketplaces run their own tablets and always will.

What matters is knowing which handful of things genuinely have to share a single record.

Anything that touches the guest. Bookings, phone calls, deposits, visit history, preferences, allergies and marketing consent should be one record, not six. This is the group where fragmentation causes visible harm, because the gaps appear in front of the guest.

Anything that touches the room. Bookings, table plan, party size and turn times need to be the same picture. A booking system that does not know your floor plan is a list, not a plan.

Anything a guest reads. Your menu should have one source, with every channel drawing from it. If updating a price means editing in four places, one of them will be wrong within a month, and it will be the one a guest is looking at.

Outside those three groups, separate tools are usually fine. Stock, rotas, payroll and accounting can live on their own without anybody noticing, as long as the exports are clean.

How do you audit your stack before the autumn season?

An hour with a sheet of paper does most of the work.

List every system you pay for or log into, including the free ones and the ones only one person uses. Beside each, write who uses it, what it holds, and what it is connected to. Most owners find two or three tools nobody has opened in months, and at least one that quietly holds guest data.

Then trace a single booking from first contact to the guest leaving, and mark every point where a human retypes something. Those points are your list. Fix the ones on the guest and room paths first.

Finally, ask a question that is easy to avoid: if you dropped a supplier tomorrow, what would you get back? Your guest list, your booking history, your menu, in a format you could actually use. If the answer is unclear, that is a bigger risk than the monthly fee.

How Deskadora helps

Deskadora is built around the first two groups above, so the guest and the room share one record.

A booking taken through the widget on your own site, a call answered by the AI voice agent, and a reservation entered by hand all land in the same book. The guest profile, the deposit rules, the floor plan and the guest CRM read from that one place, so an allergy captured on the phone at 20:15 is visible to the floor without anyone copying it anywhere. There are no per-cover commissions on those bookings, and the guest details stay yours.

The digital menu works the same way. One menu, edited once, with translations across twelve languages that keep any wording you have corrected by hand rather than overwriting it. It stays free without limits on items, photos or languages, which makes it a low-risk way to see how the platform behaves before you move anything else.

Deskadora does not replace your till, your accounting software or the invoicing platform you need for September. It is not meant to. The aim is narrower: the guest and the room in one system, so the retyping stops and the details stop falling out.

If your audit turns up more copying than you expected, a twenty-minute demo covers the reservations side, deposits, the voice agent and floor management.

FAQ

How many systems should a small restaurant be running?

There is no correct number, and chasing a low one for its own sake is a poor use of a rentrée. A fifty-cover independent typically needs a certified till, something for bookings and guests, a menu, an invoicing platform, and accounting, with rotas and stock either separate or handled inside one of those. Five or six well-chosen tools that share the right records will beat three tools that force manual copying. The test is not how many logins you have, it is how many times a week somebody types the same fact twice.

Is it worth changing systems in September, or should we wait until winter?

September is the better month for anything touching bookings and guests, because the autumn and year-end season is decided in the next few weeks and you want the new setup carrying those reservations rather than migrating mid-December. Anything touching the till or payments is safer in January, when a quiet week gives you room to fix problems. Change one thing at a time either way, and keep the old system readable for a month afterwards.

What should we ask a supplier before signing?

Three things. What can I export, in what format, and can I do it myself without asking you. What does this connect to today, with names rather than a promise of an integration later. And who owns the guest data, in writing. A supplier who answers those three plainly is usually straightforward on everything else. Ask about pricing structure too: a per-cover or per-booking fee means your bill grows precisely when the restaurant is doing well.