Travel's real AI opportunity is in the back end, not the chatbot. I built a working lab to prove it.

Everyone in travel is building AI for the front end. The bigger, more durable opportunity is in the back end — and rather than write about it, I built a working demonstration of it. This is for the commercial, product, distribution, strategy and technology leaders at travel supply and distribution businesses: wholesalers, DMCs, OTAs, package-holiday businesses, agency networks, loyalty programs and startups.

Most of the AI conversation in travel right now is centred on the front end — agentic tools and chatbots for itinerary planning and booking. I think that is the wrong place to be looking for the biggest wins.

After more than 20 years in the industry, including leading global strategy for a large multinational travel company and a background in revenue management, I’m convinced the more durable opportunity sits in the back end: the API integrations, content mapping, supplier selection and pricing decisions that quietly govern how travel businesses actually run.

To show what that looks like, I built the Travel Spark Solution Lab — a set of working demonstrations, not an off-the-shelf SaaS product, that let business leaders see redesigned travel processes running live. What follows is what it is, why I built it, and what surprised me when we did.

The Solution Lab asks a single question — “Does it really have to be this hard?” — and makes it tangible through working demonstrations across supply activation, booking and pricing.

Why the front end isn’t where the opportunity is

The current focus has been driven in part by the big OTAs, which have talked about the contribution of AI chatbots to their revenue — although that contribution remains incredibly low. Travel agencies are also looking at how AI can streamline customer enquiries, itinerary creation and the initial consulting process. The industry seems totally focused on the front end of the sales experience.

I think AI and technology more broadly give businesses an opportunity to do something more fundamental. Travel has built its solutions around years of systems and technology constraints. If we could completely redesign areas such as API integration and content mapping today, we wouldn’t necessarily build those same inefficiencies back into our businesses.

Where this came from for me

When I was looking after global strategy for a large multinational travel company, I was trying to solve the challenge of API integrations and content normalisation across multiple sources.

At the time, our easiest solution was a technology intermediary that sat between two systems and already had API connectivity built. Before that, the business was looking at manual loading, spreadsheet management and hands-on-keyboard approaches.

Ten years ago, that allowed us to automate a lot. With the advancement in AI and technology, I now ask where we can improve on those solutions again.

I’ve seen this challenge even quite recently. A large organisation went through an RFP and tender process to look for new sources of supply and new suppliers, alongside the usual commercial returns.

They reached the final tender preparations before learning from their technology team that a new integration would take more than 12 weeks, come at a significant cost, and pull resources away from other scheduled work. An inefficient technology process ended up driving the commercial outcome at the business level.

The question behind the Solution Lab

The driving question for me was how we could take some of those travel industry norms, improve them, and speed up the processes behind them.

API integration is a great example. If we can use an AI solution to read documentation, map to a canonical data model, and build out 80 to 90% of an API adapter before handing it over to an engineer or developer, we’re taking a 12-week process and making it one to two weeks.

Supply Activation, step one: the system reads a supplier’s API documentation — deterministic extraction first, then AI to resolve ambiguity — and turns it into a capability matrix, so commercial teams can understand a supplier before any development starts.

That was the central question: how do we break some of that established thinking and redesign these processes from scratch?

Why I built it

These challenges are often hard to understand because they happen deep inside technology and operational processes. Rather than writing a white paper about what new solutions might deliver, it felt more useful to build one and let business leaders see it working. My intent was to combine commercial IP developed over years of working for large and complex travel organisations with modern technology.

What surprised us when we built it

What really surprised me was seeing live Hotelbeds searches come through in the Booking Hub. Although we’ve only built to a few API calls, we created the underlying pattern within hours.

The Booking Hub running a live Hotelbeds search: 230 source offers from multiple suppliers normalised into 56 comparable, bookable products in one interface — with the commercial model applied on top.

More importantly, we were able to prove some things around data modelling and room mapping — to the point where we found an error in one of the supplier feeds. There was a spelling error in the room type name, and our system managed to pick it up and join two different room names into a single room.

For me, that was a powerful example of something deterministic models or traditional matching algorithms wouldn’t necessarily have caught, because on the surface the two entries looked like completely different offerings. We built rules around the room-type naming issue, and you can now see them working live in the demo.

Mapping suppliers to a canonical master: the system adjudicates each match with visible evidence — name, address, distance and brand — removing roughly 85% of the manual effort while surfacing only genuine exceptions for review.

Rethinking pricing and supply

One of the most interesting parts of the Solution Lab is the pricing model and its optimisation algorithms.

While that sounds technical, my background in revenue management let me rethink parts of the pricing journey that are currently missed. Businesses often choose relatively arbitrary markup or price-adjustment figures to sit within a competitive set.

In the Lab, the model also considers customer service scores, API technical uptime, error rates, commercial rebates and back-end overrides that impact the deal.

This creates an opportunity to move beyond the old model in which the cheapest net rate always wins in supply orchestration. The system can choose what makes the most sense for the business at that point in time.

The pricing and orchestration layer choosing both a customer price and a supplier route against a commercial objective — showing that the cheapest net rate doesn’t automatically win once service scores, reliability, rebates and margin are weighed together.

Customer prices can then be based on market value. Regardless of where we buy the product, the customer’s willingness to pay is the same. They don’t frankly care who supplies it — they care whether the price is competitive and makes sense.

Where people still matter

I assumed we would have to be extremely careful about AI hallucinations, particularly given how critical some of this information is to people’s holidays and to transactional systems.

Setting the right boundaries was important, as was keeping a human in the loop. Where something doesn’t score 100%, somebody manually reviews it. People remain critical to these processes.

Where people still matter: only residual ambiguity is escalated to a human exception queue, where a reviewer confirms or rejects the system’s best candidate matches. People handle judgement; the system handles the repetitive work.

Commercial IP is the difference

The important thing here is that we’re not suggesting throwing an LLM or AI model at any back-end system with a developer who lacks travel-specific commercial experience.

That’s where the commercial IP comes in. The rules and design behind these solutions draw on knowledge built over more than 20 years in the travel industry — seeing these problems and designing solutions around them.

The Travel Spark Solution Lab helps businesses see, in real time, how existing processes could be thought through differently and redesigned to be more efficient. It was not designed as an off-the-shelf SaaS solution; it was designed to help businesses redesign their own processes and implement modern technology.

If we didn’t have these technology constraints — and the workarounds that have become normal — would we design and develop processes this way? My view is that we absolutely wouldn’t.

The real challenge is whether the right people inside a business see these processes as problems to be solved, and whether there is enough commercial experience behind the technology to develop the right solutions.

With the right IP and experience, the industry should be looking beyond AI-led or agentic trip planning, and considering how the rules-based commercialisation of AI can drive efficiency across back-end processes.

See it working

If you run supply, distribution, product, commercial or technology strategy at a travel business, the Solution Lab is built for you to see these ideas running live rather than described on a slide. Explore the working demonstrations at lab.travelspark.com.au — or get in touch to walk through how these processes could be redesigned inside your own business.