Every Passenger Count Changed the Price: How We Automated Group Tour Pricing and Availability

Industry:

Dating

Platforms:

Web App

Every Passenger Count Changed the Price Hero Image

Project Summary

A family-owned operator priced each custom club tour once, in a workbook, and then watched the group change for months. We tied the costing to the live group, so every registration now reruns price and capacity, and people are alerted only when a threshold is crossed.

Client

Family-owned US operator running custom tours to Greece for clubs and associations

Group

A regional garden society, later joined by a second club, with an island stay

Problem

A price set at proposal stage that went stale with every registration

What we built

A costing model that reads live headcount, room mix and supplier capacity

Delivery

Recalculation automated; commercial decisions kept with people

About the Client

The operator sells scheduled departures to individual travellers through its website, and its booking system handles those well. Its second line, custom tours for garden societies, alumni chapters and museum members' groups, is smaller but higher-margin.

The product manager costs a 10-day itinerary and quotes a price per person in bands by group size. The contract fixes the bands, free places and confirmation dates. Then the organiser spends months recruiting members, who register through a group booking page.

The Challenge

The price was set at the proposal. The group only became real at final payment.

Everything in between was movement: people joined, dropped out, switched to single rooms, or arrived as a second club. Each change could move the band, the free places, the coach and guide cost per paying traveller, and whether a small island hotel still had enough rooms. It's the problem behind how group tour pricing breaks down when numbers keep changing, and here it showed up four ways:

The price was always out of date. Real numbers lived in the booking system and were compared with the costing only near final payment.
Band crossings went unnoticed. A group quoted at 40 or more could slip to 38 without anyone flagging the lower band or the lost free place, until travellers had paid.
Capacity was checked by email. Whether the island hotel could take three more rooms took days to answer while recruitment carried on.
Every recosting was a new copy. Sales, the product manager and accounts could each be looking at a different workbook.
Margin on a group was only really known after it had travelled.

Why This Approach

Option	Where it fits	Why it did or didn't fit here
A better costing workbook	Operators with a few simple groups a year	Still one assumed size per copy, and still blind to registrations
A generic pricing product	Operators whose rules match the common case	This operator's bands, free-place terms and supplements varied by club contract
The operator's own costing logic, connected to the live group	Operators with negotiated, group-specific terms	Chosen: it keeps the product manager's proven logic and makes it recalculate itself

What We Built

The design rule: describe each cost by how it behaves when the group changes, not just by what it costs.

Component	What it does	Gap it closes
Cost behaviours	Each cost is per group (guides), per vehicle (coaches), per room by occupancy (hotels) or per person (ferry, meals, entrances)	Fixed costs divided by an assumed headcount
Contract rules	Bands, free-place ratio, organiser's place, single supplement and target margin stored with each group	Rules hidden in copied formulas
Live inputs	Reads paying travellers, free places and requested room types from the booking system's registrations	A costing blind to real numbers
Service capacity	Allotment by room type and release date for each hotel, coach seats, the ferry allocation, restaurant maximums	Capacity checked by email
Costing versions	Every recalculation saved with its trigger and any decision taken	Workbook copies that diverged

The model keeps no traveller list of its own; it reads registrations from the booking system. Capacity is shown as headroom per service, the same calculation described in tracking group availability across supplier capacity, so price and availability are always read together.

How It Works Now

Cost the proposal

The model prices each band and shows how sensitive each one is to the share of solo travellers.

Contract the group

Bands, free-place terms, supplier capacities and the confirmation dates are stored on the group.

Recalculate on every change

Each registration, cancellation or room change reruns the band, cost per paying traveller, margin and headroom.

Alert at thresholds only

A band crossing, a gained or lost free place, a service short of capacity, or margin below target alerts the product manager; small moves stay quiet.

Decide and record

The choice (reprice, absorb, ask for space, or cap the group) is saved with the costing version.

In Practice: One Retimed Flight, Every Supplier It Touched

A garden society contracted three bands (20–29, 30–39, 40+ paying travellers), one free place per 20 payers, plus the organiser's place. Registrations settled at 31, in the middle band, with no alerts.

Then a neighbouring club asked to bring 11 members. Before saying yes, the product manager ran it as a what-if: 42 payers moved the group into the top band and earned a second free place, but the newcomers' single rooms overran the island allotment and the dinner exceeded the taverna's maximum. The operator secured extra island rooms and a second sitting before accepting.

Close to departure, five travellers withdrew, two leaving sharers alone in twins. The group fell to 37, lost its second free place and slipped below target margin, and the island hotel now had unused rooms past their release date. The operator chose to absorb the band change for a long-standing client, charge the single supplement only to the two affected travellers after speaking with them, and give the organiser a short window to refill. Each choice sits on the costing version.

Delivery and Scope

Automating the calculation is not automating the judgement. The system doesn't decide whether to reprice, since a long-standing club may matter more than one group's margin. It doesn't decide whether to accept more travellers. It knows the allotment a hotel contracted, not the hotel's own inventory. And because it was built around this operator's contracts, it isn't a generic product.

Results

Area	Before	After
When the price was checked	When someone remembered, usually near final payment	After every registration, cancellation or room change
Band crossings and free places	Noticed late, sometimes after travellers paid	Alerted as they happen
Supplier capacity	Asked by email, answered days later	Headroom per service, before saying yes
Margin on a group	Known after it travelled	Visible throughout recruitment
Decisions	Made in conversation, rarely written down	Recorded with the costing they relied on

The largest gain was timing. Experienced people still make the pricing calls; they now make them while there is time to recruit, renegotiate or ask a supplier for space. Seeing each band's sensitivity to solo travellers has also made proposals more realistic from the start.

Lessons for Tour Operators

Describe how each cost behaves. A costing that knows a coach from a hotel room can recalculate itself.

Price the room mix you have, not the one you assumed. Solo travellers change both cost and capacity.

Alert on thresholds, not on every change. Band crossings, free places, capacity and margin are what need a person.

Build pricing after the group data exists. Recalculation needs reliable headcount and room requests; start with linked traveller bookings or one group operations record.

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.