TravelCRM
TravelCRM is a travel agency CRM we designed and built in Laravel, Vue and PostgreSQL on AWS, now running in production. It replaces the spreadsheet-and-inbox stack agencies typically outgrow, covering enquiries, quoting, bookings, itineraries, supplier settlement and payments in one system.
The problem
Travel agencies run on a sequence that no general-purpose tool models properly. An enquiry arrives — by email, phone, WhatsApp or social — and has to become a quote, often several quotes as dates and cabins change. A quote becomes a booking with components from different suppliers, each with its own deposit schedule and balance due date. Then somebody has to work out what each supplier is owed and what the agency actually made.
Most agencies hold that together with spreadsheets and an inbox. It works while one or two people remember everything, and it fails quietly: an enquiry nobody followed up over a weekend, a quote rebuilt from scratch because the original could not be found, a supplier balance discovered late. The cost is rarely a dramatic failure — it is margin and enquiries leaking steadily.
What we built
- A unified enquiry inbox, so an enquiry has one record regardless of which channel it arrived through.
- Branded quoting with reusable templates, so a variation is a change rather than a rebuild.
- Bookings and itineraries modelled as multi-component records rather than flat line items.
- Supplier settlement — what is owed to whom, and what remains after it.
- Payments and deposits, including staged balances.
- Automated follow-ups on enquiries that have gone quiet.
- Team roles and reporting built on travel’s own shape rather than generic CRM dashboards.
Why this stack
| Layer | Choice | Reasoning |
|---|---|---|
| Backend | Laravel | Strong conventions matter on a product expected to be maintained for years by more than one developer |
| Front end | Vue | The interface is genuinely application-like — quote building is interactive, not a sequence of page loads |
| Data | PostgreSQL | Bookings, components, suppliers and payments are relational. Settlement needs integrity guarantees, not eventual consistency |
| Infrastructure | AWS | Managed services keep the operational burden proportionate to a focused product |
The part that was genuinely hard
Settlement. Quoting and bookings are well-understood problems; reconciling what multiple suppliers are owed across components, deposits and staged balances is where travel software usually either gets vague or pushes the work back into a spreadsheet. Modelling it properly — so a number can be traced back to the components that produced it — determined much of the data design underneath everything else.
TravelCRM is our own product and is actively developed. The product page covers what it does today. If you run a travel business and want something similar — or want this adapted to how you work — get in touch.