A tour operations CRM should do more than record a booking. It should connect tours, travellers, rooms, documents, payments, invoices, vendor payments and reminders so the operations team can see what is ready, what is missing and what needs action next.
Who This Is Built For
Tour operators replacing spreadsheet-based trip operations
Travel management companies coordinating travellers, suppliers, documents and payments
Operations and finance teams that need one source of truth after a booking is confirmed
Teams that need role-aware access to operational and financial records
Project Overview
Prapanch needed a full-featured Tour Operations CRM for the work that happens after a tour is sold. The system brings tours, bookings, travellers, crew, documents, payments, invoices, vendor payments and financial reporting into one operational workspace instead of leaving each part in separate spreadsheets or manual trackers.
The challenge was not just creating forms. A booking can contain multiple travellers, rooms, services, documents, payment events and operational units. The system had to keep those records connected while remaining fast enough for teams working through large tables and permission-sensitive workflows.
What Challenge Were We Solving?
Spreadsheet workflows made it difficult to answer basic operational questions: which traveller document is missing, which flight or hotel is still unbooked, which payment is pending, which vendor needs to be paid and which departure needs attention. Manual updates also made derived payment status and invoice state easy to misread.
The team needed a system that could model the real relationships in a tour operation without forcing staff to repeat the same data across unrelated screens.
Our Approach
We designed a SvelteKit frontend on Cloudflare Workers with a PocketBase backend in Go, organised inside a pnpm-workspaces monorepo. The interface uses a reusable DataTable with server-side pagination, faceted filters and text search so teams can work through operational records without loading everything at once.
A Zod-driven DynamicSheetForm keeps complex forms consistent while allowing different record types to define their own fields. Composite booking creation creates the booking, room allocations, travellers, documents, operational units and auto-generated invoice in one transaction.
What Made the System Fit the Workflow
The useful part of the product is the connection between records. Payment status is derived automatically from payment activity. A Go reminder worker regenerates reminders for flights and hotels not booked, payments pending, documents missing and departures approaching. Severity levels help teams prioritise work, while per-tour locking avoids duplicate reminders.
Access control is enforced in four layers: PocketBase database rules, SvelteKit route guards, server-side gates and UI-level gating. That keeps sensitive payment and vendor information protected even when someone bypasses a visual control.
Technical Architecture
Frontend: SvelteKit 2, Svelte 5 runes, TypeScript, Tailwind CSS 4, shadcn-svelte, TanStack Table and Superforms with Zod.
Backend: PocketBase with Go hooks and services for booking workflows, reminders and data rules.
Infrastructure: Cloudflare Workers, Docker and GitHub Actions, with pdf-lib and xlsx for document and export workflows.
Outcome
The resulting platform gives tour operations and finance teams a connected workspace for daily execution. It contains 18+ dashboard modules and 22 backend collections, supports one-transaction composite booking creation, derives payment status from activity and keeps reminders and permissions close to the underlying operational data.
Frequently Asked Questions
What is a tour operations CRM?
It is software that manages the operational records behind a tour business: tours, bookings, travellers, rooms, suppliers, documents, payments, invoices, reminders and reporting. A CRM focused only on leads does not cover this post-confirmation workflow.
What should tour operator software manage?
At minimum, it should connect bookings to travellers, rooms, services, documents, payment status, invoices, vendor payments and departure readiness. Search, filters, exports, reminders and role-based permissions become important as the operation grows.
Is a booking engine enough for a travel agency?
A booking engine can capture a reservation, but it usually does not provide the complete back-office view of documents, room allocations, pending balances, vendor payments, reminders and operational exceptions. Agencies with complex group or multi-service trips often need both.
When should a travel agency build custom operations software?
Custom software is worth considering when the team relies on spreadsheets for core operations, needs connected booking and finance records, has unusual approval or permission rules, or cannot represent its workflow in an off-the-shelf product without repeated manual work.
How should role-based access work in travel agency software?
Permissions should be enforced at the database, server route, page or loader and UI layers. Finance, operations, administrators and general staff should each see the records and actions appropriate to their responsibilities.
