New: Try our free Website Audit tool. Run your free audit →Run it free →

Hospitality

The booking you pay commission on was already yours.

Somebody searched your name, found you on a platform instead of your own site, and booked through it. You paid for a customer who had already chosen you. We build websites for restaurants, hotels, bars and venues that take that booking directly — and handle the enquiries a booking widget was never designed for.

Venue websitesRebuildsDirect bookingMenus & eventsLocal searchEnquiry handlingAutomationMaintenance
Illustrative concept
yourvenue.co.uk/book
Book a table
Party sizeSelected by guest Date & sittingFrom your diary OccasionOptional Access or dietary notesFree text
Booked on your own site Confirm
No commission, and the guest’s details are yours to keep

The leak

Your website is the cheapest booking channel you own, and usually the worst one.

In short

Aggregators earn their commission on discovery — finding you a guest who did not know you existed. They also collect the commission on the guest who searched for you by name, because your own site made booking harder than theirs did.

Hospitality is unusual in that the platform is not really a competitor. It is a channel, and a useful one. The problem is that most venue websites are so far behind the platform experience that they send their own traffic there by default — including the traffic that arrived already convinced.

Meanwhile the things a platform genuinely cannot do — a private-dining enquiry, a function, a large party, a supplier question — land in an inbox and wait.

What we usually find
  • The menu is a PDF. Which does not open properly on a phone, cannot be read by a search engine, and is eighteen months out of date.
  • Opening hours in three places, disagreeing. On the site, on the platform, and on the Google listing — each edited at a different time.
  • “Book now” jumps straight to a platform. Handing over a guest who was already on your site, and a commission with them.
  • Functions and private hire have no route. The highest-value enquiry on the site, reduced to a generic contact form.
  • Photography that is not the venue. Stock images of a different room, which guests notice the moment they walk in.
  • Nothing about access, parking or dietary provision. Practical questions that decide bookings, answered nowhere.
  • No mailing list. Every guest who ever booked, and no way to tell them about the Christmas menu without paying somebody.
  • Events buried or missing. Quiz nights, tastings, seasonal menus — the reason for a repeat visit, with nowhere to live.

What we build

A site that takes the booking rather than passing it on

Building and rebuilding venue websites is the work. The rest follows from it, because a hospitality site that cannot hold a booking or answer a function enquiry is an expensive menu.

Primary

Venue websites

Built so the obvious next action is booking with you: readable menus that are actual pages, hours that are correct everywhere, real photographs of your rooms, and the practical answers guests need before they commit.

  • Menus as pages
  • Direct booking
  • Real photography
  • Mobile-first
Primary

Website rebuilds

Dated or platform-dependent sites rebuilt properly, keeping the domain and whatever local visibility exists, and spending the budget on the booking path rather than a new set of fonts.

  • Address preservation
  • Speed
  • Booking path
  • Accessibility
Bookings

Direct booking & enquiry routes

Your booking system embedded properly rather than linked away to, plus separate routes for the things it cannot take — functions, private dining, large parties, group enquiries.

  • Embedded booking
  • Function enquiries
  • Private hire
  • Group bookings
Content

Menus, events & seasons

A structure the team can update themselves on a Tuesday morning — menus that change, events that come and go, and a seasonal offer that does not need a developer to publish.

  • Menu management
  • Events
  • Seasonal offers
  • Self-service editing
Local

Local & “near me” search

Structure and structured data so the site, the map listing and the platform profile agree with each other — and so a search for what you serve, near where you are, has somewhere real to land.

  • Location structure
  • Structured data
  • Hours consistency
  • Menu indexing
Retention

Keeping the guest afterwards

A mailing list that actually gets used, a route back for the guests you already have, and the groundwork for telling them about the next thing without paying a platform to do it.

  • Guest list
  • Seasonal sends
  • Review requests
  • Return visits

Elsewhere on the site — designing a new site, rebuilding an old one, connecting the operation, and keeping it current.

Direct vs platform

Keep the platform. Stop paying it for the guests it did not find you.

This is not an argument for switching the aggregators off. They reach people who have never heard of you, and that is worth a commission. The argument is about the guest who typed your name.

Via a platform

A booking you paid for

  • A commission on every cover, including repeat guests
  • The guest’s details belong to the platform, not to you
  • You are shown beside your competitors at the point of choosing
  • Rates and terms are theirs to change
  • No route for a function, a large party or a private hire
vs
On your own site

A booking you keep

  • No per-cover commission on a guest who already chose you
  • Their details are yours, so you can invite them back
  • Nobody else is on the page at the moment of decision
  • You set the terms, the deposit rules and the cancellation policy
  • Functions and private hire get a proper enquiry route
