Most travel companies already have a booking system, a CRM, a way to take money, and a place operations actually works, often a spreadsheet or an inbox. The next software decision is rarely a green-field platform. It is whether to buy another seat, build something custom, or put a thin layer on the stack that already runs the business.
Asked as “build versus buy”, the question sounds like a preference. Asked as an operations question, it is sharper: which system is allowed to be authoritative, and which join will no vendor own?
This page is for travel companies and travel-tech product teams. It is not a hotel-PMS buyer’s guide, and it is not a claim that Kaize has replaced a named operator’s platform.
What this is and is not
Across travel businesses, one recurring issue I've seen is that the customer journey rarely lives in one system. Booking information, customer communication, CRM data and operational actions sit across different platforms and teams. The make-or-buy question fails when it pretends those systems will collapse into one product because a vendor said so.
The Kaize lesson is modest: travel software earns its seat when it respects the systems the operation already runs, or honestly replaces one of them.
That is a founder and operator observation, not a case study. The test below is recommended architecture. It is not evidence that Kaize has replaced a named operator’s booking platform.
Buy the system of record you do not want to recreate
A booking engine, a CRM, a payment provider and a hotel PMS are usually bought. Recreating them is a multi-year product, not a quarter’s project. If the job is “we need a reservation system”, the honest answer is almost always a vendor, plus the discipline to make that vendor the system of record for reservations.
The failure mode is not buying SaaS. The failure mode is buying a second system of record for the same job. The company already has a booking system and a CRM that do not agree. Another seat that also stores “the customer” gives operations a third place to be wrong.
UK customer files do not become someone else’s problem because the vendor is well known. UK GDPR accountability stays with the travel company. For a UK package, ATOL stays with the operator even if the booking SaaS is excellent.
Build the join the vendors will not own
Vendors are rational. They own the product they sell. They do not own the afternoon when a tour operator has to change one component, update the CRM passenger list, tell the customer, and wait for a supplier who is not on that vendor’s network.
That join is often the actual product. A custom build that copies the booking engine is usually a worse booking engine. A custom build that makes the booking and the CRM tell the same story, and puts a human on the confirmation, can be the work the operation cannot buy.
Write the job in operator language before anyone picks a stack. “Show the live booking beside the CRM thread and draft the change” is a build. “Replace the reservation system” is a different, much larger decision. Do not let a demo of the first become a budget for the second.
A thin layer is a third option, not a compromise
Kaize’s public position is that it usually works around existing booking, CRM and operational systems rather than replacing them. That is a product stance, not a slogan. A thin layer that drafts, routes and recommends can be the right build when the systems of record are already good enough and the pain is the join.
The layer still needs a boundary. Drafting a customer reply is not sending it. Recommending a booking change is not writing the reservation. If the layer includes an agent that can reach those systems, the control question lives on how travel companies should control AI agents. If the buy includes an AI feature that looked good in a demo, the evaluation question lives on what usually breaks in production.
This page should not steal those questions. It should decide whether the next pound is a seat, a join, or a replacement.
A recommended make-or-buy test
This is Kaize’s recommended architecture for the decision. It is not a certification and not a priced proposal.
- Name the system of record. For this job, is the booking engine, the CRM, or operations notes allowed to win?
- Name the join. Which two systems already disagree on a live customer?
- Buy if the vendor owns the job. If the workflow lives inside one product you already trust, buy the seat and stop inventing a platform.
- Build if the vendor treats the job as out of scope. Especially when the job is the join between booking, CRM and customer ops.
- Do not build a second booking engine. Recreating a system of record is a product company decision, not an integration.
- Do not buy a second customer file. Another CRM “just for this workflow” is how the journey fragments further.
- Keep irreversible writes human until the chosen path has an owner, an audit trail and a revocation path.
What to do before the next vendor meeting
Write one live workflow on one page: the trigger, the systems it already touches, the action that must stay human, and the place the customer can already be wrong. Take that page to the meeting. If the vendor cannot show the join, you are not buying the job. If your own team wants to rebuild the booking engine, you are not buying the job either. You are starting a product company.
The wider map of where AI and software belong in travel operations sits on AI for Travel.
If you want a structured look at whether the next workflow is a SaaS seat, a join, or a build around the systems you already run, start with a Kaize Opportunity Review. That is a scoping conversation, not proof that this test has already been applied to your estate.
Questions
Should a travel company build custom software or buy SaaS?
Buy the system of record you do not want to recreate. Build the join and the workflow the vendors treat as out of scope. Do not buy a second customer file, and do not build a second booking engine.
When is a thin layer better than a platform replacement?
When the booking and CRM are already good enough and the pain is the work that crosses them. A thin layer that drafts and routes is a different decision from replacing the reservation system.
Is this a Kaize replacement case study?
No. This is recommended architecture and founder/operator observation. It is not evidence that Kaize has replaced a named operator’s booking platform.