How much does a restaurant booking system cost?

Per engagement, and for one room and one sitting the answer is that you should use a free tool. We will name one on the call. Where a group has outgrown that, scoping comes first, priced separately and yours to keep, ending in a fixed price for phase one. Tell us how many rooms or sites, whether you want the ordering channel as well as the floor, and which POS you run, and you will have a band on the first call. Card processing goes to your gateway, not to us.

There are free booking tools. Why would we pay for this?

For one room and one sitting, you should not - use a free tool, and we will name a good one on the call rather than bill you to rebuild it. The threshold is when the floor plan starts costing you money: parties of two seated at six-tops, parties of eight refused that two adjacent tables would have taken, one turn length applied to every party size. Those are decisions made at the moment of booking, and a widget that counts covers cannot make them.

Should we leave the delivery platforms?

No, and we would be suspicious of anyone who told you to. They bring demand you genuinely cannot reach on your own, and that demand is worth its commission. The argument is narrower: the repeat customer who already knows your name and searches for you by it should be able to order on your own channel, where the margin and their details stay with you. Both things can be true at once.

Do we have to replace our POS?

Almost never, and we would rather not. The till works, your staff know it, and replacing it mid-service is a bad trade. We read from it and write to it where there is an interface, and where there is not we say plainly that it is an export rather than an integration. What we build sits alongside it.

Can it handle no-shows?

Card-guaranteed bookings, deposits scaled to party size, and cancellation windows that actually release the table back into the book rather than leaving it held. The part people underestimate is the confirmation channel: a reminder nobody reads does not prevent a no-show, which is why these go out on Viber in Greece rather than by email.

Does it work for a group with different menus per site?

That is most of why a group outgrows a product. Menus, prices and availability that differ by site, stock and waste per kitchen, and consolidated reporting that does not depend on somebody exporting spreadsheets. If your sites are genuinely identical, you need much less than this.

How long does it take?

An own-channel ordering and booking site is typically five to eight weeks. Table and cover management is longer, because the first week is spent on your actual floor plan and turn times rather than on screens - get those wrong and the rest is decoration.

Is it eligible for ΕΣΠΑ funding?

Software and equipment spend under Ψηφιακός Μετασχηματισμός ΜμΕ is subsidised at 50-60%, and restaurant businesses generally qualify. We are not ΕΣΠΑ consultants and will not advise on your application, but we will write the technical specification and costing your consultant needs.

For restaurant groups, not for a single taverna

A restaurant is a floor plan, not a number of covers

We build table and cover management, and the ordering channel that belongs to you rather than to a platform - for Greek restaurant groups running several rooms or sites, where the free booking widget stopped being enough about a year ago.

Book a call Try the allocator

table-allocatorworked examples

The allocator below is really assigning tables - tightest fit, real turn times, and it will tell you what a setting is costing you.

In plain language

What is table management, and why is a booking widget not enough?

A booking widget models a restaurant as a number of covers per sitting: it counts how many people it has accepted and stops at a limit. Table management models the actual room - tables of fixed sizes, which ones can be pushed together and which cannot, how long a party of two occupies a table compared with a party of eight, and how much of the evening a booking consumes rather than just how many people it contains. The difference shows up as lost revenue in two specific ways. A widget will seat a party of two at a six-top because it only checks the cover count, burning four seats for two hours. And it will refuse a party of eight that two adjacent four-tops would have taken, because it has no concept of pushing tables together. Neither is a reporting problem you can fix afterwards; both are decisions made at the moment of booking, which means they are the software's job.

Words that get used interchangeably and should not be

Cover: One diner. Covers are what a widget counts and what a P&L reports, which is why it is tempting to schedule against them - but two covers at a two-top and two covers at an eight-top are not the same evening.
Turn time: How long a table is occupied. It varies with party size far more than most systems allow for: a deuce is out in ninety minutes, a party of eight is not. One turn length applied to everything either loses the late sitting or holds tables empty.
Own channel: Ordering and booking on your own site and your own app, where the margin and the customer's details stay with you. Delivery platforms bring genuine demand you would not reach; the argument is not to leave them, it is to stop them owning the customer who already knows your name.
No-show and deposit: The empty table nobody paid for. Card-guaranteed bookings, deposits on large parties and cancellation windows are all software features, and they are the difference between a policy you have and a policy that holds.

The floor, and the seats it leaves empty

