Building a restaurant website with online booking

The calculation nobody runs

A booking platform brings two very different things, and charges the same price for both. It brings new customers who did not know you: that is acquisition, and its cost should be judged as such. And it also takes bookings from customers who were searching for you by name, had already seen you, or had already eaten with you: for those, you are paying twice.

The calculation takes ten minutes with your dashboard open, and needs four pieces of information.

• The number of covers booked through the platform in a representative month.
• The share of those covers who already knew you. Many platforms distinguish new from returning customers; otherwise your front-of-house team has a reliable estimate.
• The unit commission you actually pay, or the subscription divided by the number of covers.
• The annual cost of a built-in engine: the initial investment amortised, plus running costs.

Multiplying the first two by the third gives what you pay each month for bookings your own website would have taken. That amount, and only that amount, is what should be compared with the cost of a built-in engine.

In many establishments that calculation makes the project pay for itself within months. In others, particularly those drawing most of their custom from the platform, it shows that changing nothing is the better call. Both answers are useful, and only the calculation tells them apart.

The configuration that works: both

The reasoning above almost never leads to leaving the platforms. It leads to no longer handing them what they do not bring you.

Keep the platform as an acquisition channel, with its own budget and indicators. Recover on your site the bookings from customers who already know you: those typing your name, those coming from the link on your business listing, those returning.

The shift happens by itself provided your own booking flow is better, or at least as simple. That is a matter of journey, not communication: a visible button on every page, three fields, immediate confirmation.

One last effect is worth knowing: customers who book on your site are yours, in the sense that you can tell them about a seasonal menu or a closure. Those who book elsewhere belong to the platform, including when they have known you for ten years.

What a customer looks for, in order

The behaviour is well known and remarkably stable. A visitor is looking for four things, in this order: opening hours, the menu, the ability to book, and the address.

They are often looking from a phone, sometimes while walking, regularly outside service hours. A restaurant website is therefore judged first on its speed and on the legibility of those four items, not on its aesthetics.

The rest, the story of the house, photos of the team, the gallery of dishes, matters, but comes afterwards. A beautiful site that forces you to download a PDF menu loses a share of its visitors before the third second.

A booking engine is not a form

The difference is operational: a form sends a message, an engine handles a real constraint, your seats at a given moment, under your rules.

• The floor plan and capacities: how many covers, across which tables, and which can be combined.
• Services and slots: accepted arrival times, the average length of a meal, the number of sittings.
• Exception rules: closing days, private hire, large parties that warrant a phone call.
• Immediate confirmation, and a reminder the day before.

That last point is the most profitable on the list, and the cheapest to set up. A booked table that stays empty is a straight loss, frequent on bookings made several days ahead. A reminder sent the day before, with a link to confirm or cancel in one tap, reduces it measurably: the customer who will not come cancels, because cancelling takes less effort than doing nothing. The table frees up, and it can be filled.

The other blocks, by usefulness

Four features come up regularly and connect naturally to the same set.

• A menu managed from an admin area. Changing a dish or a price should take thirty seconds, with no supplier involved. Without that, the site menu goes stale in three weeks, and it is customers' most frequent complaint.
• Takeaway ordering, with payment and a collection slot, as soon as a meaningful share of activity happens outside the dining room.
• Events and private hire, with a form that asks the right questions up front and saves four rounds of messages.
• Gift vouchers, sold online and redeemed in the restaurant, particularly at the end of the year.

A fifth block is not part of the site but deserves mention: the business listing on search engines and maps. Accurate hours, recent photos and a direct booking link there often produce more visits than the website itself.

Timelines, budget and build order

A site with a manageable menu and online booking goes live in one week and sits on average between 2,000 and 8,000 euros. Adding takeaway ordering with payment, gift vouchers or a waiting list takes the project beyond that, depending on how many features and sites are involved.

On top comes a modest running cost: hosting, domain name, sending confirmation and reminder messages. That is the figure that enters the switch-over calculation, and it stays well below commissions on the same volume.

Start with booking and the manageable menu. Those are the two features used every day, and they represent a fraction of the budget of a complete project. Go live, watch for a month, then decide what comes next from what you observe: if private hire requests clog the mailbox, add the form; if takeaway grows, add online ordering.

If you want to run the calculation on your own establishment, three figures are enough to start: your covers booked through platforms in a month, the share of customers who already knew you, and the commission you actually pay.