To prevent overbooking when you sell through your website, by phone and via agencies, you need one thing, done properly: every channel must read and update the same availability, at the same moment. That means a single source of availability, a check that stops two simultaneous sales from taking the same seat, temporary holds with an expiry during payment, and clear rules for agency allocations and cancellations. Synchronising separate systems at intervals reduces the problem, but does not remove it.
Why overbooking happens
Overbooking, selling more places than you have, rarely comes from one person’s mistake. It comes from how sales are organised. Take an example scenario: an excursion with 20 seats. The website sells 5, an agency sells 8, the office sells 10 by phone. Looking at their own numbers, each of them did everything right. The total, though, is 23: three people too many, who now need to be moved or refunded, with all the hassle that follows.
The usual causes are few and recurring:
- each channel keeps its own count (the website, a spreadsheet for phone sales, emails with the agency);
- updates arrive late, at the end of the day or whenever someone remembers;
- two sales happen almost at the same time and nothing decides who came first;
- cancellations are not recorded everywhere, so seats stay “lost” or, worse, get resold twice.
The problem: separate availability across channels
As long as there are several sources, someone has to reconcile them. If a person does it, the system only works when that person is careful and available. If software synchronises them every so often, channels can sell the same seats between one sync and the next.
The common reaction is caution: holding back a few seats “just in case”. Overbooking drops, but you sell less than you could, and the underlying problem remains.
One authoritative availability source
The structural fix is a single booking engine that holds availability and through which every sale passes:
- the website books directly on the engine;
- phone and desk sales use an admin panel connected to the same engine, not a separate spreadsheet;
- agencies use a dedicated channel or connect via an API;
- partner websites use a widget that queries the same availability.
Manual bookings are where this most often breaks. They have to exist, because phone sales and exceptions will always be there, but they must draw on the same availability as the website. If staff can “add two more people” without going through the system, the single source is no longer single.
If you want a closer look at the different availability models (seats per departure, time slots, rentals by duration), I explain them in the article on how a booking engine works for tour operators, activities and rentals.
What happens when two customers book at once?
Even with a single source, two requests can arrive at the same instant for the last seat. If the system reads “1 available” for both and then confirms both, you are overbooked anyway. Two technical safeguards are needed.
Atomic checks
Checking availability and reducing it must happen as one operation: either all of it succeeds or none of it does. In practice this is done with database transactions and constraints, so only one of the two requests gets the seat and the other receives a clear message.
Temporary holds with an expiry
A few minutes pass between choosing a seat and paying. During that time the seat should be held for that customer, with an expiry. If payment succeeds, the hold becomes a booking; if the customer abandons checkout or the payment fails, the hold expires and the seat becomes available again.
The edge cases matter too: a payment provider that responds late, a user who clicks “pay” twice, a confirmation that arrives after the hold has expired. Each needs to be handled, or you end up with duplicate bookings or seats held for nobody.
Agency and partner sales
With agencies there are two main approaches:
| Model | How it works | Watch out for |
|---|---|---|
| Shared availability | The agency sees and books against the same availability as your website, in real time. | You need an agency channel or a reliable API connection. |
| Allocations (allotments) | A number of seats is reserved for the agency for a date or period. | Deciding when unsold seats are released back to the other channels. |
Allocations are useful when an agency needs guarantees, but they must be managed inside the system, with a release date, not agreed by email. Otherwise you are back to separate sources.
Cancellations and restoring availability
A cancellation should put seats back on sale at the right moment, and only once. The questions are practical. Is the seat released immediately or only after the refund? If the cancellation is partial (from four people to two), does the system return only the difference? Does a date change release the old date and take the new one in a single operation?
Without precise rules you drift in one of two wrong directions: seats that stay occupied by bookings that no longer exist, or seats released twice.
External suppliers and APIs
If you also sell third-party services, availability is not only yours. Connecting to the supplier via an API helps, but APIs alone do not prevent overbooking. What matters is the supplier’s guarantees (is their confirmation final or provisional?), response latency, rate limits and the booking and cancellation rules of their system.
So when an external service is part of the sale, it is worth confirming the booking with the supplier before treating it as closed, and planning what happens if the supplier says no. I cover this more broadly in the article on APIs and business software integration.
Monitoring and logs
Even a well-designed system needs watching. You need a log of every availability change (who, when, from which channel), alerts when a departure goes over capacity or a hold stays open too long, and an easy way to reconstruct the history of a booking. When something does not add up, what makes the difference is being able to answer “where did this booking come from?” quickly.
Lessons from a multichannel booking platform
For a tourism operator I built a multi-channel booking platform designed around exactly this principle: one booking engine with real-time availability shared across phone, agencies and website, online payments, a dedicated agency channel and an admin panel. The stack is Angular for the interfaces, NestJS for the backend and PostgreSQL for the data.
The starting point in a project like this is organisational rather than technical: deciding that every sale, phone sales included, goes through the same engine. Everything else, from temporary holds to cancellation rules, is built on top of that decision.
Frequently asked questions
Can I sell through several channels at once without overbooking?
Yes, if every channel reads and updates the same availability with atomic checks. No system makes the risk zero in every circumstance, but this removes the most common causes: separate counts and late updates.
Is synchronising bookings between different systems enough?
It helps, but between one sync and the next there is still a window in which two channels can sell the same seat. The scarcer and more in demand your seats are, the more that window matters.
Do APIs eliminate overbooking?
Not on their own. It depends on how the supplier confirms bookings, how quickly it responds and what limits it applies.
Where to start
If you sell across several channels, let’s assess together how to share availability and bookings. You can see how I build booking engines or tell me about your case; the initial analysis is free.