Pick a party size and a time. The allocator assigns the tightest table that fits, and the plan shows what that cost: every chair nobody is sitting in stays hollow. Switch table-combining off and try a party of eight - instead of "fully booked" it names the two tables that would have taken them, which is the refusal a manager can act on. Then hold the two-tops for walk-ins and watch what that policy costs.

Pick a party size and book it - see which table it lands on.
Try a party of eight with combining off, and see which tables it would have needed.
Hold the two-tops for walk-ins and see what that costs in bookings.

0/3

table-allocatorinteractive

Party size90 min turn

Allow pushing tables togetherHold the two-tops for walk-ins

Service at

freeseatedpushed togetherheld for walk-insempty chairClick a booking to cancel it.

Pick a party size, then a time.

22 covers booked0 seats wasted26% floor in use

Real allocation, running in your browser - turn times, tightest fit, table combining, seats wasted, all genuinely computed. Nothing is sent anywhere. The plan and the timeline are two views of the same service. Six tables and one evening is a simplification of a real floor; the logic is not.

Your own regular, at platform prices

Nothing here argues that Greek restaurants are under-served by booking tools - they are not, and the free ones are good. The argument is about what a platform charges you for the regular who already knew your name, and about what happens above a certain size.

27-30%: the commission Greek restaurants report paying efood and Wolt on an order, while the platforms say their rates exceed 20% only on some packages - and it is charged whether or not the platform found you that customer
myDATA: electronic invoicing through the ΑΑΔΕ platform is an operating obligation, so an ordering channel that cannot issue a compliant receipt is not finished
97.18%: of Greek searches run through Google, so the own-channel argument is also a findability argument - one site you control, not a listing you rent

What we build, once the free tool has run out

If you have one room and one sitting, use a free booking tool - genuinely, and we will name a good one on the call. These four are what a group ends up needing instead.

Table and cover management
Bookings assigned to tables rather than counted against a limit: turn times by party size, tables that combine and tables that do not, sections and server loads, walk-in holds you can set by service rather than by policy document. The reporting that comes out of it is about seats and time, which is what the floor actually runs on.
- Floor plan
- Turn times
- Combining
- Walk-ins
Ordering on your own channel
A site and app where your own customers order for collection or delivery, issue a compliant receipt through myDATA, and stay yours afterwards. The platforms keep bringing you the demand you cannot reach on your own - this is about the repeat customer who already knows your name.
- Own site
- myDATA
- Viva Wallet
- Flutter
No-shows, deposits and large parties
Card-guaranteed bookings, deposits scaled to party size, cancellation windows that actually release the table, and confirmations on the channel Greek guests reply to. A large-party policy that lives in a document is not a policy.
- Deposits
- Cancellation
- Viber
- Stripe
Several rooms, several sites
One back office over a group: menus and prices that differ by site, stock and waste per kitchen, staff rotas against forecast covers, and consolidated numbers that do not require somebody exporting three spreadsheets on a Monday.
- Multi-site
- Menus
- Rotas
- Reporting

What it connects to, starting with the till you keep

A kitchen already runs on several systems. Replacing the till is almost never the project.

POS and till systems: Entersoft, SoftOne, Oracle Simphony and the Greek POS most kitchens actually run - read from, written to, not replaced.
myDATA / ΑΑΔΕ: Receipts transmitted through a certified provider, with the VAT treatment right for dine-in against takeaway.
Delivery platforms: efood, Wolt and Box orders landing in the same queue as your own, so the kitchen works one screen rather than four tablets.
Greek payments: Viva Wallet, Stripe, IRIS and bank gateways, with card-guaranteed bookings and deposits where they earn their keep.
Viber and SMS: Confirmations and reminders on the channel guests reply to - the cheapest measurable thing in the whole build.
Google and Maps: Reserve-with-Google and menu structured data, so your own channel is the one that surfaces.

What it costs, and when a free tool is the answer

Lower than the rest of this site, because the projects are smaller. Compare every band below against a free tool before you read it as a quote.

Own ordering and booking channel
€3.5k - €7.5k
Bookings and ordering on your own site, taking payment, issuing a myDATA receipt, confirmations on Viber. The commonest first project for a group that has decided it wants the customer relationship back.
Table and cover management
€8k - €14k
The allocator on this page, built properly: your floor plan, your turn times, combining rules, walk-in holds, sections, and the reporting that comes out of scheduling against tables instead of covers.
Group back office
€14k - €20k
Several sites in one system: menus and pricing per site, stock and waste per kitchen, rotas against forecast covers, consolidated reporting. Phased, and scoped before quoting.

