How to judge a booking engine, including ours
Demonstrations are designed to look the same. The differences between booking systems show up in the answers to seven questions that never come up in a demo, and in what happens on the day you want to leave.
Why demos do not separate good systems from bad ones
Every booking engine demo shows a calendar, a product page and a confirmation email, and they all work, because the person driving knows which dates have availability. Nothing in a demo tells you what happens when two agents hold the last cabin at once.
The questions below are the ones that separate systems. Send them in writing. A supplier who answers all seven in an email is already more trustworthy than one who wants to explain it on a call.
Seven questions to ask before you sign
1. How does my data come out, and can I do it myself
Ask for an export today, during the evaluation, not a promise about later. It should include bookings, customers, products, prices and the notes your staff write, in a format a spreadsheet opens. If the supplier has to run it for you on request, your data is hostage to a working relationship — the same relationship that has broken down on the day you need it.
2. Whose name is on the payment gateway contract
If the merchant account is in the supplier's name, the money reaches them first, your chargeback history belongs to them, and on the day you leave you start bank approval from zero. In your name it is slower at the start and yours afterwards. Be careful with any answer that avoids the word merchant.
3. What happens when a hold expires
A booking engine holds inventory while somebody pays. Ask how long, and what happens at the end. Put the scenario precisely: a cabin is held for fifteen minutes, an agent cancels at minute fourteen, and the channel connection has not synchronised. Does the cabin come back on both sides, one side, or neither. A supplier who has built this properly answers immediately, because it has bitten them.
4. Is the channel connection two-way or one-way
Pushing availability out to a marketplace is the easy half. Reading bookings back immediately, and reducing availability everywhere else, is the half that prevents oversells. Many integrations sold as channel management are a one-way push with a periodic import. Ask what the interval is, what happens to a booking that arrives inside it, and who pays for the oversell.
5. Do the fees scale with bookings
A subscription and a per-booking fee are different bets. A per-booking fee makes your best season your largest invoice, for work the supplier does no more of. It can still be right at low volume, where the cost disappears out of season. Ask for the total on last year's numbers, and on double them.
6. What happens to my customisation when you upgrade
If the supplier has adjusted templates, forms or logic for you, ask who pays when the platform version changes, and ask to see the last three release notes. A product that has never released anything is not stable, it is unmaintained; one that releases constantly without notes leaves your customisation as your own problem.
7. How long does it take to leave
Ask for the exit in steps: notice period, final data handover and its format, who controls the domain and DNS, what happens to booking history and to bookings already taken. The answer predicts how you will be treated for the whole contract, because a supplier comfortable with the exit expects to keep you by being useful.
Signs to stop the conversation
- There is no self-service export, and the answer to question one contains the word "just".
- They will not name the payment provider until after the contract, or they propose collecting your money into their account as a convenience.
- The only demo is on their domain with their data, and they will not give you a sandbox with your own products in it.
- The contract renews automatically with a long notice period and says nothing about data on exit.
- In a sales conversation they agree to build anything you describe. Nobody who has maintained a platform says yes that quickly.
- They want to register the domain, hold the DNS or own the analytics account "to make it easier".
Send the seven questions by email and see what comes back. A supplier who answers in writing has thought about the answers. A supplier who replies with a meeting invitation and no answers has told you something too.
An embedded widget is not an integration
Both put a booking button on your website, and the price difference is large enough that the distinction is worth ten minutes.
| Embedded widget | Real integration | |
|---|---|---|
| Where the checkout happens | On the supplier's page, inside a frame or a new tab | On your domain, in your layout |
| What the buyer sees | A visible change of design at the moment of paying | One continuous experience |
| Search engines | The product content usually is not on your page at all | Product pages are yours, indexable, with structured data |
| What breaks | A supplier release changes the widget without warning | Your own release, on your own schedule |
| What it costs | Little, and it works this week | More, and it takes weeks |
A widget is a legitimate answer, not a compromise to apologise for. If you sell a handful of products, or your inventory genuinely lives in a platform such as Bokun and that platform is the source of truth, a widget is often the honest choice.
It stops being enough when your product pages need to rank in search, when the checkout has to carry your brand for a high-value booking, or when you need the booking data inside your own systems.
When a spreadsheet is still the right answer
A shared sheet with one owner and one column that everyone agrees is the truth beats a booking platform that nobody updates. Some businesses should not buy a system this year.
- You take a few bookings a week and one person handles all of them.
- You sell one product with one departure pattern, and availability changes rarely.
- You operate for one short season and the system would sit idle for eight months.
- The real bottleneck is reply time, not record keeping. Software will not write the reply.
- Nobody in the business will own the new system after launch.
- Whatever you decide, fix the sheet first: one row per booking, never a merged cell, one status column with a fixed set of values.
- Give every product a short identifier that never changes even when the marketing name does.
- Keep money in one currency per column, put business rules into their own columns instead of a notes field, and keep a dated export every week.
A clean sheet is also the cheapest possible migration. Most of the cost of moving into a booking system is deciding what your products actually are, and which rows are the same thing written three ways.
Where izBooking fits, and where it does not
Applying the same seven questions to our own platform, since a guide that exempts its author is worth nothing.
Probably right when
You want to sell under your own brand and domain, with availability, options and payment in one place, and you have enough direct demand for that to matter.
You need to keep selling through a channel manager or a marketplace at the same time.
Look elsewhere when
You need a booking button on an existing page this week — a widget is cheaper and we will say so.
You need a back office handling accounting, payroll or full ERP.
Needs a conversation when
Your product model is unusual: multi-day itineraries with per-day options, or allotments with complex release rules.
You need international card payment live in under two weeks. Bank approval does not compress.
Two disclosures belong here. izBooking serves over a thousand merchant sites, and during 2026 it is moving onto a new white-label platform; existing sites are transferred in controlled batches only after that platform passes an acceptance gate, not in parallel with development. If you sign now, ask which platform your site will be built on and when.
The izBooking page describes what it does and the pricing page gives ranges. If your existing system already fails question three or four, the relevant work is booking integration rather than a new platform, and it is usually cheaper. The companion guide on what a travel website costs covers the budget side.
What travel operators ask us most
Can we connect a booking engine to our existing website?
Usually yes, and it is often the cheapest useful step, provided the site can be edited at template level and is not on a locked platform.
If the platform does not allow it, the honest answer is that a workaround will break at the next update, and a rebuild is a separate decision to make on its own merits.
How much of the migration work is ours rather than the supplier's?
More than most quotations imply. Deciding what your products are, which duplicate rows are the same product, and which pricing rules are still in force is work only your business can do.
A supplier can format and import the result. Nobody can decide it for you, which is why a tidy catalogue shortens the project more than any technical choice.
Is a per-booking fee always worse than a subscription?
No. At low volume it is often better, because the cost disappears when you are not selling and there is no fixed bill out of season.
It becomes expensive at the point where your growth increases the invoice without increasing the supplier's work. Model both on last year's numbers and on double them before choosing.
What if the supplier will not answer the seven questions in writing?
Treat that as the answer. Every one of the seven is something a supplier knows about their own product, so a refusal is a choice rather than an inability.
You can also ask them to write the important ones into the contract. A supplier comfortable with their answers rarely objects to that.
Read next
Tell us what you are trying to run
What you sell, what you use today, and what is breaking. You get a written answer with an approach and a price range - not a brochure.