What this is worth depends entirely on your commission rate and your mix.

We are not going to put a percentage on it. What the shift is worth to your venue is arithmetic only you can do, from your own platform statements and your own cover numbers — and we would rather you did that sum than took a figure from an agency website. What we can do is build the site so the direct route is genuinely the easier one.

What the site can handle

The bookings a widget takes, and the enquiries it cannot.

A table for two on Friday is a form submission. A christening lunch for forty with a dietary list, a drinks reception and a room hire fee is a conversation — and it is worth several hundred times more. Both need somewhere to go.

Enquiries, by where they have got to Illustrative concept — statuses only, no figures
New booking
Table reservationParty size and sitting capturedWebsite
Function enquiryDate, guest count, room preferenceWebsite
Confirmed
Private diningDeposit taken, menu agreedPhone
Set menu, large partyPre-order sent to kitchenWebsite
Awaiting response
Drinks receptionQuote issued, waiting on the clientEmail
Accessibility questionAnswered, holding the dateWebsite
Follow-up due
Christmas enquiryQuiet for a week — nudge scheduledWebsite
Corporate bookingInvoice details outstandingReferral

A concept sketch of how enquiries can be tracked once the website records them rather than emailing them. There are deliberately no counts, covers, rates or percentages anywhere on it — those would be your numbers, not ours, and we are not going to invent a set to decorate a web page with.

  • Table availability, where you want itYour diary or booking system embedded in the page rather than linked away to, so the guest never leaves your site to complete the thing they came to do.
  • Enquiry source, recordedWebsite, phone, referral, walk-in. Not to produce a dashboard, but so that in six months you can tell which channel is actually worth what you pay for it.
  • Automatic acknowledgementBecause function enquiries arrive at nine on a Sunday evening and go to whoever replies first, exactly like every other enquiry-led business.
  • Follow-up when it goes quietMost function enquiries stall somewhere. A scheduled nudge is the cheapest revenue in hospitality and almost nobody does it.

Structure

Menus, events and functions each need a real page.

A PDF menu cannot be read by a search engine, does not work properly on a phone, and nobody updates it. The single highest-return change on most hospitality sites is turning the menu into pages.

  • /Home
  • /menus/Actual pages, never a PDF
    • /menus/dinner/Readable, indexable, editable by you
    • /menus/sunday-lunch/Its own audience and its own search
    • /menus/…/Breakfast, bar, tasting, seasonal — as applicable
  • /functions/The highest-value enquiry on the site
    • /functions/<type>/Weddings, corporate, private dining, wakes
  • /events/The reason to come back
  • /visit/Parking, access, dietary provision, finding you
  • /book/Your booking system, on your own page

Illustrative only. These routes are indicative — a single-site restaurant, a hotel with several outlets and a wedding venue need very different maps. Naming and depth are agreed jointly before design begins.

The structural point is that a search for “Sunday lunch near me” and a search for “wedding venue” are different intents with different budgets, and neither is served by a homepage carousel. Each needs somewhere to land that answers the thing that was actually asked.

  • The menu is content, not an attachmentDishes as text on a page can be found, read aloud, priced, updated and indexed. A PDF can do none of those, and it is the most common single failure we see in this sector.
  • Functions deserve more than a formRoom capacities, layouts, minimum spends, what is included, photographs of the room actually set up. It carries the margin, and on most venue sites it is the flimsiest page there is.
  • Practical information convertsParking, step-free access, allergen handling, how far from the station. Unglamorous, and frequently the thing that decides whether a group books you or somebody else.

Enquiry to table

From a search to a confirmed booking, without anybody re-typing it.

Six steps between somebody finding you and sitting down. The site can carry more of them than most venues ask it to.

1Found on a real pageA menu, an event or a function page that answers the specific thing searched for.
2Practical questions answeredHours, access, parking, dietary provision — before they have to ask.
3Books or enquires on siteYour diary for a table; a proper enquiry route for anything larger.
4Acknowledged immediatelyConfirming it arrived and what happens next, whatever time it was sent.
5Reaches the right personFunctions to the events manager, tables to the diary, suppliers elsewhere.
6Recorded and followed upWith a status and an owner, so a stalled enquiry gets a nudge instead of being forgotten.
Automation belongs in the dull parts.

Acknowledging an enquiry, routing it, and chasing one that has gone quiet. Not writing to guests pretending to be a person, and not anything you could not explain to a guest if they asked. If a step is worth automating, somebody on the floor should be able to describe it in one sentence.

More on the operational side — business automation and AI integrations.

