Travel businesses do not have one system of record. The booking sits in one place, the customer conversation in another, operations in a spreadsheet or inbox, and payments somewhere else again. That is true in a hotel, a tour operator, an airline, a transfer company, a destination business and a travel-SaaS tenant.
So “how should we use AI?” is the wrong first question. The useful question is: which operational job is painful enough to automate, which system is authoritative for that job, and where a human still has to own the decision.
This guide is Kaize’s map. It is not a tour of every AI vendor, and it is not a claim that Kaize has installed AI in every sector named below.
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 can sit across different platforms and teams. The challenge with adding AI isn't simply giving a model access to those systems; it's deciding what it should be allowed to read, what it can change, and where a person still needs to own the decision.
That is a founder and operator observation, not a multi-client case study. The pages linked from here are Kaize’s recommended architecture for travel-tech implementation. They are not evidence of named hotel, airline or tour-operator deployments.
Where AI belongs in travel operations
Start with the job, not the model. A hotel guest-messaging draft, a tour-operator booking-change recommendation, an airline disruption update, a transfer-company allocation, a destination inbox, a travel-SaaS tenant workflow: each is a different operational world. The pattern underneath is the same: retrieve, draft, recommend, then stop before the irreversible write.
Hotels are one operator type. Aviation, tour operating, transport, tourism and travel SaaS are the others this pillar is meant to hold. Kaize should not accidentally become a hotel-AI consultancy.
Name the system of record for that job before anyone picks a model. For a reservation change it is usually the booking engine. For a customer conversation it is usually the CRM or the inbox. For money it is the payment account. If two of those already disagree on a live customer, AI will not reconcile them by sounding confident.
Six operator worlds, one pattern
A hotel can use AI to draft guest messages and surface arrival status. Rate, inventory and refund commitments stay with a person. The PMS is one system among several, not the whole industry.
Aviation and disruption work is a timing problem. An agent can assemble the facts operations already has and draft a passenger update. Rebooking that changes the contract the passenger holds stays human.
Tour operators live on component changes. The useful automation drafts a date or component move and queues supplier confirmation. Confirming an ATOL-protected package is still an operator act.
Transport and transfer companies need allocation and exception drafts, not an unsupervised “your driver is confirmed” when the supplier has not answered. Tourism and destination businesses need inbox drafts that match the live booking. Travel SaaS teams need tenant-safe workflows that inherit the tenant’s operational boundary, not the platform’s admin key.
If a paragraph on this page could be published unchanged by a generic consultancy after swapping “travel” for “organisation”, it does not belong here.
Four questions this library owns
If the question is how an agent should reach a booking engine or CRM, that lives on how travel companies should control AI agents. If the question is why a demo passed and production failed, that lives on what usually breaks in production. If the question is whether to build or buy, that lives on build versus buy travel software. If the question is how to automate without losing the customer, that lives on operations automation and the human handoff.
This page should not steal those questions. It should send a travel buyer to the page that can actually answer them.
UK consequences that are real
Customer and passenger files in a UK CRM, PMS or booking system are personal data. An automation that can export or rewrite them is a UK GDPR processing activity. See the ICO’s data-protection principles. For a UK package, a write that changes the booking can change an ATOL-protected contract the operator already sold. Those are operator problems, not model-vendor problems.
How to use this map this quarter
Pick one workflow that already crosses two systems. Write down the authoritative system, the actions that must stay human, and the approval path. Then read the child page that owns that question. Do not commission a sixth generic AI article to sit beside this library.
If you want a structured look at where AI should sit on your existing stack, and where it should not, start with a Kaize Opportunity Review. That is a scoping conversation, not proof that this map has already been delivered on your estate.
Questions
How should a travel business start with AI?
Start with one operational job that already crosses booking, CRM or customer ops. Decide which system is authoritative and which actions stay human. Do not start with a model bake-off.
Does AI for travel mean hotel AI?
No. Hotels are one operator type. This guide also covers aviation, tour operating, transport, tourism and travel SaaS.
Is this a Kaize case-study library?
No. These pages are recommended architecture and founder/operator observation. They are not named-client implementation reports.