Enquiry to itinerary: what to automate first

Ask a travel business what it wants to automate and the answer is often "the itinerary". Ask what actually consumes the day, and the answer is almost never the itinerary. It is the hour before it — reading a request, working out what is missing, chasing it, and typing the result into the system that produces the quote.

That gap is where the first automation belongs, and it is unglamorous enough that it is routinely skipped in favour of something more impressive that never ships.

Start by defining what "complete" means

Before any technology decision, a travel business needs a written definition of a complete enquiry, by itinerary type. Party composition. Dates and how flexible they are. Origin. Budget band. Service class. Special requirements. Source and ownership.

This sounds trivial. It is not. Writing it down usually surfaces more disagreement inside a travel business than the technology ever does, because different consultants have been applying different definitions for years and the business has absorbed the cost as normal variation.

Until that definition exists, there is nothing to automate against. Extraction has no target, validation has no rule, and any measurement of "qualification time" is measuring an undefined thing.

A definition of complete is the contract everything downstream is built against. Skip it and you automate the disagreement.

Choose a first candidate that can be measured

A good first automation candidate has four properties. It is high-volume, so the gain is material. It is well-understood, so the rules can be written down. It is measurable, so the result can be proven to whoever holds the budget. And it is reversible, so a mistake is recoverable rather than a customer incident.

A workflow missing any of these is a poor first candidate however attractive it looks in a demonstration. Autonomous itinerary generation typically fails three of the four: the rules are not written down anywhere, the output quality is hard to measure objectively, and a wrong itinerary in front of a client is not cheaply reversible.

• High-volume. If it happens twice a week, the saving will not survive the maintenance cost.
• Well-understood. If your own team disagrees about the correct outcome, a system will not resolve that.
• Measurable. Capture the baseline before anything changes, or every later claim is an assertion.
• Reversible. The first automation should fail in a way that costs an apology, not a booking.

Structure before generation

There are two broad things an AI step can do with an enquiry. It can structure it — turn prose into fields your systems can use. Or it can generate — produce a draft itinerary, a suggested response, a proposed price.

Structuring is dramatically safer and, in most travel operations, worth more. It is verifiable, because a consultant can see at a glance whether the dates and party size are right. It is bounded, because the output is a set of fields rather than free text. And its failure mode is a flagged gap rather than a confident invention.

Generation is where the demonstrations are impressive and the production deployments are cautious. It has a place — preparing a starting structure for a consultant to edit is genuinely useful — but it belongs after structuring, not instead of it.

Decide what happens when it is unsure

The design question that matters most is not what the system does when it is confident. It is what it does when it is not.

A system that resolves uncertainty by guessing produces errors that are confident, documented and downstream of any human review. A system that flags uncertainty produces a small amount of visible work and no silent errors. The second is almost always the right trade in a business where a wrong date costs a booking.

In practice that means deciding, per field, what confidence threshold is required and what happens below it. That is a specification, not a setting, and it is worth the hour it takes to write.

Keep the consultant in the loop, deliberately

The valuable thing a travel business sells is judgement about destinations, suppliers and travellers. The expensive thing it does is reconstruct context. Automation should remove the second and leave the first alone.

Concretely: a consultant should open a request and find the details structured, the gaps identified, the comparable past work surfaced and a starting structure prepared. They should still be the one deciding whether it is right for this traveller. If an implementation removes that decision, it has automated the wrong half of the job.

Sequence it narrowly

Take one channel and one itinerary type all the way through to a consultant-ready record. Run it alongside the existing process with real traffic, which is messier than any sample and is where the definition gets corrected. Measure against the baseline. Then widen.

The alternative — a shallow layer across every channel at once — hides exactly the problems that matter until they all arrive together at launch.

Written from delivery experience across travel operations. It describes an approach rather than guaranteeing an outcome; results depend on scope, data quality and starting point.