Building the foundation for AI-powered
travel support

Duffel sells travel infrastructure to companies that aren't travel companies - spend management platforms like Ramp and Rippling, fintechs like Robinhood and Bilt. These companies have millions of users who want to book travel, but they don't want to become travel agents themselves. Duffel provides the supply, the licensing, the infrastructure, and the operations that come with it.

I spent time with the support team - moved desks, sat in their area, watched how they actually worked. What I found was a structural problem rather than a tooling one. When a traveller needed to change a flight, the request would pass through multiple people and multiple systems before anything got resolved. Agents were working across three different tools - Zendesk for communication, an internal dev tool for order data, and the Dashboard for other booking information - and one request could touch all three, with the agent keeping the same information consistent by hand across each one.

There were two paths. We could redesign the internal admin tool - make it better for agents and keep support as a back-office function. Or we could move agents out of that tool entirely and into the Dashboard, which is the product Duffel actually sells to its customers.

I argued for the second one. The reasoning was that we sell the Dashboard to our customers so they can manage their travellers' bookings, and our own agents are doing the same job with more expertise. Both need to look at orders, take actions, see timelines, manage requests. Rather than maintaining two separate tools for essentially the same work, building one good product means our agents get something designed for their workflow, we stress-test our own product with the most demanding users we have, and we're building toward something that Duffel can eventually position as a dedicated travel operations tool in its own right.

That created an interesting design constraint - one product serving two different types of agent. Merchant agents work in a consumer-friendly context where airports are written out in full and the interface is forgiving. Duffel's expert agents need information density, IATA codes, and speed. One tool, two modes of working in it.

The Dashboard was still organised around individual bookings - one flight, one order, one view. But travellers don't think in bookings. A trip to Sydney is a flight, a hotel, maybe a car rental. Three separate bookings, one trip, one person. When something changes with the flight, the hotel might need to change too, and if the agent can only see one booking at a time they're missing the full picture.

The Customer User Page reorganised the agent's view around the traveller rather than the booking. One page per person, showing their full trip across all bookings, all requests, and all their history with us. When an agent opens a support conversation, they can see everything about that traveller in one place - which bookings they have, what they've asked for, and what's already been done. It's the foundation that everything else gets built on, and it's live - this is what our ops team works in every day.

The scenario that became the spine of the project was simple: “I need to fly a week later.” One sentence, natural language. The system figures out what needs to change - the flight, the hotel, maybe a transfer - checks availability, reprices, and handles the rebooking. The traveller gets a result, not a process to manage.

We started here deliberately. The traveller experience was the anchor for everything that followed. When we had to choose between making something easier for agents or better for travellers, we chose travellers. They're our customers' users - they don't know Duffel exists, and they shouldn't have to. Every decision downstream was tested against this: does it move us closer to that one-input experience?

All the structural work - mapping the service blueprint, moving agents into one tool, reorganising around the traveller - created the conditions for AI to actually land in a meaningful way. This isn't AI bolted onto a broken process; it's AI operating within a system that was already organised around trips, travellers, and structured workflows.

We chose a supervised model deliberately. These are our customers' users, not ours - the consequences of getting it wrong land on their brand. A lot of AI support tools go fully autonomous and fail silently, and travel has too many edge cases and too much money on the line for that. The approach is that AI handles the routine - surfacing suggestions, drafting responses, running through defined procedures - and a human agent reviews and approves before anything executes. Where the AI can resolve something end-to-end via API, it does. Where it can't, it escalates to the agent with full context rather than leaving the traveller waiting.

There's a reason every AI company uses travel in their product demos. 'I need to fly a week later' - and everything gets sorted. We built that prototype early, and it's compelling.

Travel runs on systems that are decades old. Airline source tools that predate the web. Booking data structured around individual orders, not around the person travelling.

As support grew and we took on bigger customers, the tension became clear: invest in better tooling for the agents servicing travellers today, or build the AI system we actually wanted to build. We didn't have the team to move both at the pace we wanted. So the foundational work - the migration, the data model, the agent workspace - came first, because without it, neither path was possible. That's taken longer than anyone expected, but it's what made the AI work real rather than performative.

Not everything has shipped, and not everything will. But travel support went from something Duffel struggled to offer to one of the core things it sells.