Industry

Travel & hospitality software: inventory, suppliers and the truth about availability

Systems that hold up when twelve suppliers disagree about what is available.

Travel is the hardest integration problem in ordinary commerce, and it is disguised as a simple one. A customer sees a room, a seat or a package with a price and an available badge. Behind that badge is a question no single system can answer: is this genuinely available right now, at that price, from a supplier who will honour it? Answering it means reconciling a property management system that owns the physical rooms, a channel manager pushing inventory to a dozen OTAs, bed banks and DMCs that resell the same rooms through their own contracts, a GDS speaking a protocol older than most of the people using it, and your own direct site — all of which believe they hold the truth, and none of which update at the same speed. Hospitality adds its own layer. A hotel is not selling a product; it is selling a perishable one. An unsold room tonight is revenue that cannot be recovered tomorrow, which is why rates move by the hour, why overbooking is a deliberate commercial strategy rather than a bug, and why every system in the chain has to cope with a price that was true when the page loaded and is not true when the customer clicks. We build the connective layer around all of that: booking engines that fail honestly rather than optimistically, supplier integrations that survive partners being slow or wrong, and the reconciliation and reporting that lets an operator see one consistent picture of their business instead of five contradictory ones.

Common challenges

What tends to go wrong

Multi-supplier aggregation. A single search may need to query a channel manager, two bed banks, a DMC contract, an airline consolidator and a car supplier — each with different latency, different response shapes, different failure modes, and different definitions of what "available" means. The slowest partner sets your page speed unless the architecture says otherwise, and one partner returning nonsense must not empty the whole results page.
Rate parity and dynamic pricing. Contractual parity obligations mean the price on your site and the price on an OTA have to stay in a defined relationship, while both move constantly. Static markup rules break the first time a supplier runs a flash promotion; the system has to reason about the rule, not just apply the last number it saw.
Availability that is never quite current. Inventory pushed to a dozen channels is stale in every one of them the moment a booking lands anywhere. Overbooking is expected within tolerances, so the design question is not preventing it but detecting it fast, resolving it gracefully, and never letting the same physical room be confirmed twice by two different systems.
The cancellation cascade. A single cancellation triggers a chain: release inventory, reverse supplier bookings, apply the correct policy from a contract that may differ per rate plan and per season, calculate a refund net of non-refundable components, process the payment reversal, adjust commission, and notify everyone. Getting any step wrong costs real money and produces a dispute months later.
Seasonality that is genuinely extreme. Traffic during a wedding season, a festival window or a fare sale can be twenty times an ordinary Tuesday, and it arrives within an hour. Systems sized for the average fail exactly when the year's revenue is being made.
Payments and settlement complexity. Multi-currency pricing, partial payments and deposits, pay-at-hotel versus prepaid, supplier settlement in a different cycle from customer collection, chargebacks against bookings already consumed, and commission reconciliation across agents and OTAs — all of which have to add up at month end.
Legacy protocols that will not be replaced. GDS and older supplier interfaces are not going away, do not offer test environments worth the name, and behave differently in production than in documentation. Anything built on them has to be defensive by default.

How we address it

What we build instead

Aggregation with per-supplier isolation. Every supplier gets its own adapter, its own timeout budget and its own circuit breaker. Searches fan out in parallel and return what has arrived when the budget expires, so a slow bed bank costs you its results rather than the entire page. A supplier failing repeatedly is taken out of rotation automatically and reported, rather than degrading every search silently.
A rate engine that models rules, not numbers. Markups, commissions, contracted nets, seasonal overrides and parity constraints are stored as rules and evaluated at quote time, with the resulting price snapshotted onto the booking. That snapshot is what makes a dispute answerable six months later: you can show exactly which rule produced which number on which day.
Booking as a saga, not a transaction. A multi-supplier booking cannot be one database transaction, so it is modelled as a sequence of steps with explicit compensation. If the hotel confirms and the transfer fails, the system releases the hotel rather than leaving a customer with half a holiday and an operator with a manual mess. Every step is idempotent, because suppliers retry and duplicate.
Availability treated as a cache with a confidence level. Inventory is pushed and pulled continuously, with the system distinguishing between what it believes is available and what has been confirmed. Confirmation happens at the last possible moment, and the interface tells the truth when it changes — a clear, immediate "this just went" beats a confident booking that fails at the supplier.
Cancellation policy as data. Policies are structured per rate plan and season, with the applicable terms captured onto the booking at the time of sale. Refund calculations, supplier reversals and commission adjustments then follow deterministically instead of being re-derived by a human under time pressure.
Built for the peak, not the average. Search results and static content are cached aggressively, expensive work is queued, and rate limits sit at the edge. Load testing targets last year's busiest hour, because that is the hour the system is actually for.
Reconciliation as a first-class module. Supplier statements, OTA commission reports, payment gateway settlements and your own bookings are matched automatically, with the exceptions surfaced for a human. Most travel operators do this in spreadsheets; it is the single highest-value thing we automate for them.

