Enquiry to paid booking: what travel CRM software should do between "hi" and "booked"

1. Where enquiries actually go missing

Follow one enquiry through a typical desk. It arrives by email, or a web form, or a message on WhatsApp or social. Someone copies the details into a spreadsheet or CRM. An agent searches a booking engine in another tab, screenshots or pastes the options into a document, adds a markup by hand and emails a PDF. The client replies two days later. By then the fare has moved, the agent who quoted is on leave, and nobody can see which version the client was looking at.

None of those steps is unusual. The trouble is the number of hand-offs between systems that don't share a record. Each copy-and-paste step is a chance to quote a stale price, miss a follow-up or lose the conversation history. Fixing that takes a sales tool that's connected to inventory and orders. A tidier spreadsheet won't do it.

2. One queue, routed by rules

Step one is capture. Enquiries from web forms, email, WhatsApp and social messaging should land in one queue with the conversation attached, so the agent answers from one screen rather than four apps.

Assignment shouldn't depend on who happens to notice. Route by destination expertise, language, client tier or current workload, then set response-time targets with reminders and escalation when they slip. That's how a desk keeps the same standard at its busiest moments as at its quiet ones, and how a manager can see where response times are slipping without asking for a report.

3. Quote from live inventory, not from memory

This is the step that separates travel CRM software from a generic CRM with a travel template. The agent should pick live flights, hotels, transfers and activities from inside the CRM, apply markup rules and publish options in one place. They shouldn't be pasting results from another screen.

That only works if the CRM sits on the same supply layer as your booking channels. With a unified travel API underneath, a quote is made of the same typed components (offer, items, price, policies) that a booking will later use. So the thing the client accepts is the thing that gets booked. It isn't a description of it.

It matters most for complex itineraries. The question of dynamic packaging vs FIT operations usually comes down to this. A FIT trip assembled by an agent and a dynamic package assembled by rules should both price their components consistently and apply fees once. They should also produce one itinerary. If your CRM can only quote flights well, or only hotels, the rest of the trip goes back into documents.

Versions and expiry belong on the quote too. When a client asks for "the same, but a night longer", the agent should create version two, with version one still on the record and an expiry that reflects how long the prices can reasonably hold.

4. The quote is the point of sale

A PDF is a dead end. The client reads it, replies by email, and someone re-enters the choice. A better pattern publishes the quote as an interactive itinerary that renders well on a phone. The client compares options, picks one and pays securely from the same link, and the booking is created on the platform.

That changes how a quote does its job. Instead of describing what you could book, it becomes the checkout. It also gives you a clean record of what was offered, which version was accepted and when. That helps if a question comes up later about what the client agreed to.

5. Hand over without re-keying

Once a quote converts, the sale has to become operations. The booking should appear where your team already runs trips (for B2B desks, the Nucleus B2B portal), and post-booking questions should flow into support and ticketing in Pulse. The customer record should carry forward so a returning client is recognised next time.

On the integration side, ask whether order events are pushed or have to be polled. Webhooks for travel order events (order created, ticket issued, payment received) let your CRM, support desk and any in-house tools react the moment something changes. On Synapse, every order emits the same webhook stream across verticals, so a CRM built on it doesn't need a separate connector for each product line.

6. Questions to ask any travel CRM vendor

• Can agents build a quote from live flights, hotels, transfers and activities without leaving the CRM?
• Does an accepted quote create the booking on the platform, or does someone re-enter it?
• Are quote versions and expiry tracked on the record?
• Can the client choose between options and pay on the quote itself?
• Do web, email, WhatsApp and social enquiries land in one queue with history attached?
• Can routing use destination, language, client tier and workload?
• Are order events pushed by webhook, and are they the same across verticals?
• Is the customer record shared with support and loyalty, or copied into them?

If the answer to the first two is "export and import", you're buying a contact database, not travel CRM software.

7. Where Compass fits in the Elkanio suite

Elkanio Compass is our travel CRM. It does the work above on the same core as the rest of the suite. Enquiries from every channel land in one queue. Quotes are built from live inventory and published as interactive itineraries the client can accept and pay for. The booking then moves to Nucleus for operations and Pulse for support, and the customer record continues into Quantum for loyalty. Teams that need it can see response times, quote-to-booking conversion and margin per agent without exports.

Compass doesn't have to come first. Many travel management companies start with Nucleus and add Compass when the sales desk is the bottleneck. Because it shares the core, adding it later is configuration, not migration. If you're still deciding between a portal, a booking engine and an API, start with B2B travel portal vs booking engine vs travel API.

Bring three recent enquiries. We'll build and send the quotes in Compass during the demo.