A travel agency's booking desk, rebuilt as a system.
Bookings lived in one person's inbox. Customers rang to ask where their itinerary had got to, and somebody had to go and find out. Here's what we changed, and what it took.
The situation
The agency sold packaged itineraries — hill stations, multi-day tours, custom trips. Business was good. The problem wasn't demand; it was that every booking touched the same person, and that person was a bottleneck with a phone.
Enquiries arrived by phone, email, Instagram and WhatsApp. Each one was written into a shared spreadsheet, sometimes. Confirmations were typed manually. And once a customer had booked, the only way to learn anything about their own booking was to call the office and wait while someone checked.
What was actually broken
Three things, and they compounded on each other.
Bookings had no home. A booking existed as an email thread, a WhatsApp conversation, a spreadsheet row and a memory — four places, none of them authoritative. Reconciling them was a daily job nobody had been hired to do.
Status was invisible to the customer. Every update required a human to write it. Which meant most updates never got written, which meant customers called, which meant staff stopped working to answer.
Peak season made it worse. The weeks with the most bookings were the weeks with the least time to manage them properly.
- Enquiries spread across four channels
- Bookings tracked in a shared sheet, manually
- Confirmations typed by hand, when remembered
- Status only available by phone call
- No record of who owned which booking
- Peak season handled by working later
- One form per itinerary, on the site itself
- Every booking lands in a single pipeline
- Confirmation sends itself in seconds
- Customer panel updates on its own
- Owner and timestamp on every record
- Same process at 5 bookings or 50
What we built
The design decision that made everything else work: put the booking form on the itinerary page itself. Not a generic "contact us" page, not a separate enquiry form — a short form attached to the specific trip the customer is already reading about.
That single choice meant every booking arrived with its context already attached. No one had to ask "which package?" ever again.
Customer books from an itinerary page
A short form sits on the itinerary itself. No separate enquiry page, no lost context, no follow-up question about which trip they meant.
The booking lands in the pipeline
Deduplicated against existing records, tagged to the itinerary, assigned an owner, timestamped. It now has one authoritative home.
Confirmation goes out in seconds
Sent automatically with the itinerary attached and a link to the customer's own panel. Nobody typed it.
Staff move the booking forward
One status change in the pipeline — enquiry, confirmed, documents received, paid, travelling, complete. That is the entire action required of the team.
The customer's panel updates itself
No email written, no call made, no "just checking on my booking." The status change is the communication.
How it's put together
Power Automate handles the orchestration: it receives the form submission from the website, writes the booking record, sends the confirmation, and pushes each status change back out to the customer panel. The website already existed — we wired into it rather than replacing it.
Deliberately unglamorous. There was no need for a custom application, a new database platform, or a migration project. The agency's existing Microsoft licensing covered the automation layer, which meant the running cost was close to nothing and the whole thing could be handed over without a support contract.
What changed
The number worth stating plainly: zero status emails are now written by hand. Not fewer — none. The category of work disappeared rather than shrinking.
Beyond that, the booking record became something the agency could actually reason about. Who owns this? When did it arrive? What stage is it at? Those questions used to require asking a person. Now they're properties of the record.
We built the pipeline before we'd fully mapped what happens when a booking goes backwards — a customer postpones, or changes a date, or cancels after paying a deposit. Forward motion was designed carefully; reversals were handled later, as patches. On the next build of this kind, we'd map the unhappy paths at the same time as the happy one. It costs a day of thinking and saves a fortnight of retrofitting.
Where this goes next
This is the system we'd productise first. Twenty travel agencies need close to the same thing — a form on the itinerary, a pipeline behind it, a panel the customer can check. That's the test for whether something is a service or a product, and this one passes it.