Card processing goes to your gateway, not to us. A scoping engagement on its own is €1,250-€2,500 and you keep the document - including if it concludes that an off-the-shelf product plus your existing POS would serve you better than anything we would build.

What we measure in seats and time

Covers is the number a P&L reports and the wrong one to schedule against. The floor runs on seats and on hours, so these four do too.

Seats left empty per service: Table capacity minus party size, summed. Nobody was measuring this, and it is the number that makes the case for the whole system.
Floor in use at peak: Table-hours booked against table-hours available, for the two hours that matter rather than the whole day.
Bookings refused, with the reason: Split by cause. A refusal because combining is switched off is a setting; a refusal because you are full is a good evening.
No-shows after a deposit: Against no-shows before one. The only honest way to know whether the deposit policy did anything.

What we have shipped

Work for clients and tools we run in public, each labelled as which it is. Where the tool is the demo above, you can check it yourself instead of taking our word for it.

4
Turn-time bands derived from party size, because one length either loses the late sitting or holds tables empty
Our own tool · Restaurant group · 2025
Scheduling against tables instead of covers
A widget that counts covers will seat two people at a six-top on a Friday, then refuse a party of eight that two adjacent tables would have taken. Both are decided at the moment of booking, which makes them the software's job. This is the allocator that makes them properly.
- Next.js
- TypeScript
- Postgres
- Viber
Read the build It runs in the demo above

What we can build

None of these exists. Each is a system we have specified for this sector at the level of detail we would start from: the parts that are hard, the decisions that would have to be made early, and what would be worth measuring once it runs.

Proposal
Restaurant group
The repeat customer who should not arrive via a platform
An own-channel ordering and booking site for a group, issuing compliant myDATA receipts, with delivery-platform orders landing in the same kitchen queue rather than on a fourth tablet.
- Next.js
- Flutter
- Postgres
- myDATA
- Viva Wallet
Read the build It runs in the demo above

Questions we get asked about this

How much does a restaurant booking system cost?: Per engagement, and for one room and one sitting the answer is that you should use a free tool. We will name one on the call. Where a group has outgrown that, scoping comes first, priced separately and yours to keep, ending in a fixed price for phase one. Tell us how many rooms or sites, whether you want the ordering channel as well as the floor, and which POS you run, and you will have a band on the first call. Card processing goes to your gateway, not to us.
There are free booking tools. Why would we pay for this?: For one room and one sitting, you should not - use a free tool, and we will name a good one on the call rather than bill you to rebuild it. The threshold is when the floor plan starts costing you money: parties of two seated at six-tops, parties of eight refused that two adjacent tables would have taken, one turn length applied to every party size. Those are decisions made at the moment of booking, and a widget that counts covers cannot make them.
Should we leave the delivery platforms?: No, and we would be suspicious of anyone who told you to. They bring demand you genuinely cannot reach on your own, and that demand is worth its commission. The argument is narrower: the repeat customer who already knows your name and searches for you by it should be able to order on your own channel, where the margin and their details stay with you. Both things can be true at once.
Do we have to replace our POS?: Almost never, and we would rather not. The till works, your staff know it, and replacing it mid-service is a bad trade. We read from it and write to it where there is an interface, and where there is not we say plainly that it is an export rather than an integration. What we build sits alongside it.
Can it handle no-shows?: Card-guaranteed bookings, deposits scaled to party size, and cancellation windows that actually release the table back into the book rather than leaving it held. The part people underestimate is the confirmation channel: a reminder nobody reads does not prevent a no-show, which is why these go out on Viber in Greece rather than by email.
Does it work for a group with different menus per site?: That is most of why a group outgrows a product. Menus, prices and availability that differ by site, stock and waste per kitchen, and consolidated reporting that does not depend on somebody exporting spreadsheets. If your sites are genuinely identical, you need much less than this.
How long does it take?: An own-channel ordering and booking site is typically five to eight weeks. Table and cover management is longer, because the first week is spent on your actual floor plan and turn times rather than on screens - get those wrong and the rest is decoration.
Is it eligible for ΕΣΠΑ funding?: Software and equipment spend under Ψηφιακός Μετασχηματισμός ΜμΕ is subsidised at 50-60%, and restaurant businesses generally qualify. We are not ΕΣΠΑ consultants and will not advise on your application, but we will write the technical specification and costing your consultant needs.

The other four

Bring a bad Friday

The most useful first call is one evening that went wrong - the party you turned away, the tables that sat half empty, the no-shows at nine. Twenty minutes, and you will leave knowing whether software would have changed it.

Or write to hello@appcrafters.gr.