We built Travel CRM because we ran a travel operation on a general-purpose sales CRM for eighteen months and watched it fail in the same three places every week.
A sales CRM models a deal: one prospect, one value, one close date, a pipeline of stages. That model is correct for software sales. It is wrong for travel in ways that are not cosmetic.
One: the supplier is a party to the deal
In a sales CRM the deal is between you and the customer. In travel there is a third party in every line item — the hotel, the airline, the DMC, the transport operator — and they have their own state.
That means a quote is not a number. It is a set of components, each with its own supplier, its own cost, its own margin and its own confirmation status. A trip can be 80% confirmed. A sales CRM has no vocabulary for that: the deal is open or closed.
The consequences are practical. When a supplier raises rates between quote and confirmation, you need to know which open quotes contain that component and what it does to each margin. In a generic tool, that means someone opening quotes one at a time. In a model that knows about components and suppliers, it is a query.
Two: hold dates are the real deadline
Sales CRMs have close dates. They are aspirational — a guess, moved when it slips, and nothing breaks when it does.
Travel has hold dates, which are the opposite. A hotel holds two rooms until 6pm tomorrow. At 6:01 the inventory is gone and the quote you sent is fiction. Nobody emails to tell you.
A hold is an obligation with a hard expiry, attached to a component rather than the trip, and several per trip with different expiries. The system has to know the earliest expiry across all components, warn before it passes, and mark the quote stale after it does. Modelling that as a "close date" reminder loses the two things that matter: which component expires, and what happens to the rest of the trip when it does.
This single object changes daily work more than anything else we built. Before it, the working day started by opening a spreadsheet to check what was expiring. After it, the system says so.
Three: the voucher is the deliverable
A sales CRM ends at "won." Travel starts there. What the customer actually receives is a voucher: the confirmation numbers, the addresses, the pickup times, the emergency contact, the terms.
That document has to be generated from the same data that produced the quote, or it will disagree with it. Every operator who has built vouchers by hand in a word processor has sent a customer a hotel they are no longer booked into, because the itinerary changed and the document did not.
So the voucher is not an export. It is a view over the same objects, regenerated whenever a component changes, versioned so you can see what the customer was sent and when. And it has an audience the CRM does not otherwise model: the traveller, who is often not the person who paid.
What we did with this
Three objects a sales CRM does not have — component, hold, voucher — and one relationship it models wrongly: the customer who pays is not always the person who travels.
Everything else is broadly familiar. There is a pipeline. There are stages. There is a dashboard with open enquiries and value. Those parts we did not need to reinvent, and we deliberately kept them recognisable, because an operations lead who has used a CRM before should not have to relearn the basics.
Would we tell you to build one?
Usually not. If you are running fewer than perhaps twenty trips a month, a spreadsheet plus a shared inbox genuinely works, and the discipline of a system costs more than it returns.
The threshold is not trip volume, it is how often two people need the same answer at the same time. When the question "has the Bali hold expired?" has to be asked of a person rather than a screen, and asked more than once a day, the spreadsheet has stopped being the cheap option.