Case Study: Peak Adventure Itinerary Planning
Short form
A spreadsheet format got a standing ovation. That’s not a metaphor — when Redgum demonstrated a clean, canonical layout for airline bulk pricing data, the operations team stood up. They’d been spending one to two weeks per person per month manually reformatting each airline’s data dump before it could be loaded and sold. Nobody had said it out loud, but the standing ovation did. PEAK Adventure Travel had consolidated thirty to forty adventure travel companies under one operational roof; Redgum’s job was to build the specialist systems that let that scale work.
The challenge
PEAK Adventure Travel was founded on a simple but powerful insight: small adventure travel operators — each running four, six, ten people on a tour — have no leverage with airlines. A group of six can’t negotiate bulk pricing. Thirty companies combined can. By consolidating purchasing power under a single entity while keeping each operator’s sub-brand visible in its local market, PEAK unlocked economics unavailable to any of them individually. The business went from a 30–50 person operation to more than 1,000 staff worldwide.
Behind the scenes, a single platform had to support all of it. PEAK had consolidated onto an Australian software platform with its own internal development team. Overnight, that team went from building for a small company to being the primary software supplier for an organisation ten to fifteen times larger. They needed specialist help on specific high-value projects while they kept up with the primary build. Two independent personal connections — one at team level, one at management — brought Redgum in. Instant credibility at both levels.
The most acute problem was airline pricing data. Every airline delivered bulk pricing in its own proprietary format. Before any of that data could be loaded into the main system and offered to customers, staff had to manually transform each airline’s dump into a usable form. The data was structured poorly — repeated slabs of information, high cognitive load, high risk of keying error. One to two weeks of staff time, per person, per month, consumed by format translation.
What we built
The first thing Redgum built was a canonical spreadsheet format. Clean structure, no repetition, designed for both humans and systems to work with without friction. When it was demonstrated to the operations team, they stood up and applauded. The quote that came back: “This is the best thing we’ve seen. Why isn’t everything this easy?”
That reaction was the tell. Nobody had fully articulated how much the format problem was costing — it had been absorbed into the rhythm of the month, invisible as overhead until it disappeared.
The canonical format became the foundation for an ingestion system that eliminated the manual reprocessing step entirely. Each airline’s data dump, regardless of source format, was transformed on ingest into the standard structure — ready to load, ready to sell, without staff intervention.
From there, Redgum built the trip planning system: a tool for assembling day-by-day itineraries from activities, accommodation, meals, and transport, combined into purchasable packages. It handled variance — customers flying from different home cities could be quoted the same tour at different prices depending on their departure point, with the right flights automatically threaded in. Those costs flowed into the main booking and costing system, so customers could be offered the best available flights at the point of purchase.
The three components — canonical data format, ingestion system, and trip planning tool — were built as specialist contributions to PEAK’s larger platform, integrated with the internal team’s primary build.
The outcome
The airline data processing work — one to two weeks per person per month — was returned. Error rates and cognitive load on data entry dropped sharply. The platform scaled from a 30–50 person operation to more than 1,000 staff worldwide; Redgum’s components were part of the system infrastructure that made that growth possible.
The clearest signal of impact was the one that came first: a standing ovation for a spreadsheet. When a data format earns that reaction, the pain it replaced was real.
The engagement ended not because of a performance issue but because a management shakeup shifted budget priorities away from forward investment. Many of the staff who had championed the project moved on around the same time. What the system became after that is unknown — but what it delivered before that decision was made is not.