Reference
Crew Pairing vs Crew Rostering: What's the Difference?
Crew pairing assembles the flight schedule into anonymous trips: sequences of sectors that leave a base and return to it. Crew rostering then assigns those trips, plus everything else (training, reserve, leave), to named crew members to form their monthly schedule. Pairing is solved without a single name in the data; rostering exists to attach the names.
The two terms get used interchangeably, vendors included. They are in fact two distinct optimisation problems, solved in sequence, with different inputs and different objectives. And plenty of operators only ever need one of them.
What is crew pairing?
Crew pairing (also called trip or rotation construction) takes the flight schedule as input and produces coherent blocks of work: a pairing starts at a base, strings together sectors over one or more days with turnarounds and layovers, and ends back at the base it started from.
No names appear at this stage. The unit of reasoning is a generic crew: a trip requiring a captain, a first officer and two cabin crew qualified on a given type. The constraints in play are operational and regulatory feasibility, such as minimum ground time, FDP limits on each duty day, rest between duties, and returning to base.
The classic objective is cost minimisation: paid time not spent flying, hotel nights, deadheading. It is a very large combinatorial problem and has been a centrepiece of airline operations research for decades. Recent work reports solution-cost reductions of 6.8 to 8.5% on crew pairing instances of up to 50,000 flights when machine learning steers the optimiser (Yaakoubi, Soumis & Lacoste-Julien, 2020, EURO Journal on Transportation and Logistics), and up to ~30% less compute time through ML-based column selection (Morabit, Desaulniers & Lodi, 2021, Transportation Science).
What is crew rostering?
Crew rostering takes those trips as input, along with everything that is not a flight, and builds the monthly schedule of each named crew member.
The inputs change nature completely:
- each person's qualifications, endorsements and recurrent check expiry dates;
- leave, absences, training, standby duties;
- individual rolling counters over 7, 14 and 28 days;
- crew requests and preferences;
- company rules and collective agreements.
So do the objectives. Beyond cost, rostering targets fairness (distribution of weekends, nights and layovers), request satisfaction, roster stability and robustness against disruption. A roster that is excellent on paper and socially unsustainable is a bad roster, and no amount of optimality changes that.
How do the two problems really differ?
| Crew pairing | Crew rostering | |
|---|---|---|
| Input | Flight schedule | Pairings plus non-flying activities |
| Output | Anonymous trips | Named individual schedules |
| Unit handled | A generic crew complement | A person |
| Dominant constraints | Operational feasibility, FDP, return to base | Qualifications, individual counters, leave, labour agreements |
| Primary objective | Cost of producing the trips | Fairness, preferences, robustness, cost |
| Typical horizon | The schedule (season or month) | The roster month |
| Effect of a disruption | One trip to rebuild | Cascade across several individual rosters |
The distinction worth keeping: pairing optimises a product, rostering optimises a distribution among people. Which is why a strong pairing tool is not automatically a strong rostering tool, and the reverse.
Why are the two steps kept separate?
For an entirely practical reason: solving them jointly produces a problem that even industrial solvers struggle with at realistic scale. The two-stage decomposition has been the reference method for decades.
It carries a known cost. Trips built in stage one are built without knowing who will fly them. A pairing-optimal solution can turn out to be awkward to assign, because it concentrates layovers, because it needs a scarce qualification, or because it lands on the week three crew members are in the simulator. Modern approaches soften this by feeding assignability criteria back into trip construction rather than by merging the two problems outright.
Does every operator do crew pairing?
No, and this is what generic explainers almost always skip.
Crew pairing presupposes a known, repeating flight schedule. That is the scheduled airline world: a stable seasonal programme, trips that recur week after week, and an obvious payoff from optimising how they are built.
Business aviation, on-demand charter and much ACMI work do not run that way. The schedule assembles itself from incoming requests, sometimes 48 hours out. There is nothing to pre-assemble: the problem is directly one of assigning flights to available, qualified crew under regulatory constraints, inside a roster that has already been published. Pairing disappears; rostering and flight assignment become the whole game. Recomputation speed then matters more than the elegance of a construction made a month in advance.
SkAI Tech covers both sides of that divide. For a repeating programme, pairing optimisation builds the flight schedule into trips that leave a base and return to it, within duty limits and with as little positioning as possible; rostering then generates ON/OFF duty patterns against company patterns and regulation, and flight assignment attaches the trips to named crew. For on-demand flying, the same engine skips the pre-built trips and assigns flights to crew directly. Rosters are generated in 12 minutes on average. Those results are observed across SkAI Tech deployments in 2025-2026, over a scope of more than 70 aircraft and 900 crew members, and vary with fleet size and operating model.
Flying a repeating schedule? See how SkAI Tech builds pairings for scheduled airlines.
How do trips get allocated to crew members?
Three models coexist, and the choice between them is usually a labour agreement question rather than a technical one:
- Assigned rostering: the operator builds and publishes each crew member's schedule. The most common model in Europe.
- Bidline: complete lines of flying are published and crew members bid on them by seniority. The historic North American model.
- Preferential bidding (PBS): crew members express weighted preferences and an engine builds personal rosters honouring them as far as possible, in seniority order. A middle path between the two.
One optimisation engine can serve all three (see crew bidding). What changes is the objective function and the weight given to individual preferences, not the underlying mathematics.
FAQ
Is "crew scheduling" pairing or rostering?
Crew scheduling is the umbrella term for the whole chain, from flight schedule to published individual roster. When a vendor advertises crew scheduling, the useful question is: does it cover trip construction, named assignment, or both?
Do we need a pairing tool if we don't fly a repeating schedule?
No. With no repeating programme there are no trips to pre-build. The effort belongs on named assignment and on recomputation speed after disruption, which are the real pain points in charter, medevac and much of ACMI.
Do pairing and rostering use the same technology?
Both are constraint-based optimisation, but with different problem structures: pairing behaves like a set-covering problem, rostering like a multi-constraint assignment problem. Excellence at one does not transfer automatically to the other, and it is fair to ask a vendor which one they were actually built for.
Where do standby and reserve fit?
On the rostering side. Reserve is an activity assigned to a person, exactly like a trip or a training slot. How much of it you hold, and where you place it, directly determines how much disruption the operation can absorb (see our guide to crew disruption management).
Sources
- Yaakoubi, Y., Soumis, F. & Lacoste-Julien, S. (2020), Machine learning in airline crew pairing to construct initial clusters for dynamic constraint aggregation, EURO Journal on Transportation and Logistics 9(4), DOI 10.1016/j.ejtl.2020.100020: solution-cost reductions of 6.8 to 8.5% on instances of up to 50,000 flights.
- Morabit, M., Desaulniers, G. & Lodi, A. (2021), Machine-Learning-Based Column Selection for Column Generation, Transportation Science, DOI 10.1287/trsc.2021.1045: up to ~30% less compute time.
- SkAI Tech indicators (first-party data): average generation time observed across 2025-2026 deployments, varying with fleet size and operating model.
