Every vendor in this category demos well. The screens look the same, the feature lists are near-identical, and the differences that will actually cost you money in year two are not on any of them.
These are the questions that separate a platform you keep from one you migrate off — and, more usefully, what a good answer sounds like.
1. Show me a hotel loaded from a real contract
Not a demo product. Ask them to load one of your contracts, live, in front of you: a room type with per-occupancy prices, two overlapping seasons, a minimum stay, an allotment, and one compulsory supplement.
A good answer takes ten minutes and produces a rate you recognise.
A bad answer is "we'd handle that in onboarding" — which means the model does not fit your contract and somebody will be pasting values into a grid every season.
2. What happens when two agents book the last room at the same second?
This is the question most likely to be answered with a euphemism.
A good answer describes the availability count being consumed inside the same database transaction that creates the booking, under a lock, and released when a booking is cancelled.
A bad answer mentions "real-time sync" or "we check availability before booking". Checking before booking is exactly the race condition — the check and the write have to be the same operation.
3. Is the agent balance a ledger or a field?
Ask to see the data, not the screen. Can you export every movement, with a reason and a reference, and add it up to the balance shown?
A good answer shows an append-only list where corrections are made by reversing entries, both of which stay visible.
A bad answer is a balance you can type over. You will find out why that matters during a dispute, not before.
4. What happens to the money if a booking fails halfway?
A good answer: funds are held, not spent, while the booking is placed; a failure releases the hold and the agent's balance is untouched; holds expire and something sweeps them up.
A bad answer: "we refund it." A refund is a second movement that can fail on its own, and in the gap the agent either cannot spend their own money or can spend it twice.
5. Reprint a voucher for a booking made a year ago
Then change the product's cancellation policy and reprint it again.
A good answer: the voucher is identical both times, because it renders from a snapshot taken at booking.
A bad answer: the voucher now shows today's policy. You have just been shown a system that will one day tell a guest they agreed to terms that did not exist when they bought.
6. Where does your name appear?
Walk the whole path: the portal, the browser tab, the sign-in page, the confirmation email's sender and body, the voucher, the e-ticket, the invoice.
A good answer is "nowhere". A bad answer is "only in the email footer", which is the place your agents look most.
7. Can I export everything, today, without asking?
Bookings, products, agents, the ledger, in a format you can open.
A good answer is a button. A bad answer is a support ticket, a fee, or a notice period — all three are a lock-in mechanism wearing a process costume.
8. Who can move money, and what is written down when they do?
A good answer: money rules are restricted to named roles, adjustments need a second person to approve, two-factor authentication is available, and every change is on an audit trail with an actor and a timestamp.
A bad answer: one admin account shared by the office.
9. What does the system do badly?
Ask it plainly.
A good answer names two or three real things — a vertical that is thinner than the others, a report that does not exist yet, a workflow that takes more clicks than it should.
A bad answer is "nothing". Either they have not run it in production, or they are not going to be straight with you about the parts that will annoy you. Both are the same problem later.
10. What happens on the day I want to leave?
The best time to ask is before you sign, and the answer tells you how the vendor thinks about the relationship.
A good answer is unbothered: export is self-service, data is yours, notice is short.
Two questions that are not on this list
"How many integrations do you have?" — Integration count is a proxy for nothing. What matters is whether the one supply source you actually need works, and whether your own contracted inventory is a first-class citizen rather than an afterthought bolted next to the API.
"Is it customisable?" — Everything is customisable if you pay enough. The useful version of this question is question 1: does the model already fit the contracts you have?
If you are working through this list against us, the answers are on the pages about what white-label has to mean and how the booking engine actually works — and we will answer question 9 in writing if you ask.
