Guides

Agents in a travel app: rebooking is the feature worth building

Booking is already a form. The task an agent is uniquely good at is rebooking under disruption, and it needs four read tools before it can answer anything.

VVoqal · Engineering8 min readPart of Business

About this article

The demo every travel product builds first is spoken booking. Someone says “find me a flight to Lisbon next Friday” and the app produces flights. It is a good demo and a weak feature, because searching for a flight is the part of travel that already works. Flight search has had thirty years of investment and the form is genuinely good.

The task that is still broken is what happens when the flight you booked stops existing.

Why disruption is the case#

A cancellation is the moment when a passenger has a clear goal, no ability to act on it, and a system that has all the information required to help. They know they need to get to Lisbon tonight. They do not know which seats exist, what their ticket permits, or what they are owed. Every one of those is a query, and none of them has a screen.

If you are still costing this project, adding an agent, from the speech layer up is the place to start, because the read tools below are the part of the work that is genuinely yours and the rest is a procurement decision.

Every row in the middle column is a queue. The contribution is not politeness, it is that rows two to four can be resolved by a passenger holding a phone.

The thresholds are not a matter of opinion, which helps. In the United States, 14 CFR 260.2 defines a significantly delayed or changed flight as one departing three or more hours early or arriving three or more hours late for a domestic itinerary, six hours for an international one, along with a change of origin or destination airport, an added connection, or a downgrade to a lower class of service. Passengers with disabilities get additional triggers, including a substitute aircraft that lacks required accessibility features.

In the European Union, the Commission’s own passenger rights guidance says that after a cancellation the airline must offer, on a one-off basis, a choice between three things: reimbursement plus a return flight to the departure airport, re-routing to the final destination at the earliest opportunity, or re-routing at a later date under comparable conditions. Once the passenger chooses, “you no longer have rights in relation to the other two options.” Assistance thresholds start at two hours for shorter flights and rise to four for the longest, and compensation attaches to arrival delays of three hours or more.

Read that last sentence again from a product perspective. A passenger is being asked to make an irreversible choice between three options, under stress, in an airport, usually without being shown what the other two would have got them. That is a user interface problem with a legal consequence attached, and it is exactly the shape of problem a well-built confirm card is for.

Four read tools before any answer#

An agent with only the first of these will confidently offer a seat the ticket cannot use, which is worse than saying nothing.

The booking record establishes what was sold and what has happened to it. The fare rules establish what this particular ticket permits without a fee, which varies enormously within the same cabin on the same aircraft. Live inventory establishes what actually exists in the next few hours, including partner metal. And the disruption state establishes what this passenger has already been offered, because an accepted option closes the others.

Four tools, all reads, all returning small answers. The tool-design work here is mostly in the return shapes: fare rules should come back as a set of permissions rather than as the rule text, because a model reasoning about prose rules will get it wrong in a way nobody can audit. Putting an agent in front of the services you already run covers the seam, and the shape of the answers matters more than the transport.

There is no write tool in that list. Rebooking is one write, it goes last, and it goes through a gate.

The confirm card is where the money is#

The card is drawn from the priced quote the booking system returned. If the card and the model's sentence can disagree, the card is what the passenger will hold you to.

A fare change is a payment. The card has to carry the new itinerary, the itinerary it replaces, the amount with its sign, the card it moves on, and what becomes non-refundable once the tap happens. “Fees may apply” is not a confirm card, it is a disclaimer, and a disclaimer on a screen somebody tapped is a dispute waiting to be filed.

The design rule that makes this safe is that the card is rendered from the structured quote, not from the model’s prose. The model can say “there’s a seat at nine, it’ll cost you sixty euros more”; the card shows what the booking system priced. If those two ever disagree, the user acted on the card, and the card was right. The card a passenger accepts before anything is rebooked is the general form of this argument, and travel is where the cost of getting it wrong is easiest to quantify.

Options belong on the screen#

A products widget listing two items with sizes, prices in Egyptian pounds and an add control on each row.
Grocery items rather than flights, so read it for shape. A rebooking answer wants this structure: priced options a passenger picks from. A spoken paragraph cannot be picked from. Sample items from the widget renderer.

Three rebooking options read aloud is a memory test conducted on someone who is already having a bad day. Three options drawn as cards, each with a departure time, an arrival time, a connection count and a price delta, is a decision. The spoken part should be the summary that helps you pick: “the nine o’clock gets you in before midnight, the others are tomorrow.”

That division between what is said and what is shown is the whole argument for an agent that returns native UI rather than text. It matters in every vertical and it is unusually clear here, because the options are structurally identical and differ only in numbers, which is precisely the thing speech is bad at conveying.

When the honest answer is no#

Some disruptions have no good option. The next seat is in two days, the ticket does not permit an interline rebooking, and the passenger is going to sleep in the airport. An agent built to be helpful will generate something in that situation, and what it generates will be a suggestion the booking system will refuse.

Design for it explicitly. If the inventory tool returns nothing within the window the fare permits, the agent says so, states what it checked, and offers the one thing that is genuinely available: a place in the queue for a human, or the entitlement the passenger can claim while they wait. That response is worth building carefully, because it is the one the passenger will remember and the one most likely to be screenshotted.

The temptation is to soften it with a sentence about how the team is working hard. Resist it. A passenger who has been told “nothing tonight on us or our partners, the first seat is Thursday at 06:10, and you’re owed a hotel” can act. A passenger who has been told the airline apologises for the inconvenience has been given nothing, and they can tell the difference.

This is also the case that argues hardest for reading the entitlement tool. Being told what you are owed, by the app, without asking, is the single most surprising thing an airline agent can do.

Hospitality, and the smaller version of the same idea#

Hotels have the same shape at a lower stake. A guest asking to extend by a night, move rooms, or push a checkout time is asking a question whose answer depends on inventory, rate rules and what has already been promised. The tools are the same four in miniature, and the confirm card carries a rate rather than a fare.

The difference is that the failure mode is recoverable. A wrong hotel extension is a phone call. A wrong rebooking is a missed flight, which is why the travel case deserves the stricter gate even though both use the same machinery.

Language, briefly and without a claim#

Disruption is when a passenger is most likely to stop using their second language. Someone who books in English will complain, negotiate and panic in whatever they grew up speaking, and a travel agent that only works in the booking language will lose them at exactly the moment it was supposed to help.

We are not going to attach a number to that. The engineering question is whether your speech stack handles the varieties your passengers actually speak, which is an evaluation problem rather than a vendor-claim problem, and checking coverage for each variety your passengers speak covers the method.

Where to start#

Build the four read tools and ship an agent that can only answer questions. No writes, no rebooking, no card. It will tell a passenger what their options are during a disruption, which is most of the value and none of the risk.

Add the write when you have watched a few hundred of those conversations and know what people actually ask for. The confirm card is a week of work and the tool design behind it is a month, and doing it in that order means the month is spent on the right tools.

For the category question underneath this, start with what this kind of software actually is. For the integration itself, the quickstart is the shortest path to a first turn.

Sources#

Filed underAgentsTravelConfirmationTool design

Next

The quickstart wires the SDK into an app and runs one real turn against your own backend.

Read the quickstart

The rest of Business

Open the cluster

Build versus buy, what an agent changes about activation and support load, and the measurements that tell you before the quarter ends.

Elsewhere on the map