A travel company decides it needs an AI assistant. The brief is almost always the same: build a chatbot that answers customer questions. Six months later the bot handles “what time is check-in?” beautifully and falls apart the moment a flight gets cancelled. The questions that actually cost the business money — the rebookings, the disrupted itineraries, the angry guest whose room was given away — still land on a human agent’s desk. That gap is the most common failure in travel and hospitality AI programmes, and it traces back to a framing error made before a single line of code is written. The programme equates “generative AI” with “LLM chatbot,” scopes the work around conversation, and treats the operational tasks as out of scope. The value lands elsewhere, and the chatbot launch — however polished — leaves the hard problems unsolved. Why the LLM-Chatbot Framing Fails Generative AI is a broader surface than large language models. An LLM is one component: it generates and interprets natural language. But the work that moves operational metrics in travel — modifying a booking, re-sequencing an itinerary after a cancellation, matching a disrupted passenger to available inventory, reconciling a refund against fare rules — is not a language task. It is a workflow task that uses language at the edges. When a programme scopes itself as “build a chatbot,” it implicitly scopes out everything that isn’t conversation. The retrieval layer that pulls live booking state, the policy engine that knows which fare classes are changeable, the orchestration that calls the booking API and confirms the change — these get deferred, because they don’t fit the chatbot mental model. The result is predictable: a fluent interface bolted onto nothing, handling FAQ traffic while the costly tasks remain manual. This is the same pattern that shows up across verticals when a single fashionable technology name stands in for a whole capability. We see it regularly: the named technology becomes the scope, and the scope becomes the ceiling. The fix is to treat the LLM as the conversational front-end of a generative-AI system, not the system itself — a distinction we draw out in our broader work on generative AI engineering practice. Where the Value Actually Lands The tasks worth automating in travel and hospitality cluster into three tiers, and they are not equally easy. Naming them honestly is the first defence against the chatbot trap. Task tier Example What it needs beyond an LLM Difficulty Informational Check-in times, baggage rules, amenity questions Retrieval over a knowledge base Low Transactional Make a booking, add a service, upgrade a room Live inventory access, payment, booking-API orchestration Medium Service recovery Rebook a cancelled flight, re-sequence a disrupted itinerary, compensate a guest Policy/fare-rule reasoning, multi-system state, exception handling High The informational tier is where an LLM chatbot genuinely shines, and it is also where most programmes stop. The transactional tier requires the model to act against real systems — which is where agentic patterns become relevant. The service-recovery tier is where the money and the loyalty are won or lost, and it is the tier the chatbot framing systematically neglects. A useful planning heuristic, observed across the customer-facing AI engagements we have worked on rather than from any published benchmark: roughly the majority of inbound contact volume is informational, but the disproportionate share of cost and churn risk sits in the small fraction that is service recovery. Automating the easy 80% feels like progress on a dashboard and leaves the expensive 20% exactly where it was. How Agentic AI Changes Booking Beyond a Basic Chatbot The phrase “agentic AI” gets used loosely, so it is worth being precise. A basic chatbot answers; an agent acts. In a travel context, an agentic system can decompose a goal (“get me home today, my flight was cancelled”) into steps — query current booking state, check rebooking eligibility against fare rules, search available inventory, hold a seat, confirm with the traveller, execute the change, issue the new itinerary — and call the relevant systems at each step rather than narrating advice the traveller must then execute by hand. That capability rests on two things the conversational layer alone does not provide: reliable access to live state across booking systems, and a policy layer that constrains what the agent is allowed to do. Without the policy layer, an agent that can modify a booking is a liability. The engineering question is not “can the model talk about rebooking” but “can we let it touch the booking system safely, with the fare rules and the audit trail enforced outside the model.” This is the same agentic-orchestration concern that recurs whenever generative AI moves from advising to acting — a thread we develop in our work on agentic AI systems. For itinerary planning specifically, the agentic difference is between a model that suggests a plausible-sounding schedule and one that verifies each leg against real availability and pricing before presenting it. A suggested itinerary that books-out the moment the traveller tries to act on it is worse than no itinerary, because it consumes trust. What AI-Driven Service Recovery Looks Like Service recovery is the part of the surface where a well-built system earns its place. Consider a worked example, with the assumptions stated explicitly: a passenger’s connecting flight is cancelled overnight; the airline holds the original booking, the fare rules permit free rebooking on disruption, and seats exist on two alternative routings. A service-recovery system that works does the following before the traveller has finished reading the cancellation notice: it detects the disruption from the operational feed, retrieves the affected booking, evaluates rebooking eligibility against the fare rules, ranks the available alternatives by arrival time and disruption to the rest of the itinerary, and presents a confirm-or-decline choice in plain language. The LLM’s job in that chain is narrow — interpret the traveller’s preference and explain the options clearly. Everything load-bearing happens in the retrieval, policy, and orchestration layers. What makes this hard is not the conversation. It is that booking state lives across multiple systems, fare rules are intricate and change, and the cost of an incorrect automated action — rebooking onto a flight the traveller can’t make, or issuing a refund that violates policy — is high enough that the system must know its own limits and escalate cleanly. A correct system is measured by how well it hands off the cases it should not touch, not only by how many it resolves. What Are the Practical Disadvantages of AI in Hospitality? The risks are real and worth naming, because programmes that ignore them ship brittle systems. First, hallucination in a transactional context is not a cosmetic flaw — a model that confidently states an incorrect cancellation policy or invents a non-existent amenity creates a service failure and a liability. The mitigation is architectural: ground every factual claim in retrieval over an authoritative source and never let the model assert policy from its own weights. Second, automated actions without a constraint layer are dangerous. An agent that can modify bookings can modify them wrongly at scale. Third, personalisation pulls against privacy: the more a system knows about a guest, the more it can help and the more it can leak. Fourth, the failure modes are concentrated exactly where the customer is already upset — during disruption — so a system that degrades gracefully under those conditions is worth more than one that demos well under happy-path conditions. We pay close attention to that last point, because it is the one most often discovered in production rather than in scoping. None of these disadvantages argues against deploying AI in hospitality. They argue for scoping the programme around the operational surface rather than the conversational veneer. Structuring the Programme So Value Ships Incrementally The reason the chatbot framing persists is that it offers a single, legible deliverable: launch the bot. The better structure produces packageable value at every milestone instead of staking everything on one launch. Ship the grounded informational tier first — it is genuinely useful and it builds the retrieval foundation everything else depends on. Then add the transactional tier on top of live system access. Then layer service recovery on the policy and orchestration work, which by then is partly built. Each tier is independently valuable and independently shippable, which means the programme can demonstrate ROI before the hardest tier is complete and can stop or re-prioritise without having wasted the earlier work. This incremental posture is something we apply across vertical AI programmes, including adjacent customer-facing domains — the same reasoning shapes our work on AI in education and the operational AI patterns we describe for AI in energy and AI in maritime and shipping, where the gap between a demo and a production system is equally unforgiving. FAQ Is there AI for travel? Yes — and it is broader than the chatbots most travel programmes start with. The useful AI surface in travel spans informational assistance, transactional booking actions, and service recovery during disruptions, with the highest operational value concentrated in the harder transactional and recovery tiers rather than in FAQ handling. How to use AI for travel itinerary? The agentic difference for itineraries is between a model that suggests a plausible schedule and one that verifies each leg against real availability and pricing before presenting it. A useful itinerary system grounds its recommendations in live inventory so the plan survives contact with a booking attempt, rather than producing a schedule that books out the moment the traveller acts on it. How is AI being used in hospitality? It is used across three task tiers: answering informational questions through retrieval over a knowledge base, executing transactional actions like bookings and upgrades against live systems, and handling service recovery such as rebookings and compensation. The informational tier is where most deployments stop, but the transactional and service-recovery tiers are where cost and loyalty are actually won or lost. How does agentic AI change travel booking and itinerary planning beyond a basic chatbot? A basic chatbot answers; an agent acts. An agentic system decomposes a goal into steps — query booking state, check eligibility against fare rules, search inventory, hold and confirm a seat — and calls the relevant systems at each step, rather than narrating advice the traveller must execute by hand. That capability requires reliable access to live state and a policy layer that constrains what the agent is allowed to do. What does AI-driven service recovery look like for post-booking disruptions like cancellations and rebookings? It detects a disruption from the operational feed, retrieves the affected booking, evaluates rebooking eligibility against fare rules, ranks alternatives, and presents a confirm-or-decline choice in plain language. The LLM’s role is narrow — interpret preference and explain options — while the load-bearing work happens in the retrieval, policy, and orchestration layers, and the system must escalate cleanly the cases it should not touch. What are the practical disadvantages or risks of deploying AI in the hospitality industry? The main risks are hallucinated policy statements in a transactional context, automated actions taken without a constraint layer, the tension between personalisation and guest privacy, and failure modes concentrated during disruption when the customer is already upset. None argues against deploying AI; they argue for grounding factual claims in authoritative sources, constraining automated actions, and scoping the programme around the operational surface rather than the conversational veneer. The next time a travel AI brief lands as “build us a chatbot,” the more useful question is which task tier the value is supposed to land in — because the framing chosen at scoping is the ceiling the programme will hit, and a GenAI feasibility assessment that names the service-recovery tier honestly is worth more than a fluent bot that can’t rebook a cancelled flight.
