Multiple Travellers, Multiple Suppliers, One Group: How We Replaced Spreadsheet-Driven Tour Operations

Industry:

Dating

Platforms:

Web App

Project Summary

A trade-only wholesaler ran a 150-person, three-city alumni tour from one master workbook that only one coordinator could safely edit. We replaced it with a linked operations record, so one change now reaches every supplier it affects.

Client

US wholesaler of European travel, selling only through advisors

Group

About 150 alumni on a 12-day Prague, Vienna and Budapest tour

Problem

A master workbook that copied every traveller into a tab per supplier

What we built

One operations record linking travellers to services, with manifests generated per supplier

Delivery

One departure run in parallel, then new groups first

About the Client

The operator doesn't sell to the public. Advisors build itineraries on its trade portal or call its reservations team, and it contracts the hotels, transfers, guides and sightseeing behind them. Most of its business is tailored independent travel.

Its booking system handles that well: each advisor booking is a separate file with its own client, commission and terms. But an association's members book through their own advisors, so one group arrives as many separate bookings that the system doesn't know belong together.

The Challenge

The alumni tour needed four hotels (two in Vienna, as no single property could take the block), three coaches, transfers from several US gateways, local guides, group dinners, and two optional extras bought by part of the group. Over a dozen suppliers each needed a different slice of the same traveller list.

It all lived in "the master", a clever workbook with a tab per supplier, kept by one senior coordinator. It failed one change at a time:

Every tab was a copy, not a view. Names were pasted into the rooming, coach, transfer and meal tabs, so each traveller existed many times over: the traveller data re-entry problem at scale.
Nothing knew which suppliers a change touched. A retimed flight affects transfers, a hotel, a coach and a dinner; working that out was memory.
Suppliers drifted apart. Each hotel's rooming list, including the split Vienna block, was right when sent and wrong a week later.
Sent wasn't confirmed. The status tab logged emails, not whether a restaurant had actually updated its list.
On her days off, nobody could safely change it.

Why This Approach

Option	Where it fits	Why it did or didn't fit here
A better, shared online spreadsheet	One small group a season, in one city	Removes emailed copies, not copied tabs; formulas can't show which suppliers a change affects
A standalone group product	Operators who book and collect for the whole group	The travellers were advisor bookings whose commissions and terms had to stay in the booking system
A linked operations record beside the booking system	Operators whose bookings work but group operations don't	Chosen: it reads tagged advisor bookings and leaves booking, commission and payments alone

The connection to the booking system was kept deliberately light. For a deeper integration that adds group bookings and payments inside a platform, see how an operator added a group module without replacing its booking system.

What We Built

The design rule: a traveller is entered once, and every supplier list is a view of that record.

The key is the assignment. A traveller's room in Vienna, their coach, their transfer slot and their dinner choice are links to services, not rows retyped in four tabs.

Component	What it does	Gap it closes
Group and services	Each supplier commitment (a hotel block, a coach, a dinner) as one service	No record of the group as a whole
Traveller record	Passport name, advisor agency, booking reference, dietary and mobility needs	The same person pasted into a dozen tabs
Assignments	Which traveller is on which service, with their room share or meal choice	Changes copied tab by tab
Arrivals	Each PNR or own-flight arrival, linked to its transfer and first night	No link between a flight and what depends on it
Manifest versions	What went to each supplier, when, in its format, and its acknowledgement	"Sent" logged, never "confirmed"

Colleagues can now cover the coordinator safely, tour managers see their own coach on the day, and advisors see no change.

How It Works Now

Set up services

For each hotel block, coach, transfer slot, dinner and extra.

Bring travellers in from advisor bookings

Tagged bookings appear with agency and reference; nobody retypes a name.

Assign travellers to services

With defaults where everyone shares one, such as the farewell dinner.

Generate manifests

For each supplier in the format it already uses.

Send and track

Each send is a dated version, "awaiting acknowledgement" until the reply is logged; this is confirmation as a discipline, built in.

Change once, see the impact

The record lists every service and manifest a change makes out of date.

In Practice: One Retimed Flight, Every Supplier It Touched

Ten days before departure, the consolidator moved one gateway's flight into Prague. Eight travellers would land five hours later, in the evening.

Before, the coordinator worked out every consequence herself, and the welcome dinner was the step most often forgotten.

Now she updates the arrival once, and the record lists every service that depends on it: the transfer, the first night in Prague, the welcome dinner and the tour manager's list. She moves the eight to the evening transfer and agrees a late meal with the restaurant; the system records that decision, it doesn't make it. Two land-only travellers sharing rooms with people on that flight stay on their own arrival, so nobody is moved by mistake. New manifest versions go to the transfer company, the hotel and the restaurant. When the restaurant hasn't acknowledged two days later, its manifest appears on the open items and a colleague follows up.

Delivery and Scope

Other groups were live on their own workbooks, so there was no clean start. We walked every tab with the coordinator, turning rules she applied by eye (such as which Vienna hotel took overflow rooms) into fields. Travellers were matched to advisor bookings by reference, not name. One departure ran in both systems until the manifests matched; then new groups started in the record while groups close to travel finished on their workbooks. For a full system migration, see moving a legacy group system to the cloud between seasons.

Results

Area	Master workbook	Operations record
Traveller data	Entered once, copied into many tabs	Entered once, linked to every service
Impact of a change	Worked out from memory	Listed by the system, service by service
Supplier manifests	Filtered and pasted per supplier	Generated in each supplier's format
Confirmation	"Sent" noted in a status tab	Each version tracked to acknowledgement
Cover during absence	One person knew the tabs	Any colleague can work the record

The team no longer spends the last weeks before departure reconciling tabs. And a second multi-city group no longer means a second workbook only one person can edit, the real limit of running large group tours on tools built for individual bookings.

Lessons for Tour Operators

Count the copies, not the tabs.

The warning sign is the same traveller pasted into many places.

Model the link between a traveller and a service.

Most group errors are right data that never reached one supplier.

Write down the rules your coordinator applies by eye before you build.

Keep the suppliers' world the same.

The change belongs inside the operator, not in the formats suppliers receive.

If your platform runs your business but buckles when a large group arrives, see how we build custom group travel management solutions for tour operators.