Digital transformation for an operator still running on spreadsheets

The operator sold multi-day guided itineraries through three channels: a website that could take enquiries but not confirm a booking, a call centre, and a network of travel agents. Every channel ultimately reached the same place — a reservations team keying bookings into a system installed more than a decade earlier.

Inventory lived in spreadsheets. Departure capacity, hotel room blocks, coach seats, and guide allocation were tracked in workbooks maintained by different people, reconciled by hand, and shared by email. That reconciliation gap was directly responsible for double-selling roughly two percent of bookings, each of which was resolved by upgrading a customer at the operator’s expense.

Agents phoned to check availability because they had no other way to see it, which consumed reservations team capacity that should have been converting direct enquiries. In peak booking season the phone queue itself became the constraint on revenue.

The reservation system could not expose an interface, so the website could never confirm in real time. Customers who wanted to book at eleven at night received a callback the following afternoon, by which point a meaningful share had booked elsewhere.

Two consultancies had proposed replacing everything. Both proposals were large, sequenced by system age, and would have delivered nothing usable for well over a year — which the business, running on seasonal cash flow, could not fund on faith.

The objectives: stop losing bookings to double-selling, give agents and the website real-time availability, take direct bookings without a human in the loop, retire the spreadsheets, and sequence the programme so that early stages funded the later ones.

The programme was sequenced by revenue impact, not by system age. The oldest system was not the most expensive problem; the spreadsheets were. Inventory was therefore addressed first, and everything else was ordered behind it.

Stage one built a single inventory service holding departures, capacity, and component allocation as authoritative data with real-time availability. It was populated from the spreadsheets, run in parallel for a full booking cycle with daily reconciliation, and only then made the source of truth. Double-selling stopped at that point, which is what made the programme self-funding before stage two began.

Stage two put an availability API in front of that service and gave agents a portal to check and hold inventory themselves. Reservations team call volume fell immediately, freeing the capacity that stage three needed.

Stage three replaced the customer-facing booking journey. The website moved from enquiry capture to confirmed booking with payment, reading live availability from the inventory service. The legacy reservation system stayed in place initially as a record-keeping system, fed automatically rather than by keying.

Stage four retired the legacy reservation system and the remaining ancillary spreadsheets, once every function it performed was either replaced or demonstrably unused. This was the last stage rather than the first because it carried the least revenue upside and the most operational risk.

Throughout, the operating model changed alongside the software. Reservations staff moved from data entry into exception handling and complex itinerary sales, and the operator kept a small internal product function that Webneuron helped establish rather than owning it permanently.