Your own booking system for a guesthouse is not meant to replace the portals - it is meant to let a guest who already knows your place book without a middleman. The portal keeps doing what it does well: bringing in new people. But a guest who is coming back for the second time, came on a friend’s recommendation or typed the name of your guesthouse into a search engine does not need a middleman any more. They need a calendar where they can see a free date and pay the deposit. If they do not find one, they go back to the portal and book there, and you pay a commission on a guest you earned yourself.
This article is not about how the property website looks, the photos or the description of the area - I covered that separately in the piece on a website for a hotel or guesthouse. Here I deal with the engine itself: what it has to do, how to keep it in line with Booking and Airbnb without selling the same night twice, and how to work out whether it will pay for itself at all.
A booking system for a guesthouse - your own panel instead of commissions
A booking system has two sides and both matter equally. The guest sees a calendar on your website, picks dates, a room type and the number of people, pays a deposit and gets a confirmation email. You see a panel: occupancy for the coming weeks, tomorrow’s arrivals, bookings waiting for confirmation and a button for entering the guest who just phoned.
The second side gets neglected more often, and it is the one that decides whether the system survives its first season. If entering a phone booking takes longer than writing it down in a notebook, a month later everyone is back to the notebook and the calendar on the website starts showing free rooms that do not exist.
In practice there are three ways to go:
- A subscription system - you embed a booking widget from an external service on your site. Quick to start, but you pay every month for years, and the look and the rules are whatever the provider planned for
- A WordPress plugin - the calendar lives inside your website, and so does guest data. Good when the rules are simple; I described the mechanics in the piece on bookings and rentals in WooCommerce
- Your own panel - written around your rules: packages, a minimum stay in high season, different prices for returning guests, your own documents. You pay once for the build and then only for upkeep
There is no single right answer. There is, however, one question that sorts the choice out: do your sales rules fit into the settings of an off-the-shelf tool, or do you work around them by hand every week?
What a guesthouse website with booking has to handle
A guest books directly when it is as easy with you as it is on the portal. The portal has set the bar, and nobody will put up with extra hassle just to save you a commission. From the point of view of the system itself that means a few hard requirements:
- Booking without creating an account - name, phone, email and payment. You can offer an account after the booking, never before
- Paying the deposit straight away - BLIK and instant bank transfer on a phone. A booking that is “pending email confirmation” is an invitation for the guest to click somewhere else in the meantime
- The calendar on your own domain - jumping to an unfamiliar address halfway through booking raises suspicion at exactly the moment the guest is typing in their details
- Cancellation terms in the confirmation - until when it is free and what happens to the deposit, written in the email and not only in the terms and conditions
- Working on a weak signal - people book accommodation on the road, so the calendar cannot take longer to load than the rest of the page
Each of these points looks obvious, yet an online booking system for a guesthouse that meets all of them at once is something I come across less often than I would like. The one missing most often is the second: payment goes by bank transfer “within three days” and the date hangs in limbo.
A booking system on a guesthouse, B&B or apartment website - what differs from a hotel
Most of the tools that come up when you search for a booking system for a B&B or software for running a guesthouse were built for hotels: a reception desk, a housekeeping rota, a till downstairs. A guesthouse with five rooms, a B&B with two or three apartments in one building has no reception. The owner answers the phone, greets the guests and issues the bill. So a system for a guesthouse has to do fewer things, but do them unattended: show the calendar, take the deposit, send the confirmation and show the morning’s arrivals on a phone.
The good news is that scale does not change the tool. The same calendar handles two rooms in a B&B and fifteen in a guesthouse; only the number of rules grows: room types, packages, minimum stays. That is why I advise against picking a system “to grow into” for a property that does not exist yet.
Beyond taking bookings for a guesthouse, three things are worth planning from the start, because owners ask me about them most often:
- An invoice or receipt for the booking - the guest’s details are already in the system, so the document should appear with one click rather than being retyped into accounting software. I described how to hook invoicing up to orders in the piece on automatic invoices in WooCommerce, and the mechanics are the same
- A season summary - how many nights sold directly, how many through the portals and how much commission went out. Without it you cannot tell whether your own system has paid for itself
- A second language for the calendar - guests from abroad mostly arrive through the portals, but when they come back they want to book with you in their own language
What a small property does not need: a reception module, a shift rota or an integrated ERP system. That is cost and complexity which makes sense in a hotel and only slows a B&B down.
One more thing: a booking system with an owner’s panel does not require a new website. Most often I add the calendar and the panel to the site that already stands, as part of extending an existing website with the features it lacks. Replacing the whole site is a separate decision and a separate budget.
Syncing with the portals without double bookings
This is where home-grown systems most often fall apart. A guesthouse sells the same rooms in three places at once: on its own website, on Booking and on Airbnb. Each of them has to know what the others have sold.
The simplest route is iCal calendars. Every portal lets you export a room’s occupancy calendar as a link and import a calendar from outside. Your system pulls the booked dates from the portals, and the portals pull the booked dates from your system. It works, it costs nothing and for a small property it is often enough.
It does, however, have two drawbacks you need to know about before you start:
- It is not instant - portals refresh external calendars periodically, not at the moment a booking is made. That leaves a window in which the same night can be sold in two places
- It carries occupancy only - no prices, no guest details, no number of people. You still set the rates on each channel separately
That double-booking window can be narrowed a lot. Your system blocks the date the moment a booking is placed, not once the payment is booked. Every room has its own calendar on every portal - one shared calendar for “double rooms” is a straight road to selling three rooms when two are free. And the last free nights at the peak of the season are worth selling through one channel only.
A larger property, with many room types and a lot of traffic from the portals, usually needs a channel manager. That is an intermediary service which connects to the portals through their programming interfaces and passes occupancy, rates and bookings across almost immediately. The portals do not open that kind of connection to every property individually, only to certified partners, so a small guesthouse plugs into them through exactly such a service. Your own panel can talk to a channel manager just as it would to a portal.
Whichever route you take, one rule applies: one calendar is the master. Everything, including phone bookings and regular guests, goes there first. A property where some bookings live in the portal’s extranet, some in the system and some in a notebook will sooner or later put two families in one room.
What it costs and when it pays back
The sum has two parts: what you pay once and what you pay every month.
Once, you pay for the build. Your own booking panel added to an existing website is, in my practice, a project with a written quote after a conversation, billed in stages. The figure grows with the number of room types, pricing rules and connections to other systems, not with the number of screens. How I price projects like this is laid out in the article on what a custom web application costs.
Every month, you pay for hosting, the payment provider’s fee on each deposit, and possibly a channel manager and technical maintenance. With a subscription system the build is cheaper or free, but the monthly fee runs for as long as the property operates.
Work out the payback on your own figures, not on someone else’s examples:
- Take the total commission from your portal statements for the last year - that is the amount you are fighting for
- Judge honestly what share of it comes from guests who could have booked with you - returning guests, referrals, people searching for your property by name. You will not move new guests off the portal, and they are not the point
- Add the yearly running costs of your own system - hosting, payments, a channel manager if you use one, and maintenance
- Compare that with the build cost - if the recovered commission minus the yearly costs covers the build in one or two seasons, the project stands up. If it takes five, stay with the simpler route
I showed the same way of counting, using an online store as the example, in the comparison of a subscription store and a self-hosted one. If you would like me to go through this calculation with you on your own data, tell me how you take bookings today - where guests come from, how many rooms you have and what your current tool is missing.
When your own panel does not pay off
I do not recommend a build to every property. If you have a handful of rooms, one price list per season and almost all guests come from the portals, a plugin or a subscription system will do the same job for a fraction of the cost. Bookings without the Booking commission only start once you have returning guests anyway, and that is a matter of time and service, not code.
Your own panel starts to make sense when:
- you sell packages - a stay with meals, a weekend with an activity, a stay with spa treatments - and an off-the-shelf tool cannot price them
- you have your own rules, such as a minimum stay only in the summer holidays or a different price for guests coming back for the third time
- you want guest data on your side, so you can invite people back after the season
- you need a connection to invoicing, accounting software or the restaurant system at the same property
Where to start
Before anyone writes a line of code, do three things. Write down where last season’s bookings came from, even roughly. Decide which calendar will be the master. And read your contract with the portal for clauses about prices on your own website - that is a legal matter, so what I write here is not legal advice, and any doubtful clauses are worth showing to a lawyer before you advertise a lower price on your own site.
Then start simple: a calendar on the website, an online deposit, sync through iCal. Add a channel manager and your own rules when the first season shows what is really missing.
Frequently asked questions
Can I take bookings without paying the Booking commission? Bookings made on your website do not go through the portal, so the portal takes no commission on them. Bookings made on the portal still carry a commission. Your own system does not abolish commission - it moves to you the guests who were looking for your property anyway.
Is iCal sync enough? For a small property with a few rooms it usually is, provided every room has its own calendar and your system blocks the date at the moment of booking. With many room types and heavy traffic from several portals the iCal delay starts to hurt, and that is when a channel manager is the better choice.
A deposit or an advance payment for online bookings? Under Polish law these are two different things, with different consequences when a stay is cancelled. Technically the system can handle either, but confirm the wording and the rules in your terms with a lawyer - this is not legal advice.
How long does it take to build your own booking panel? A first version with a calendar, a deposit, an owner’s panel and iCal sync is a project of a few weeks from the moment the scope is closed. It is best to start outside the season, so the system is tested on real bookings before the peak arrives.
Building an application, a panel or an integration rather than a website? I write B2B systems to order - backends, APIs, client panels, billing modules. Let’s talk about your project.