Most travel AI pilots work. Very few scale. The difference is almost never the model — it is whether the use case was chosen for how well it demonstrates or for how well it survives a Tuesday in August.
There is a particular kind of meeting that happens about nine months into a travel AI programme. The pilot worked. The demonstration was good. Somebody senior saw it and was pleased. And yet the thing has not moved beyond one site, one language or one queue, and nobody can quite explain why.
The explanation is usually that the use case was selected before anyone asked whether it could survive contact with operations. It was selected because it was visible — because it would show well to a board that had asked what the company was doing about AI. Visibility and survivability are close to unrelated, and in this sector they are sometimes inversely related.
What surviving contact with operations actually means
The use cases that reach production and stay there tend to pass the same four tests. This is a framework rather than a survey finding, but applied honestly it predicts which pilots will scale better than any assessment of the technology does.
1. High volume, low variance. Enough repetition that automation is worth the integration work, and enough consistency that the same answer is correct most of the time. A question asked four thousand times a month in roughly the same shape is a candidate. A question asked forty times a month in forty different shapes is not, however irritating it is.
2. A clean source of truth. There is one system where the answer lives and it can be read reliably — the property management system, the reservation system, the incident log, the ticketing platform. Where answering requires reconciling three systems that disagree, the integration work will consume the entire benefit.
3. A defined failure mode. When it does not know, there is somewhere obvious for the conversation to go, and the handover carries the context with it. Use cases where the fallback is to apologise and end the call do not survive their first bad week.
4. An owner whose numbers move. Somebody in the operation sees the improvement in their own reporting. Use cases owned by a central team and measured by nobody in operations are the ones that quietly stop being maintained, without anyone ever deciding to stop.
Applied honestly, that test disqualifies most of what gets proposed in the first workshop. What follows are the three that keep passing it.
Use case one: capturing enquiries out of hours
The most consistent performer, and the least glamorous. A meaningful share of inbound enquiries arrive outside the hours the business staffs properly — evenings, weekends, and the hours where a site has two people covering the desk, the phone and anything that goes wrong. It happens the same way to an agency where everyone is with a walk-in, to a tourist information office with one person on, and to a vehicle rental desk at eight in the evening.
Those enquiries do not wait. In a category where the same room, seat, ticket or departure is available from four other sources within thirty seconds, an unanswered enquiry is not deferred revenue — it is revenue a competitor books.
It passes all four tests cleanly. Volume is high and variance is low, because out-of-hours enquiries cluster around a small set of questions: availability, price, amendments, cancellation policy, how to get there. The source of truth is the booking system and the read is straightforward. And the failure mode is well defined — capture the detail, commit to a callback at a stated time, and put it in a queue somebody actually works at eight the next morning.
How much any operator recovers depends entirely on how badly those hours were covered before they started. There is no published figure for this in any of our four markets, so we are not going to invent one. Measure a week of your own and you will have better data than any benchmark could give you.
Use case two: requests between booking and arrival
The second is the long tail of requests that arrive between somebody booking and somebody turning up. A late checkout, an extra bed, a dietary requirement, parking, what time the pool closes. At a museum or an attraction, whether the ticket time can be changed. At an agency, whether one more person can still be added to the group. Individually trivial. Collectively, an enormous volume of interruption landing on exactly the people you least want interrupted.
This one passes the tests, but conditionally. Volume and variance are fine. The failure mode is fine. The source of truth is where it gets interesting: a surprising number of these requests are not written down anywhere official. They live in a notebook, a group chat, or the memory of somebody who has been there eleven years.
Operators who tried to automate this without first deciding where a request gets written down ended up automating the capture of requests that then went nowhere. That is worse than doing nothing, because now the customer has written confirmation that something will happen.
The ones who made it work treated the where-is-it-recorded question as the project, and the conversational layer as the easy part at the end. That is the right way round, and it is almost never how the business case gets written.
Use case three: absorbing disruption surges
The third is narrower and applies mainly to airlines, transport operators, online travel agencies and tour operators — anyone whose contact volume can rise several hundred per cent in ninety minutes because of weather, industrial action, a technical fault or a supplier failure.
Surge is the purest case for automation, because the alternative is not a human doing it better. The alternative is nobody doing it at all. During a serious disruption the queue is not being handled well by people — it is being abandoned. Anything that answers a share of 'am I affected and what are my options' while a person works the genuinely complex cases is straightforwardly better than what happens now.
It passes the tests with one caveat: variance is low during the event and very high outside it, so the use case is dormant most of the year. That makes it hard to justify on annualised volume and easy to justify on the avoided cost of a single bad week. Which of those two framings you use will determine whether it gets funded — and that has nothing to do with the technology.
The ones that usually do not survive
Three proposals come up constantly and fail for structural rather than technical reasons. Booking a whole trip through conversation, start to finish: it demonstrates beautifully, and in production it has to touch availability, rates, restrictions, payment and changes, across systems that were never designed to be driven conversationally. Upselling based on how the customer sounds: high variability, ownership contested between marketing and operations, and a failure mode that actively damages you. And the assistant that does everything across the whole customer journey — which is not a use case, it is a category.
Worth saying plainly, even though it does not help us: those three are the ones we get asked for most often.
Read the research: the state of AI and automation in European travel operations →