Booking system for tours and transfers: what it actually needs

Most small tourism businesses start with a contact form and WhatsApp. That is not a bad call: while the volume is low it is faster and more personal. The trouble starts in peak season, when four guests write about the same departure within the same hour and you are out at sea with no signal. This post goes through what a booking system has to do to actually take that job off you, instead of only adding one more screen to watch.

A form is not a booking

A contact form sends a message and its job ends there. The slot is still open until somebody writes it down somewhere by hand. If a second enquiry lands in the meantime, both guests think they have a place, and you have a problem that gets solved with an apology.

A booking system works the other way round: the moment a booking is confirmed the seat is taken and nobody else can have it. Everything else (confirmation emails, reminders, tomorrow's list) follows from that one thing. If a system does not do it reliably, the rest does not help.

Capacity is the hard part

On paper it is simple: the boat takes twelve people, so sell twelve seats. In practice it almost never works out that way.

• The same boat runs the morning and the afternoon tour, so departures must not overlap with the time it gets back.
• Some departures sell as a group tour priced per person, others as a private charter for the whole boat, and it is the same boat.
• More than one vessel means a booking is assigned to whichever vessel is free, not to a fixed one.
• The season changes the schedule: two departures in June, four in August, none in October.

With Navy Blue and Blue Cave Tours that was the interesting part: two separate brands with their own sites, but one shared fleet. A booking on one has to take the seat on the other, otherwise the same crew gets sold twice for the same departure. No off-the-shelf system does that on its own.

With SeaExplore, three different flows (group tour, private charter and taxi boat transfer) share one calendar, and each has its own rules for capacity and price.

Charge now or confirm by hand

This is a business decision, not a technical one, and both options make sense. If you take card payments, the decision brings paperwork with it, which we listed in what you need for an online shop in Croatia.

Charging upfront all but removes no-shows and you know the departure is genuinely sold. The cost of it is that some guests drop out at the payment step, especially the ones who have only just started looking. It makes the most sense for popular tours with limited capacity, where a no-show really does cost you a seat you could have sold.

Booking without payment has a higher completion rate, but it needs somebody to confirm and it means living with cancellations. For transfers, where a guest often books weeks ahead and then changes flights, it is usually the more practical option. With Dubrovnik4U Transfers the booking goes through without payment, and the confirmation goes out by email and WhatsApp, because most changes get agreed by message anyway.

With Trogir Tours it runs the other way: the ticket is paid by card immediately, because the tours are sold to guests who are in town for a few days and decide on the spot.

Your own channel and commissions

The big platforms bring guests, but they take a percentage of every booking, and over a year that is not small. It does not follow that you should drop them: it follows that your own site has to be at least as easy to book on, or the guest goes there anyway. The same logic applies to social media, which we wrote about in a website or just Instagram.

In practice, if your price on your own site is the same or better, and the booking takes the same number of taps, a share of the guests who already know you will come direct. That share is pure margin. A guest who finds you on a platform the first time and books direct the second is the most profitable guest there is.

Phones, and the guest who does not speak the language

Nearly every tour booking happens on a phone, often on a poor connection and often in a language that is not Croatian. That sets three requirements which are easy to overlook.

The site has to open fast and on a weak signal. The booking has to fit into a few steps without typing out long details. And there has to be a way back one step: a guest who picks a date and then changes their mind must not end up locked in.

On top of that, the price has to be visible before the guest starts entering details. Hiding the price until the last step is the fastest way to lose a booking.

What to ask the developer

If you are commissioning a booking system, these are the questions that need a clear answer before you sign.

• How the system stops the same departure being sold twice
• Whether the same resource can be sold both per person and as a whole charter
• How the schedule changes from month to month without calling a developer
• What happens when a payment fails in the middle of a booking
• Who sees tomorrow's list, and on which device
• Whether a booking can be cancelled and refunded without working out the numbers by hand

If the answers come back vague, the system probably does not exist in the developer's head yet. How we do it shows best through the case studies, and the approach itself is described on the web development page. Why a system like this rarely fits into a ready-made platform we set out in WordPress or custom code.