Most industries have busy periods. Airlines have irregular operations, and the difference matters. A weather event, a technical fault, or an air traffic restriction can multiply contact volume many times over within an hour, and every one of those callers has the same urgent question about a plan that has just stopped working.
This article is about how carriers use outsourced capacity to absorb that load without handing over decisions that belong in-house. It follows the shape of a disruption itself: what has to be in place before the event, what agents do while it is running, and what the queue looks like once the aircraft are moving again.
The volume problem is structural, not seasonal
Retail peaks are forecastable months ahead. Disruption is not. An airline cannot hire against a snowstorm, and staffing permanently to the worst day of the year would mean carrying idle capacity for the rest of it. The gap between normal load and disruption load is precisely the gap outsourced capacity exists to cover.
There is a second problem underneath the first. Disruption contact is not spread across the day. It lands in the hour after the cancellation notice goes out, from passengers standing at a gate or sitting at home with a connection that no longer exists. Their patience is short and their question is specific. A queue that answers promptly on an ordinary Tuesday can run into very long waits during a disruption, and every abandoned call becomes a second call, a public complaint, or a passenger walking up to a desk that is already overwhelmed.
Staff to the surge floor you are willing to survive, not to the average you usually see.
Before the event: decide what agents may do
The most important work in an airline programme happens when nothing is going wrong. That is when you write down the boundary between what an outsourced agent may do on their own authority and what must go to your own staff. Written is the operative word. A boundary that lives in a supervisor's head does not survive a mass re-accommodation at three in the morning.
Work that transfers well is work you can document: rebooking within defined fare rules, confirming a rebooked itinerary, reading back baggage status, explaining what a delay means for a connection, capturing contact details for follow-up, and answering questions about accommodation and meals where your policy is already written down. Each of these has a right answer that an agent can find in a document or on a system screen.
Work that stays with you is anything discretionary. Compensation decisions, exceptions to fare rules, medical and special-assistance judgement calls, and anything that touches safety belong with staff who own those decisions and carry the authority to make them. Our agents capture the request, set the expectation about who will respond, and hand it to the right desk. They do not improvise it.
A useful test: if an agent cannot tell within a few seconds whether a request is inside their authority, the boundary is not documented well enough to hold under pressure. Rewrite it until they can.
Before the event: systems access decides everything
An agent who can see a passenger record but cannot change it produces a slower version of the original problem. They take the call, understand the situation, and then transfer it to someone who has to hear the whole story again. Rebooking authority inside the reservation system, with rules constraining what may be offered, is what separates a programme that reduces load from one that simply adds a queue in front of your own.
Provisioning that access is usually the longest item at launch and the one most worth pushing on. It means named accounts rather than shared logins, permissions scoped to the tasks in the agreed scope, and a way to revoke access the day an agent leaves the programme. When your project manager maps the process before launch, systems access is the first item on the list, because training agents on a system they cannot yet log into wastes the training.
Before the event: train the bench in normal conditions
Agents cannot be trained into irregular operations while irregular operations are happening. Airlines that run this well keep a trained bench that handles routine volume in normal conditions and expands into disruption when it arrives. The people answering during the event already know the fare rules, the systems, and the escalation path, because they have been using them every day on ordinary bookings, seat changes, and baggage questions.
This is also where language coverage gets decided. A disruption at a hub airport puts passengers from many countries into the same queue at the same time, and a caller who cannot be understood is a caller who is transferred, held, and called back. Building multilingual support into the bench before it is needed is far easier than sourcing it in the middle of an event.
During the event: run the script you rehearsed
When the disruption arrives, the programme should feel boring from the inside. Agents open the same systems, follow the same rules, and escalate through the same path they used yesterday. The difference is volume, and volume is what the surge floor was designed for.
Two practices make the difference between a queue that recovers and one that spirals. The first is a single source of truth for what is being offered. If the operations centre changes the rebooking rules at noon, every agent needs the change within minutes, through one channel, not through a chain of messages. The second is honest queue messaging. A passenger who is told the wait is long and offered a callback is calmer than one left listening to music with no information.
Escalations during the event need their own lane. If a compensation request or a medical case has to wait in the same queue as a routine rebooking, the cases with the highest consequence get the slowest response. Agree the escalation route, the hours it is staffed, and what an agent says to the passenger while it is in progress.
After the event: the second wave
The queue does not return to normal when the last aircraft departs. It shifts. Passengers who were rebooked call to confirm. Passengers who were not call to complain. Baggage that travelled separately generates its own contact for days. Refund and expense questions arrive once people are home and have found their receipts.
This second wave is lower in urgency and higher in detail, and it is where a thin first-contact record shows. If the agent during the event captured the passenger's contact details, the new itinerary, and any promise that was made, the follow-up call is short. If they did not, the passenger tells the whole story again and the airline pays for the same call twice. Our agents work to a prescribed minimum record on every disruption contact for exactly this reason.
The other after-event task is the review. A session with the outsourced team in the week after should cover which rules were unclear, which system screens slowed agents down, and which escalations waited too long. Each of those is a change to the documentation, and the documentation is what the next disruption will be run from.
Measure recovery, not handle time
Average handle time during a disruption is a misleading number. The calls that matter most are the longest ones, because they are the ones where a connection is being rebuilt from scratch. A programme judged on handle time alone will learn to rush those calls, and the cost surfaces later as repeat contact.
The measures below are defined during scoping and reported on the rhythm agreed up front, so you see recovery data while it can still change the next event's plan. The wider call centre KPI guide covers how to weight them against each other.
- Share of passengers rebooked on first contact, without a transfer or callback.
- Share of passengers who contacted you again within a day of the event.
- Time for the queue to return to normal after the disruption closed.
- Escalations that waited longer than the agreed limit, by category.
When outsourcing this work is the wrong move
Not every carrier should outsource disruption handling, and not every part of it should go. If your fare rules change so often that no document can keep up, agents will be working from stale rules and the boundary will fail. If your reservation system cannot support scoped external access, agents will be blind and the programme will add a queue rather than remove one. And if you are not willing to write the boundary down and hold your own staff to it as well, the outsourced team will inherit an ambiguity it cannot resolve.
In those cases, fix the rules and the access first. Outsourced capacity is at its best when it is absorbing volume against a process that already works, not compensating for one that does not.
Where to start
If you are scoping this, the airline outsourcing overview covers the service mix, and inbound call center services explains how surge capacity is structured. The engagement begins with a call about your routes, your peak patterns, and the hours and agent numbers you expect to need. From there a project manager maps the process, prepares the systems, and trains agents on your rules before they take a single live call. That sequence is deliberate. The event will not wait for you to finish onboarding, so onboarding has to finish first.