Outcomes

What typically improves

What changes in practice: search results stop being hostage to the slowest supplier, and a partner outage stops taking the site down with it. Failed bookings stop leaving orphaned supplier reservations that somebody discovers on a statement weeks later.
Rate changes propagate from one place rather than being repeated across channels by hand, and parity questions have an auditable answer. Cancellations resolve on policy rather than on judgement, which removes both the disputes and the evenings spent settling them.
And month-end reconciliation stops being a week of spreadsheet archaeology: what matched, matched automatically, and what did not is a short list of genuine exceptions with the evidence attached.

Frequently asked questions

Can you integrate with our channel manager or PMS?

Usually yes. The important part is being explicit about who owns availability and how large the reconciliation window is, because that window is where double-bookings live. Where the integration only supports periodic sync, the design has to account for it rather than pretend it is instant.

Can you integrate with our channel manager and PMS?

Usually — the common channel managers and most PMS vendors expose an API, and where they do not there is often a scheduled file exchange. The approach is the same regardless: treat the interface as unreliable, persist everything before processing, retry with backoff, and make failures visible rather than silent. The first step is a survey of what your systems actually expose, which is frequently different from the documentation.

How do you handle peak booking periods?

By separating search from commit. Search is read-heavy and tolerates caching, so it can be made very fast and scaled horizontally. Commit must be strictly consistent and is comparatively rare. Treating them as one problem is what produces systems that are both slow and occasionally wrong.

How do you handle a supplier being down during a search?

Each supplier has its own timeout budget and circuit breaker. A search fans out in parallel and returns whatever arrived within the budget, so one slow or failing partner costs you its results rather than the whole page. Repeated failures take a supplier out of rotation automatically and raise an alert, instead of quietly degrading every search.

Can we take direct bookings alongside the OTAs?

Yes, and it is usually the point — direct bookings avoid commission. The requirement is that direct inventory and OTA inventory draw on the same authoritative availability, otherwise you have simply added another channel that can double-book.

What happens when a booking half-succeeds?

The booking is modelled as a saga with explicit compensation for each step. If the hotel confirms and the transfer fails, the system releases the hotel automatically rather than leaving an orphaned reservation. Every step is idempotent because suppliers retry and duplicate — and a double-confirmed room is the most expensive bug in this domain.

Can you build a B2B agent portal as well as a consumer site?

Yes, and they usually share a core. The agent side needs credit limits, agent-specific net pricing, booking on behalf of travellers and white-labelling; the consumer side needs speed and clarity. Both read from the same inventory and rate engine, which is what keeps them consistent.

How do you deal with rate parity obligations?

By modelling the rule rather than the number. Parity constraints, contracted nets and markups are stored as rules and evaluated when a price is quoted, with the result snapshotted onto the booking. That gives you an auditable answer to any parity question months later — which is when they are usually asked.

Our peak is twenty times our average. Can the system cope?

That is the design target rather than an afterthought. Search and content are cached aggressively, expensive work is queued so a spike lengthens a queue instead of stopping the site, and rate limiting sits at the edge. We load-test against your actual busiest hour from last year, not a synthetic average.

Do you work with GDS and older supplier protocols?

Yes, defensively. Those interfaces rarely have usable test environments, so we build simulators to exercise the failure paths, persist every message before processing it, and route anything unparseable to a queue a human can inspect rather than letting it disappear into a log.

Can you automate our commission reconciliation?

This is often the highest-value single project in a travel business. Supplier statements, OTA commission reports and gateway settlements are matched against your bookings automatically, and only genuine exceptions reach a person — usually replacing several days of spreadsheet work each month.

Building for travel & hospitality?

Tell us how the operation runs today. We will tell you where software would actually help.

Start a project Talk to our team