Perishable inventory
Unsold capacity has no residual value. Every pricing and distribution decision is made against a clock.
Travel & hospitality
Inventory that expires at midnight.
A hotel room unsold tonight is not stock, it is a loss that has already happened. Travel systems manage perishable inventory across channels that each believe they are authoritative, at prices that move by the hour, for customers who compare six options in one tab and abandon the booking if anything hesitates. Travel software development is mostly the work of keeping one availability figure true in all of those places at once.
The question to answer first
“Can you keep availability truthful across every channel we sell on?”
Zero
Double-bookings we design to allow, at any volume
The pressure
Four forces acting on perishable inventory.
Channel conflict
Direct, OTA, GDS and partners all want inventory, and each has a different latency and a different idea of what is available.
Seasonal extremes
The infrastructure that carries a quiet Tuesday has to carry the morning a sale opens, and those differ by an order of magnitude.
Trust decides the sale
Booking involves money, dates and travel documents. Any hesitation in the flow is read as risk and costs the conversion.
The work
What we build for operators and properties
Four systems, all of which are ultimately about one number being true in several places at once.
Booking engines
Search, availability, pricing and payment in a flow fast enough that nobody reconsiders halfway through.
Channel management
One truthful availability position pushed to every channel, with the reconciliation that keeps it truthful.
Revenue tooling
Rates and restrictions that respond to demand, with the guardrails that stop an automated rule doing something indefensible.
Guest experience platforms
Pre-arrival, on-property and post-stay, which is where repeat business is actually made.
Brilliant System designers worked with us to create an easy to use interface. Then their developers made sure the data was in place. They worked with us through multiple iterations and were very responsive to updates we requested.
Read the full review
The availability test
Six ways a booking system oversells, and what stops each.
Every one of these has happened to a real property. None of them is exotic. They are what happens when availability is a number that several systems believe they own.
| The failure | How it happens | What stops it |
|---|---|---|
| Double sell | Two channels read availability, both write a booking, neither saw the other. | A single authority for availability with a conditional write. The second booking fails loudly rather than succeeding quietly. |
| Ghost hold | A checkout is abandoned and the inventory is never released. | Holds carry an expiry from the moment they are created, enforced by the system rather than a cleanup job. |
| Stale channel | An OTA connection drops and keeps selling yesterday’s position. | Heartbeat on every channel, and a property-visible alarm the moment one goes quiet. |
| Rate mismatch | The price shown at search is not the price at payment. | The quote is a signed artefact with a lifetime. If it expires the customer is re-quoted, never silently charged a different figure. |
| Overbook by policy, silently | A deliberate overbooking rule fires without anyone being told. | Deliberate overbooking is a visible setting with an owner and an alert, not an emergent behaviour. |
| Timezone slip | A midnight cut-off resolves differently for the property and the platform. | Store instants, render in property-local time, and make the cut-off boundary explicit in the model. |
Non-negotiable
Four invariants in a booking system
- Availability is a hard invariant
- Overbooking is a business decision made deliberately, never an accident produced by a race condition.
- Money and dates together
- Payment, cancellation policy and date logic have to be modelled as one thing. Splitting them is where refund disputes come from.
- Latency is conversion
- Search response time maps directly to bookings. It is a commercial metric, not a technical one.
- Fail visibly to staff
- When a channel connection drops, the property must know before a guest arrives at a desk to find out.
Where AI actually lands
Four places it earns its cost, and one line we do not cross.
Worth doing
- Demand forecasting and dynamic pricing, inside limits a revenue manager sets and can see.
- Guest messaging across languages and time zones, handling the routine and escalating the rest.
- Itinerary and package assembly from components that were never designed to be combined.
- Review analysis at a volume that makes operational patterns visible rather than anecdotal.
Where we stop
Unbounded automated pricing. Price is a public statement about your brand, and a loop with no floor will eventually make one you would not have made.
Evidence
We have no travel or hospitality case study to publish yet. Visit Tampa Bay has published a review of our work, quoted above, and this page sets out how we would approach a booking system.
How we deliver it
The services this work draws on.
Web App Development
Fast, accessible applications that behave correctly on a bad connection.
Mobile App Development
Native and cross-platform builds that pass review the first time.
Backend Development
APIs, data models, and the boring reliability that everything above depends on.
Other sectors we work in
Next step
Tell us where your availability stops being true.
A senior engineer reads every enquiry and replies within one business day with an honest view of what it will take, including which channel is most likely to oversell first.
