Plan a booking website around the decisions that matter

The calendar is the easy part of a booking website. The difficult parts are decisions that have to be made before anyone chooses a plugin: how a booking becomes confirmed, which system is allowed to say a date is free, how deposits and cancellations work, and what happens in the office after the guest clicks the button.

I have spent a large part of my career on those decisions. I built and maintained the PHP booking engine behind Thailand-villas.com from 2001 until the platform was sold in 2022, and from 2011 klik.villas, a property management system for villa rentals with integrations to Booking.com, Agoda, and Rentals United. This guide is organized around the questions those systems forced us to answer.

Enquiry or confirmed booking?

The first decision shapes everything else: does the visitor send a request that someone confirms, or does the website confirm the booking immediately?

An enquiry flow is forgiving. Availability can be checked by a person, special requests can be discussed, and a price can be adjusted before anything is promised. The cost is speed. The guest waits, compares other options while waiting, and may book elsewhere before the reply arrives.

Instant confirmation removes that wait but moves every rule into the system. Minimum stays, changeover days, seasonal prices, extra guests, and blocked dates all have to be correct in the data, because nobody checks them before the guest receives a confirmation.

Thailand-villas.com worked on enquiries for most of its life. A guest sent a request, we forwarded it to the villa owner, and passed the owner’s answer back to the guest. It was slow, but until we could see the owners’ bookings ourselves, only the owner could confirm the dates. Once the owners’ bookings were visible in klik.villas, that loop could be automated.

Many businesses end up with both: instant booking where the rules are simple and the data is reliable, and an enquiry for everything else. That is a valid design, as long as the website makes it clear which one the visitor is using and what happens next.

Decide which system owns availability

As soon as a property or service is sold in more than one place, availability needs one owner. If your website, a channel manager, and two booking platforms can all accept a booking for the same dates, one of them has to be the source of truth, and the others have to follow it.

klik.villas dealt with this directly. It connected reservations to external channels such as Booking.com, Agoda, and Rentals United, and those integrations had to handle data formats and availability rules that changed on the other side. Receiving a booking is not enough. The system also needs to block the dates everywhere else quickly, and to notice when a channel did not accept the update.

Before building, write down:

• Where availability is edited, and by whom
• Which channels receive updates, and how quickly
• What happens when an update fails or arrives twice
• Who resolves a conflict when two bookings claim the same dates

Calendars kept in other tools are the weak point. Many of the properties in klik.villas shared their availability as iCalendar feeds, which are only fetched periodically, so between syncs a date could look free after it had been booked elsewhere. We also found syncs that replaced existing entries instead of merging with them, and added a sync log and a fallback calendar to trace and recover from that. If a channel offers a real API, prefer it; if you have to rely on iCal, sync often and log every change.

The technical patterns behind that list, including idempotency, retries, and reconciliation, are covered in reliable API integrations. The planning decision comes first: one owner, written down.

Deposits, balances, and cancellations are part of the booking

A booking is rarely a single payment. It may be a deposit now, a balance before arrival, a security deposit, a refund after cancellation, or a change of dates that moves money from one stay to another. Each of those is a state the booking can be in, and the system has to know which state it is in.

Define the states in plain language before choosing tools. For example: requested, confirmed with deposit, paid in full, cancelled with refund, cancelled without refund. Then decide which events move a booking from one state to the next, and which of them are automatic.

For the payment itself, use an established payment provider rather than handling card details on the website. The website’s job is to record what the provider reports and to act on it reliably, including when the provider’s confirmation arrives late or more than once.

The payment method will probably change during the life of the website. Guests on Thailand-villas.com mostly paid by bank transfer in the early years, because there were few online payment options for that kind of business; after the 2016 merger with Rentivo, payments moved to VacayPay. Keep the booking states independent of the payment method, so a change of provider does not mean rebuilding the booking flow.

The booking does not end at confirmation

A booking system is also an administration system. Once a stay is confirmed, someone needs to prepare it, report on it, and account for it.

klik.villas grew out of exactly that gap. Villa rental businesses were handling reservations, rental income, expenses, maintenance, and owner reporting in spreadsheets, which meant duplicated work and a high risk of inconsistent data. The system brought those tasks into one place, built around how villa rentals actually operate rather than around a hotel system adapted for another kind of business.

Even a much smaller booking website benefits from asking the same questions early:

• Who needs to know about a new booking, and how are they told?
• What does staff need to see on arrival day?
• Which numbers does the owner or accountant need each month?
• What is still being copied by hand between tools?

Anything still copied by hand after launch is a place where the booking data will eventually disagree with itself.

Booking pages have to be found

A booking engine is only useful if the right visitors reach it. On Thailand-villas.com the booking engine did not work as an isolated feature: property information, destination content, navigation, internal links, and the booking step had to work together, because the site competed for visibility with much larger booking platforms.

That structure also had to change as search changed. After Google’s Panda update in 2011 we stopped duplicating villa content across the destination sites, and later we consolidated those sites into one domain with 301 redirects, following the steps in the website migration SEO checklist. A booking website that depends on search traffic should expect to revisit its page structure when search changes.

That argues for a repeatable page structure, so each new property, service, or location is added the same way:

• Overview and essential details
• Availability or enquiry step
• Prices, or an honest explanation of how the price is set
• Location and access information
• Deposit and cancellation terms
• Related properties, services, or destinations
• A contact fallback for questions the page does not answer

A consistent structure keeps the website easier to extend and avoids a slow drift towards thin, near-identical pages. For the parts of a listing visitors use to narrow their choice, see website search and filter improvements.

Hosted tool or custom booking engine

A hosted booking tool or plugin is often the right answer. If the business books appointments or a small number of units, with simple rules and one sales channel, a good hosted tool will be cheaper and more reliable than custom code.

Custom work becomes worth considering when the booking model does not fit the tool’s assumptions: unusual availability rules, several channels that must stay in sync, deposits and owner reporting that follow the business’s own terms, or booking data that has to flow into administration and reporting. klik.villas was built because villa rental operations needed a data model of their own rather than an adapted hotel system.

Between those two there is often a middle path: a hosted engine for the booking itself, with custom integration work around it for the website, notifications, and reporting.

Write the booking process down first

Before comparing tools, describe one real booking from first contact to final payment and the report at the end of the month, including the awkward cases: a cancellation, a change of dates, a payment that arrives late. That description will decide most of the technical plan for you.

If you already take bookings and the flow feels fragile, or you are planning one and want a second opinion on the model, send me the process as it works today.