You have probably had the AI conversation three times by now. Someone demoed a tool that writes itineraries. Someone else noticed it had confidently named a lodge that shut years ago. A reservations manager quietly started pasting enquiries into a chat window at eight in the evening because the queue had got away from them. And nothing was decided.
That is a sequencing problem, not a technology problem. Travel has a shape most AI advice ignores: a single enquiry can carry the margin of an entire trip rather than a monthly subscription, the consideration window runs weeks to months, and one wrong price or availability claim can become a contractual obligation you have to honour.
So here is an order - enquiry triage, first-response drafting, itinerary drafting, then follow-up and reporting - plus what you should never hand to a machine, the human-in-the-loop patterns that survive a busy Tuesday in peak season, and an honest way to tell whether it made money.
Start where the clock is already running
Enquiry triage is the right first move because it is the one place in your funnel where the cost of delay is both large and invisible. Someone fills in your form on a Sunday evening after two weeks of research, having filled in three others the same evening. Whoever replies first with something specific frames the conversation, including the budget.
Triage is not answering. It is reading, sorting and routing before a human touches the enquiry. This is the safest work to hand a model because it is mostly transcription, not judgement: the traveller has already given you the answers in their own words, and the machine is only moving them into fields. Extract what your team already asks on every call:
- Party composition: adults, children and their ages, singles needing a supplement
- Dates and flexibility - a fixed departure, a rough month, or open - and whether it falls in shoulder or peak season
- Destination, named must-sees, and anything they said they do not want
- Budget signals: business class, private guide, honeymoon, milestone birthday
- Trip type - FIT, small group, multi-generational family, incentive - and lead time to departure, usually your strongest sorting signal
Routing is half the value
Extraction on its own just makes a tidier list. The gain comes from what you do with the fields, because a honeymoon to Kenya eleven months out and a family of five trying to leave in three weeks are not the same job and should not land in the same undifferentiated queue.
Lead time is usually the cleanest rule to start with. Anything departing inside a few weeks needs a specialist who can check live availability today; anything a year out can wait until the afternoon without costing you the booking. After that, route by destination expertise, because the consultant who knows the ground handler is the one who converts.
This is also where you catch the enquiries that should never have reached a consultant at all - the supplier pitches, the students asking for dissertation help, the traveller who wants a flight you do not sell. Sorting those out before anyone opens them is not glamorous, and it is the fastest hour you will get back.
Draft the first response, never send it
Once the enquiry is structured, the next step is drafting - not sending. That distinction is the whole ballgame.
A drafting assistant sits in your inbox or CRM and produces a first reply that already references the right region, season and party size, and asks a sensible next question. Your consultant reads it, deletes what is wrong, adds the line only they could write - the guide they trust in that valley, the reason not to walk the Inca Trail in February - and sends. They are still the author. They just did not start from a blank page with a full queue behind it.
The gain is not eloquence; your team already writes well. It is that the twelfth reply of the day is as good as the first, and that a Friday-night enquiry gets a real answer on Saturday.
Be strict about what goes into that draft: it answers the question, shows knowledge, moves to the next step. It does not quote a price, hold a room, or promise a departure.
Itinerary drafting: automate the scaffolding, not the judgement
Everyone wants to start here, and it belongs third. Itinerary quality is where your margin actually lives, and a plausible-sounding itinerary is far more dangerous than a plausible-sounding email.
Used well, a model handles the scaffolding: turning a consultant's shorthand into day-by-day prose, rewriting the same lodge description for a honeymoon couple and for a family with a nine-year-old, or producing the German version of a proposal written in English.
It is bad at exactly what makes an itinerary bookable. It does not know your ground handler stopped taking bookings in that region, that the internal flight only runs Tuesdays and Fridays after October, or that your allotment at that camp covers two nights of the four. Those facts live in contracting, rate sheets and your operations team's heads; if the model cannot read them, it will confidently fill the gap.
So the consultant chooses route, properties and sequencing; the model writes it up. The consultant then checks every named supplier, transfer and date against real availability before it leaves the building.
Never automate a promise a traveller can rely on
There is a hard line, and it is not a matter of taste. In the EU, the Package Travel Directive (Directive (EU) 2015/2302) provides at Article 6 that key pre-contractual information given to the traveller - including the price and the main characteristics of the travel services - forms an integral part of the package travel contract and shall not be altered unless the contracting parties expressly agree otherwise. If an automated system tells a traveller €3,890 per person and that figure is wrong, that is not a marketing problem. It is a contract problem.
GDPR Article 22 covers the other half: people have the right not to be subject to decisions based solely on automated processing that produce legal effects or similarly significantly affect them, and where such processing is permitted, Article 22(3) requires safeguards including at minimum human intervention, the right to express a point of view and the right to contest. Auto-declining a group booking is not where you save fifteen minutes.
- Prices, per-pax rates and supplements - anything a traveller could screenshot and hold you to
- Availability: never let a system say yes to a room, seat, departure or permit
- Deposit amounts, payment deadlines, cancellation and refund outcomes
- Visa, vaccination and entry requirements, which change faster than any content library
- Safety, medical and accessibility answers, where a wrong reassurance is real-world harm
- Final sign-off on a client-facing proposal - a human name goes on it or it does not go
Data hygiene is the prerequisite nobody sells you
AI projects in travel tend to fail on the data rather than on the model. The demo works because the demo was built on a clean input: one tidy enquiry, one destination, one departure date. Yours do not arrive like that.
If enquiries land in three inboxes, a WhatsApp number someone hands out at trade shows, and a form that mails a shared account, nothing can triage them, because there is no single queue to triage. If the same traveller exists four times under three spellings - once from a brochure request, once from the enquiry form, once from the trip they took two years ago - follow-up automation will send a returning guest a first-timer welcome. And if nobody has agreed what counts as a qualified enquiry, you cannot measure improvement, because the denominator keeps moving: does a family asking about somewhere in Asia, maybe next August, count or not?
Fix this before buying anything. One front door for enquiries. A short set of required fields, enforced. Deduplication on email plus phone. Written stage definitions - enquiry, qualified, proposal sent, deposit paid, booked, travelled - used the same way by everyone, including the person covering reservations in August.
A travel-specific CRM helps because it already understands departures, per-pax pricing and deposit schedules instead of forcing them into custom fields; we built OpenVoy for that reason. But the discipline matters more than the tool: a tidy spreadsheet beats a messy CRM, and both beat a clever model reading rubbish.
Follow-up and reporting: the boring wins that compound
Once triage and drafting are running, the fourth layer quietly pays for the first three. Long consideration windows mean most lost revenue does not leak at the enquiry stage. It leaks out of proposals nobody chased.
Keep follow-up assistive, not autonomous. Instead of a machine emailing your prospect on day seven, have it surface a ranked list each morning: these eleven proposals are over five days old, this one departs in nine weeks so the decision window is closing, this traveller opened the itinerary four times yesterday. Your consultant sends something human. You get the discipline of a sequence without the smell of one.
Reporting is the other easy win, because the work is mechanical. Pulling enquiries by source, cost per enquiry, conversion by stage, average booking value and lead time out of ad platforms, your booking system and the CRM is not a job for a human on a Monday. Automate the assembly, never the interpretation - a channel that looks expensive per enquiry may be the one bringing the fourteen-night trips.
Count hours saved and bookings gained separately
Hours saved is capacity; bookings gained is revenue. Conflating them is how AI projects get quietly cancelled a year in, because only one of the two reaches your bank account, and only if those hours get redeployed into something that sells. Travel makes the trap sharper: the hours are saved in the booking season, and the money arrives on deposit and departure, months later and in a different quarter.
What follows is purely illustrative - invented numbers to show the shape of the sum, not benchmarks, and no substitute for your own. Say you take 300 enquiries a month and assisted triage plus drafting saves 15 minutes each: 300 x 15 = 4,500 minutes, or 75 hours. At a loaded €35 an hour, that is roughly €2,625 of released capacity - real, but not revenue until those hours become more proposals or one fewer seasonal hire.
Now the revenue side, same illustration. Say enquiry-to-booking runs at 8 percent, average trip value is €4,200 and margin is 12 percent, so €504 of gross margin per booking. 300 enquiries at 8 percent is 24 bookings, about €12,100 a month. Lift conversion to 9 percent and you get 27 bookings, roughly €13,600: about €1,500 a month, or €18,000 a year, from one percentage point.
In that illustration the point of conversion is worth several times the hours, which is the argument for measuring it properly - compare the same months year on year, or run half your enquiry flow assisted for six weeks. Otherwise seasonality takes the credit and the blame, and a strong shoulder season will convince you the tooling works when it was the weather. And because deposits land weeks after the enquiry, be patient: if your median lead time is eleven weeks, you cannot judge conversion after three.
The mistakes I see most, and what to do instead
Nearly all of these are the same error: treating AI as a replacement for a person rather than leverage on one.
- Starting with a public-facing chatbot - the one place a hallucinated price reaches a traveller with nobody in between. Start behind the glass, in the inbox.
- Bloating the enquiry form. Twelve qualifying questions just means fewer people finish it, and the ones who do are the ones who were booking anyway. Keep it short and let the assistant extract.
- Letting the model invent product. Any lodge, guide or route it names gets checked against contracted inventory before it goes out.
- Buying the platform before fixing the data. This costs the most and hurts the longest, and you tend to discover it mid-season.
- No named owner. One person owns the templates, prompts and guardrails and reviews real outputs weekly. This is the first job dropped when the season starts, which is exactly when the outputs need watching.
- Measuring adoption instead of outcomes. Drafts generated is not a result. Time to first response, proposals per consultant and conversion by stage are.
- Forgetting disclosure. Article 50 of the EU AI Act (Regulation (EU) 2024/1689) requires systems intended to interact directly with people to inform them they are dealing with an AI, in a clear and distinguishable manner and at the latest at the time of first interaction, unless that is obvious. Those obligations apply from 2 August 2026, and Article 99 places non-compliance in a band reaching €15 million or 3 percent of total worldwide annual turnover, whichever is higher. A line buried in your terms is not clear and distinguishable.
Your first ninety days, in order
In this order, each step makes the next one cheaper. In the wrong order, each makes the next one harder. Pick ninety days that are not your peak booking window, because the one thing that guarantees failure is asking reservations to redesign the process during the month they are drowning.
Weeks one to three: fix the front door. One queue, agreed required fields, duplicates merged, stage definitions written down and used. Record your baseline too - median time to first response, enquiry-to-proposal and proposal-to-deposit rates, average booking value, average lead time. You cannot reconstruct it later.
Weeks four to six: triage only. Extract and route, no drafting. Let the team correct the extraction for a fortnight and watch where it fails. Expect the stated facts - dates, party size, destination - to settle first, because the traveller wrote them down; expect the inferred ones, budget above all, to be the extraction you are still correcting at the end, because you are asking the model to read intent out of the words honeymoon and business class.
Weeks seven to ten: first-response drafting, with a hard rule that nothing sends without a human pressing send. Build a small library of approved openings for your commonest enquiry types and let the assistant adapt those. Add a disclosure line anywhere a traveller might be talking to a system.
Weeks eleven to thirteen: itinerary scaffolding for one product line, plus the morning follow-up list. One line only, so you meet the failure modes on familiar ground - preferably the product your team knows well enough to spot a wrong transfer time at a glance.
Then look at your baseline again and be honest about which number moved. If time to first response halved and conversion did not budge, speed was never your bottleneck - it is your proposal, your pricing or your product, and no automation fixes that. Better to learn that in ninety days than in three years.