Sales, ticketing, finance and operations — unifying a travel business onto one platform.
Published September 12, 2026 · Asneh Technology Team
We're currently building a Travel ERP & CRM platform for a travel business client. The project is still in progress, so this post isn't a case study of finished results — it's a look at the problem we're solving and the decisions we've made so far, in case they're useful to anyone else thinking about software for a travel agency or tour operator. (We're keeping the client's name out of this post while the engagement is ongoing.)
Most travel businesses we've talked to run on a mix of spreadsheets, a booking tool, WhatsApp for customer communication, and a separate system (or none at all) for accounting and refunds. Each part works fine on its own, but nothing talks to anything else. A sales lead doesn't automatically become a booking. A refund approved by finance doesn't automatically update the operations team. Nobody has one place to see the full picture of a customer's journey — from first enquiry to trip completion to any post-trip issue.
That's the gap this platform is meant to close: one system where sales, ticketing, logistics, finance, and operations all see the same data, instead of five disconnected tools.
Rather than building one monolithic "do everything" screen, we split the platform into modules that map to how a travel business actually works day to day:
A founder needs a different view than a sales rep, and a sales rep needs a different view than someone processing refunds. So instead of one generic dashboard, we built role-based logins — Admin, Sales, Tickets, Logistics, Finance, Operations, and Founder each see a dashboard scoped to what they actually need to act on, with the underlying data shared across all of them. That's the core idea of an ERP: everyone works from the same source of truth, but nobody has to wade through screens meant for a different job.
We're building this on the same stack we use for most of our custom SaaS work: a Node.js backend with a PostgreSQL database (so bookings, payments, and customer records stay relationally consistent instead of getting duplicated across tools), and a React frontend for the dashboards. Authentication is role-based from day one rather than bolted on later, since the whole value of the platform depends on each role only seeing what's relevant to them.
Being honest about where things stand: we're still refining the finance-approval workflow (getting the right balance between speed and proper sign-off), and we're testing how the logistics module should handle multi-vendor trips where more than one supplier is involved in a single booking. Neither of those is solved yet — they're the kind of thing that only becomes clear once real users start pushing on the system.
Most companies write about software only after it ships, once everything looks tidy. We'd rather be upfront that this is unfinished — the modules above are built and being tested, not yet a finished product with results to report. We'll follow up with a second post once the platform is live with real usage.
If you run a travel business and any of this sounds familiar — bookings, payments, and customer records living in three different places — get in touch, we're happy to talk through what a similar system could look like for you.
Whether it's travel, retail, or services — if your team is stitching together spreadsheets and separate tools, we can help you think through a unified system.