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.
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 allocator, choosing a table
Pick a party size and a time, and it assigns the tightest table that fits - then tells you how many seats that left empty. 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 actually act on. Then hold the two-tops for walk-ins and watch what that policy costs.
Party size
Table 1
2 seats
Table 2
2 seats
Table 3
4 seats
Table 4
4 seats
Table 5
6 seats
Table 6
8 seats
Booking time
Click a booking to cancel it.
Pick a party size, then a time.
Real allocation, running in your browser - turn times, tightest fit, table combining, seats wasted, all genuinely computed. Nothing is sent anywhere. Six tables and one service is a simplification of a real floor; the logic is not.
Why a group, and why now
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 happens above a certain size.
- 50–60%
- subsidy on software and equipment under ΕΣΠΑ Ψηφιακός Μετασχηματισμός ΜμΕ, from a €135m budget, which restaurant businesses qualify for Source: espa.gr
- myDATA
- electronic invoicing through a certified provider is an operating obligation, so an ordering channel that cannot issue a compliant receipt is not finished Source: EpsilonNet, myDATA software
- 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 Source: YFO, SEO in Greece 2026
What we actually build
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
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 we measure
Covers is the number a P&L reports and the wrong one to schedule against. These four are about seats and time, which is what the floor runs on.
- 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.
Reference builds
Things we built ourselves to show the approach. Not client work - where a real engagement is publishable it says so, with a name on it.
- Restaurant group
Scheduling against tables instead of covers
A reference build: a table allocator that assigns each booking to the tightest table that fits, combines adjacent tables when it has to, and reports the seats a decision left empty.
Next.js · TypeScript · Postgres · Viber
- Restaurant group
The repeat customer who should not arrive via a platform
A reference build: 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
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.
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. Forty-five minutes, and you will leave knowing whether software would have changed it.
Or write to hello@appcrafters.gr.