Website rebuilds

You do not need a new brand. You need the booking path to work.

Nearly every venue site we are shown has assets worth preserving: a domain with some age on it, photography somebody paid properly for, a name already being typed into search. The task is repairing whatever pushes bookings onto a platform, and touching nothing else.

  • KeptYour domain and any URLs pulling traffic, the ratings and map listing, photography that still works, and the existing brand unless changing it is part of the brief.
  • What gets replacedPDF menus, the booking button that leaves your site, the missing function route, the layout that fights a phone, and page speed measured on mobile data rather than the office wi-fi.
  • AddedAccessibility raised to standard, the practical visit detail guests keep asking for, a guest list that is genuinely wired up, and analytics set up so the following decision rests on evidence.

Secondary capability

When the function diary is a paper book, something has to give.

Plenty of venues run functions from a hardback diary and a shelf of printed sheets, and for one room that genuinely works. Given a genuine commercial argument, the absent piece can be built — once the site is right, never ahead of it.

Function pipelinesProvisional date holdsPre-ordersAllergen and dietary listsDepositsRun sheetsSupplier schedulingTeam views
Look for a product first. Commission it only if the arithmetic holds up.

There is capable booking, EPOS and event-management software aimed at hospitality; where one of those fits how you operate, expect a recommendation to buy it rather than a quote to recreate it. We do not replace till systems, payment terminals or reservation platforms. Building to order makes sense purely when a real operational shortfall has no product available to close it.

Where that is the requirement — CRM & business systems, or something purpose-built for the trade.

Who this is for

Venues we build for

What actually gets built shifts a great deal across this list. Not everything above fits each one, and establishing which parts apply is most of the opening conversation.

RestaurantsRestaurants & BistrosCovers, menus and Sunday service. Direct booking and a menu that is genuinely readable do most of the work here.
PubsPubs & BarsEvents, food service and function rooms, where the repeat visit matters more than the first one.
HotelsHotels & InnsRooms, dining and functions competing for attention, with the commission question sharpest of all.
VenuesWedding & Event VenuesA single enquiry can be worth a month of covers. Photography, capacities and a proper enquiry route carry the page.
CafésCafés & Coffee ShopsFound on a map, judged on photographs and hours. Small sites where getting the basics exactly right is the whole job.
GroupsMulti-Site GroupsSeveral venues under one brand, where each site needs its own hours, menu and diary without four separate websites.
We build the technology, not the hospitality.

Central Systems builds technology. What that means here is websites and operational software for hospitality businesses, built and then maintained. We do not operate venues, handle food safety, allergen compliance or licensing, and we do not advise on any of them. Menus, allergen information, prices, hours and terms come from you, are published exactly as given, and remain your responsibility.

Straight answers

Questions venues ask us

Should we drop the booking platforms?
Almost certainly not. They find you guests who had never heard of you, and that is worth paying for. What is not worth paying for is commission on somebody who searched your name and then could not work out how to book on your own site. The aim is to win that second group back, not to switch the first one off.
Can you connect our existing booking system?
Usually. Most reservation systems publish an embed or a widget, and where one exists we put it on your page rather than linking away to theirs. Some are more restrictive than others and a few are contractually awkward. Whatever yours permits gets established during pricing, well before any work begins.
Our menu changes constantly. Will we need a developer every time?
No, and if you would we have built it wrong. Menus, events and seasonal offers are built so somebody on your team can change a dish or a price in a couple of minutes without touching a layout. That is the entire reason for moving off PDFs.
Can you show how much we would save on commission?
Not honestly, no — not before we have seen your platform statements and your own booking mix, and even then it would be your arithmetic rather than a figure from us. Any agency quoting you a percentage saving before looking at your numbers has invented it. We would rather build the thing and let you measure it.
Could you rework the current site instead of replacing it?
Most of the time, and it is generally the smarter route. Reworking preserves the domain, the ratings and whatever local footing exists, putting the money into menus, the route to booking and the function enquiry instead. We look over what you have and tell you candidly which way to go.
What should we budget, and how long will it run?
It turns on how many menus, outlets and function spaces the structure carries and how far the booking path goes. Price comes from a written scope both sides have settled; nothing gets guessed at during an introductory call. Allow somewhere around six to ten weeks from sign-off to going live — and it is normally the photography that delays it, not the development.

Next step

Make your own website the easiest place to book you.

Replacing something tired, pulling more bookings through your own site, or at last giving functions a page worthy of them — we can build towards wherever the venue is heading. Tell us how bookings reach you today and which of them you are paying for twice.

First conversation, no charge. Nothing becomes payable until a written price is settled.