Tour operator software, part by part, and what to buy first.

Ask around and no two UK operators describe tour operator software the same way. The name covers a list of jobs instead of one product. It means holding what you sell, pricing it, putting it in front of resellers, collecting money to a schedule, running the departure, and remembering who asked about what. Some buy the lot from one supplier; more run a few tools alongside a spreadsheet that one person understands.

Hardly any operator needs every row at once, and which row to buy first depends on how you sell rather than how big you are.

Fixed-departure and tailor-made operators need almost opposite halves of the same software. A demo that skips over the difference will spend the whole session on screens you would never open.

• Series departures. Inventory is the centre. Places per date, allocation released on a deadline you cannot miss, minimum numbers deciding whether a departure runs, a rooming list balancing singles against shares.
• Tailor-made and FIT. Costing is the centre. Components priced by season, room type and party size; a quote that goes through versions as the client moves a night; margin recalculated before they see the new figure.
• Day tours and groups. Day tours run on slot capacity and changes made on the morning itself. Group bookings run on provisional holds, release deadlines and a payment schedule agreed per group. A general-purpose system tends to creak on both.

A tour operator CRM is the part that remembers people. Reservations remembers bookings. The CRM remembers the enquiry that has yet to become one — which trip, which departure, how many travelling, what was quoted and in which version, who promised to reply, and where the traveller came from. The source field is what ties a season's marketing spend to the enquiries it produced, and it is only as accurate as whoever fills it in.

Search travel agency software or travel agency CRM and you end up in the same catalogues, fairly enough — the parts overlap. What differs is what sits at the centre. A retail agency sells other people's product, so its records are built around suppliers: a customer, a supplier reference, commission to reconcile. An operator owns the inventory, so its records are built around departures: capacity, costs and margin. A demo showing supplier connections when you asked about departure capacity is agency software with an operator's label on it.

A CRM starts working only once somebody writes to you. It organises the enquiries you already have; getting more of them is a different job.

Every part of the stack starts with an enquiry. Picture what happens just before one: a stranger reading your trip page on a Sunday evening, two competitors open in other tabs, and a short list of questions your page has left unanswered.

• What the price includes. Transfers, entrance fees, meals, tips, the internal flight. Travellers ask where the line falls between included and extra, even when the page already spells it out.
• How fit is fit enough. "Moderate" is precise to you and meaningless to somebody with a rebuilt knee. They want daily distance, ascent, and what is underfoot.
• Who else will be there. Group size, age range, whether they will be the only one travelling alone. Trip pages usually say all this, and travellers rarely find it.
• The single supplement. A solo traveller wants the figure, or the room-share terms, before writing to anybody. If you have yet to price that departure, the honest answer is to say so.
• What happens if plans change. Cancellation windows, transfer terms and balance deadlines sit in your booking conditions, which almost nobody reads. What the terms say can be answered from the page; whether a refund is granted stays a decision for your office.

Every one of those answers is on your website already, so it was never a content problem. What is missing is somebody to hand it over at the hour the traveller is reading. When the page says nothing, the traveller clicks one of the other tabs.

That gap is what Adoomi covers, and the job is a narrow one. It is a chat window on your own site that has already read what you publish — the itinerary, what the price covers, the grading, group size and age range, kit lists, your booking conditions. It answers from those pages in the traveller's language, at whatever hour they are reading. Then it writes the enquiry down: which trip, which departure, how many travelling, who needs a room alone, and what is still undecided. That reaches whoever you name as an email alert, or the traveller carries on over WhatsApp with their own wording attached.

That is the half the rest of the stack leaves alone: the questions asked while somebody is still deciding. The enquiry that reaches your reservations team already has the trip, the date and the number travelling on it. The tour operators page works through it section by section, and guardrails and handoff shows a refusal in full.

Why an "AI travel agent" search points somewhere else

Two products share a name here and do opposite jobs. An AI travel agent, in the consumer sense, plans trips for travellers: suggesting destinations, assembling an itinerary, then sending them off to book elsewhere. Its customer is the holidaymaker. What this page describes is bought by the operator, answers only from that operator's published pages, and recommends nothing. A demo that starts telling somebody where to go belongs on a different page.

Three questions always go to a person, whatever else is asked: what your financial protection actually covers, whether a refund or a transfer will be granted, and whether a trip suits somebody's mobility. Each one reaches the person you nominate for it — office manager, tour leader — quoting the traveller directly, and a dietary question about an included meal goes the same way. None of that, on its own, makes you compliant with anything: that stays with your registrations, policies and terms.

Few suppliers here publish a price, so what you are comparing is how they charge. Reservations and distribution platforms tend to take a commission per booking or a fee per passenger, so the invoice climbs with a good season. Others charge a monthly fee per user, which is steady until you take on extra reservations staff for the summer. Some set their tiers by how many bookings you take in a year. Ask what implementation and migration cost before anything goes into a contract, and what happens to your data the day you leave. Card processing sits outside all of it.

Adoomi charges a flat monthly price. The Free plan costs £0 a month and comes with 50 message credits; each answer uses one credit. The paid plans are Local at £8 a month for 200 credits, Growth at £20 for 500, and Scale at £75 for 4,000, and the pricing page lists them all. Going live takes about ten minutes: point it at your trip pages and booking conditions, read what it drafts before any traveller does, then add one line to your site.

Ask every supplier here where a traveller's words end up. In Adoomi's case: conversations sit on EU infrastructure, GDPR export and deletion come with the product, logs hold identifiers in place of the message itself, and tracking cookies stay out of the chat window entirely.

There is no single ranking, because the right first purchase is wherever you are losing money. Here are four operators and four different answers.

1. Two people edit the same departure. Reservations first. Fixing a capacity table later is harder than adding any of the other parts, and selling one place twice costs more than any subscription here.
2. Follow-ups depend on somebody remembering. The CRM first. Quote versions, a source field and a date against every enquiry: the cheapest part to adopt, and the one that stops a Friday promise being forgotten.
3. Reseller bookings get re-keyed by hand. Distribution first. Re-keying by hand is where the double-sold place comes from, and being careful has already failed to stop it.
4. The trip pages get read, and nobody writes. The website side, cheapest of the four to test. Point it at your own pages, aim your most awkward supplement question at it, and judge what comes back before a traveller ever sees an answer.