AI Customer Support at Scale: The Travel Industry’s $Billion Bet
Matic: The Robot Vacuum Making Intelligent Automation Possible at Home (Sponsored)
Matic is the first visually intelligent robot vacuum that sees your home like you do, so it can clean how you want it to.
Travel platforms are increasingly using AI for customer support. This means an increase in automated answers with less human intervention. However, the cases handled automatically are largely lookups and routine changes that map cleanly onto a structured workflow. The cases that remain are typically disputes, such as a host and a guest having different views about a cancellation. In such cases, the travel platform is positioned between them and is accountable for the funds. The platform needs to figure out how to deal with these cases. It is not just a business problem, but also an engineering problem. There is an important question at the center of this problem. At what moment should the system stop and route a case to a human agent? A platform fielding hundreds of millions of contacts a year faces that decision millions of times a day, across cancellations, refunds, and after-hours lockouts. A confident but wrong answer can ruin a traveler’s trip and the money at stake. Airbnb, Booking[dot]com, and Expedia have each tried to solve this problem in different ways. Airbnb prioritized autonomous resolution, building models that settle cancellations and refunds before an agent enters the conversation. Booking concentrated on the handoff, routing complex cases to a representative briefed in advance while equipping hosts to answer guests directly. Expedia emphasized deflection at scale, investing in summaries that carry context across more than thirty languages so an escalated case arrives intact. In this article, we will look more closely at the different solutions by following the support pipeline from first principles, show why a tail of cases resists automation regardless of model quality, and use these three approaches to understand how these can be handled. Disclaimer: This post is based on publicly shared details from various sources. References at the end. Please comment if you notice any inaccuracies.
The PipelineStart with the simplest version of automated support: a bot that matches a traveler’s message to a list of frequently asked questions and returns the closest article. It works for questions like “What is your cancellation policy?” However, it fails the moment a traveler writes something like “My host agreed to refund me, so what happens if I cancel now?” That sentence carries an intent, a history, and a financial consequence, and a simple keyword match treats it as a search query. The first real component is intent detection. In plain terms, the system classifies the message and identifies what the traveler wants: a rebooking, a refund, or a question about an existing reservation. Airbnb frames this as a layered problem:
For a cancellation, those second-layer models answer focused questions. Did the host or the guest initiate it? Have both sides agreed on a refund amount? Alongside this, a separate model predicts the expected refund ratio (such as the share of the payment a human agent would typically return given the circumstances of the trip). That predictor is trained on years of past agent decisions, which lets the system produce decisions in line with how experienced staff have handled similar cases.
However, a message understood is still inert until two further capabilities exist:
Reading intent is the easier half. Taking a correct, reversible action against live booking and payment systems is what requires greater consideration. The final element is a confidence threshold. Each prediction arrives with a score, and the threshold determines whether the system proceeds on its own or routes the case to a person. If this bar is set too low, more cases clear automatically while errors creep upward. If it is raised, the accuracy improves, but more traffic lands on human agents. That single threshold value is where much of the tuning happens This pipeline, intent detection, state tracking, an action layer, and a confidence threshold, handles a large volume of everyday requests well. However, it keeps facing problems in one family of cases. AdjudicationThe cases that clear automatically share a quality. They are answerable by retrieval. In other words, the system finds a fact or applies a rule, such as the status of a refund or the steps to change a date. Volume here is high, and the work is repetitive. These are the types of problems where automation works well. The cases that resist automation differ in kind. They require adjudication, meaning a judgment between parties whose accounts and interests diverge. A guest says the apartment was misrepresented. The host says the listing was accurate and the guest simply changed their mind. A damage claim sits between them, and the platform holds the deposit. There are three parties, three versions, and one decision about money. A better model produces a cleaner summary of the dispute, yet the underlying call still rests on weighing competing claims, which is difficult for even a powerful model.
Time pressure sharpens the divide. When flights were cancelled across the Middle East, and a surge of travelers contacted Expedia at once, automation absorbed the routine rebookings and status checks at speed, which freed human agents to spend their attention on the tangled, time-sensitive cases. The same event produced both kinds of work in the same minutes, and the value of the split was that each kind reached the right handler. This is why the resolution rate climbs and then flattens. The boundary separating automated from escalated cases advances as retrieval improves, and it approaches a region of adjudication-heavy cases that stay with people by design.
It also explains why headline percentages deserve careful consideration. Airbnb reports that more than 40% of guest issues are resolved without an agent. Expedia reports that more than 30% of its self-service interactions are powered by AI, where self-service already accounts for more than half of all contacts. Those two figures rest on different bases, so a side-by-side ranking would mislead more than it informs. Each number describes its own pipeline rather than a shared scoreboard. HandoffWhen a case crosses to a person, the details of what is shared become important. A handoff that passes along only “escalated, please assist” forces the customer support agent to restart the conversation, and the traveler retells the whole story to a second responder. A traveler who repeats every detail to a human after a stalled bot session ends up more frustrated than one who reached a person at the start. This asymmetry is the reason handoff deserves real engineering attention. A weak handoff can leave the combined system performing worse than plain human support would. The solution to this lies in the payload: the bundle of context that accompanies an escalated case. A strong payload carries four elements.
The agent opens the case already informed and continues from where the automation left off.
Expedia leans on this idea at scale. Its systems generate conversation summaries across more than thirty languages, so a case handled partly in Portuguese can reach an English-speaking support agent with the thread rendered in a language they read fluently. The same summaries shortened the time required to bring new agents up to speed by a substantial margin, because a well-formed summary teaches as it informs. Booking describes the same priority from the other side. Its tools route complex questions to a representative who receives the relevant booking and property details in advance, so the human starts the conversation already holding the facts. Booking also adds a second component that the others treat as secondary. Much of its support volume is communication between a guest and an accommodation partner, so it built tooling that drafts partner replies from property and reservation data and suggests them to the host. Here, the friction is the message between two people rather than a decision the platform owes, and equipping the partner to answer quickly relieves pressure before a formal support case ever opens. The pattern across all approaches is consistent. The success path contributes to the headline percentage, while the failure path, the moment a case escalates, is where the overall customer experience is decided. The core work for building such systems concentrates on handoff far more than on the straightforward case where everything resolves on the first attempt. DivergenceThe design decisions made by the three companies indirectly express three beliefs about which part of travel support is hardest. Airbnb’s position is that the adjudication itself can be modeled. By training on the expected refund ratio and on the questions agents ask during a cancellation, it pushes the automated portion as far toward real decisions as the data supports, and it reserves human attention for safety, discrimination, and high-value claims. The wager is that a large share of disputes follow learnable patterns, and that an autonomous system applying a consistent standard serves travelers better than a queue of agents who each interpret a policy slightly differently. The cost of this position is a heavy, continuous investment in models and labeled data, and a high bar for caution wherever money and safety meet. Booking solves the problem differently. Its emphasis on briefing the human agent and on drafting replies for partners treats communication as the primary friction. The implied belief is that a great deal of support volume is people struggling to reach each other, a guest with a question and a host with the answer, and that closing that gap quickly matters more than resolving every case autonomously. This keeps more humans in the loop while raising the quality of each human touch. Expedia’s emphasis on deflection and multilingual summaries reflects a third belief that scale is the dominant variable. With well over two hundred million interactions a year, even modest gains in self-service rates and handling times compound into large absolute numbers, so the architecture optimizes for volume routed correctly and for context that survives a language boundary across a global workforce.
TradeoffsEvery placement of the boundary carries a price on each side, and the confidence threshold makes the trade concrete.
There is an operating point that balances the two, and choosing it requires judgment about how expensive an error is relative to an escalation. In travel, where an error can mean a wrongly denied refund on someone’s holiday, that judgment leans conservative wherever the stakes run high.
There is also a more fundamental limit worth considering. The chat interface itself suits travel poorly, because a chat thread is built for one person, while a travel dispute often involves several. A cancellation between a host and a guest, mediated by a platform, is a conversation among three parties, and a linear thread struggles to hold that arrangement sometimes. It is not simply a matter of improving the interface. It suggests that the format through which support arrives may bound how far automation can go, separate from how capable the model becomes. For that reason, regulated cases, high-value claims, and anything touching safety remain with people on purpose. The boundary moves rightward over time, and a margin is kept on the far side, where human judgment is meant to outweigh a confident automated answer. ConclusionThe percentage of issues resolved without a human is an indication of two things: where a platform places its automate-versus-escalate boundary and how much of its work is answerable by retrieval rather than judgment. The model matters, yet it operates inside a structure built to manage that boundary. A few points hold across all three platforms.
Put together, the resolution rate reflects a design decision as much as a level of capability, and the boundary is the part of the system worth reading first. References:
|
Comments