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, neobanks 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.

The thing that matters about travel is that it's messy. Flights get cancelled, people miss connections, airlines make schedule changes, and when any of that happens someone knowledgeable needs to be on hand who can actually resolve it. That's what servicing means — and before I joined, it was something Duffel offered but hadn't designed. There were a few travel agents on staff who handled requests by email and live chat through Zendesk, and they used an internal admin tool that engineers had built for themselves. It worked, but none of it had been thought through as a product.

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.

This vision set the bar for every decision that followed. Whenever we were evaluating a feature or an approach, the question was always whether it got us closer to that done-for-me experience or whether it was just adding another feature onto a chat tool. The answer was honest — we weren't close to the full vision yet, the operational stack was too fragmented and the tooling too manual. But the vision made clear what we were building toward, and it reframed support from something we had to do into something that could genuinely differentiate the product.

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. 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.

We initially thought we'd build self-service change flows and let travellers handle things themselves. We realised fairly quickly that we needed agents, and that the tooling for those agents was the real problem to solve. Then AI started becoming real, and we realised there was a chance to do something more powerful here — not just better tools for agents, but a system where AI handles the routine and agents supervise and handle the complex cases.

The platform has since expanded from flights to stays, cars, and trains — and the architecture has scaled with it. Zendesk is still in the stack for email. The airline source tools are decades old and outside our control. 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 — “we'll handle your travellers' support” is now a key part of the commercial proposition. The trajectory is clear, and the systems thinking that connected a broken operational stack to an AI-ready product architecture is the kind of work I want to keep doing.