Planning the travel & airline contact centre — booking curves, IROPS, the EU261 tail

Operations · Sector guide · ~7 minute read

Travel and airline contact-centre planning lives a double life. For most of the year, demand follows booking curves the planner can model months ahead; then a snow front, an ATC failure, or a fleet grounding converts thousands of itineraries into simultaneous rebookings within the hour. The plan has to hold both worlds — the predictable curve and the violent exception.

The booking curve — the predictable half

Calm-weather travel demand is unusually forecastable. The January booking peak lands every year; school-holiday departure windows are published years in advance and differ by region and country; sale events sit on the marketing calendar; and every booking generates a pre-departure contact curve — queries clustering in the final days before travel as passengers check baggage rules, seats, and documents. None of this should surprise the operation, and in a well-run one it does not.

The disciplined planner builds a driver-based forecast on the departures calendar and the booking ledger: contacts per booking by days-to-departure, by product, by market. That model converts forward bookings — data the airline already holds — into a contact forecast that leads the volume rather than trailing it. Pure time-series forecasting wastes the single biggest information advantage a travel planner has: the demand is already on the books.

IROPS — when one event becomes ten thousand calls

Irregular operations are the defining test. One cancelled wide-body strands hundreds of passengers; a snow day or an ATC systems failure cancels hundreds of flights; and every affected passenger needs rebooking, hotel arrangements, or duty-of-care answers at the same time. Volume can reach 5–10× baseline within the hour. The crucial framing: this is not new demand, it is a season of itinerary changes compressed into an afternoon — which is why no realistic steady-state roster can absorb it.

The countermeasure is a pre-named IROPS playbook keyed to operations-control alerts, not to a meeting convened once the queue is already failing. Weather gives 24–72 hours of warning to pre-position overtime banks agreed before the season starts; ATC and technical failures give none, so the playbook must run on triggers — cancellation-count thresholds that automatically invoke surge routing, scripted IVR messaging, and the cross-trained reserve pool. The first hour decides the shape of the next three days.

Channel behaviour under disruption — deflection collapses on cue

In fair weather, travel self-service performs well: app rebooking, chat, automated notifications carry a large share of contact. During disruption the pattern inverts. Anxious passengers under time pressure do not trust the app — especially when the app shows them the same zero availability that prompted the call — and everyone phones at once. Digital deflection collapses at exactly the moment volume peaks, and the plan built on average deflection rates fails precisely when it matters.

Staff the disruption scenario on disrupted-day deflection rates, not annual averages. Then attack the demand itself: proactive notifications carrying a working rebooking link, sent before the passenger reaches for the phone; IVR messaging honest about queue position and expected wait; and callback offers that genuinely hold their promised window — a broken callback promise during IROPS converts one contact into three. The operations that handle disruption well treat communication as capacity.

The EU261 tail — the surge after the surge

Disruption demand has a long tail the day-of plan never sees. EU261 and UK261 compensation claims arrive in the days and weeks after the event — typically building over 2–8 weeks — and they are not quick calls: documented decisions, eligibility assessment by cause category, and escalation routes to the CAA or ADR bodies when the passenger disputes the outcome. The event spikes the phones; the claims wave loads the casework queue.

Forecast the tail from the event log: claims per disrupted passenger varies predictably by cause (controllable technical issues drive far higher claim rates than extraordinary-circumstance weather), so each disruption event can be converted into a claims-volume forecast within a day of it ending. Carve the claims capacity out separately — absorbed into the front line, it silently erodes service for weeks. Not legal advice — validate compensation-handling obligations with compliance.

Multilingual, follow-the-sun, and the 3am playbook

Passengers are in the air around the clock, so the operation runs 24/7 — and usually in many languages. That multiplies the planning problem: six languages each needing night cover is not one roster but six small ones, each exposed to the fragility of small teams where a single absence removes a whole capability. Language skills are a hard roster constraint, and the plan has to name the minimum per language per interval rather than hoping the mix works out.

The disciplined approach: plan each language as its own stream with explicit coverage floors, use follow-the-sun routing across sites to keep night minimums affordable, and define cross-language escalation paths for when a floor breaks anyway. Then test the IROPS playbook against the night roster — disruption does not respect time zones, and a playbook that assumes daytime management cover, daytime overtime call-out, and daytime decision-makers will fail at 3am, which is when the long-haul diversion lands.

The disciplined travel planning posture

Forecast from the booking ledger because the demand is already on the books, pre-name the IROPS playbook and key it to operational triggers rather than meetings, staff disruption on collapsed deflection rates, and forecast the EU261 tail from the event log before the claims arrive. Plan each language as a stream with a floor, and rehearse the playbook at 3am staffing levels — because that is when it will be needed.