Airline Crew Planning Software: When a Single Illegal Assignment Cancels a Flight at Five in the Morning

Why crew is the hardest constraint model an airline owns

It is 05:12. A first officer calls in sick for a 06:40 departure. Crew control has thirty minutes to find a replacement qualified on type, current on recency, legal under flight and duty limits given what they flew yesterday, contractually assignable at this notice under the pilots' agreement, within reach of the airport, and not committed to something that cascades if you move them. Get one of those wrong and you have either cancelled a flight or created a legality violation, and the second is worse.

Every airline solves this. The question is what it costs to solve. The pattern is consistent: a crew control desk of experienced people, a scheduling system they trust for some things and work around for others, and spreadsheets and local knowledge covering the gap. The gap has the same shape everywhere. The vendor system encodes regulatory limits well and contractual work rules approximately, so the contract lives partly in the system and partly in the memory of the controller who has read it.

Jeppesen Crew Rostering, Sabre AirCentre, AIMS and NAVBLUE N-Ops and Crew are the serious products here, and their optimisers contain a great deal of hard-won engineering that nobody should casually rebuild. The recurring complaint is not the mathematics. It is that the rule model is the product, so expressing your agreement inside a vendor's rule language means a configuration project measured in months or a change request with a price attached, every time your union negotiates a new clause. Airlines end up shaping contract discussions around what the software can express, which is a strange way to run a business.

Problem 1: the rule set is a legal document, and it changes without asking you

Two rule systems govern every assignment. The regulator's flight and duty limits, meaning FAR 117 for a US Part 121 carrier or the EASA flight time limitation rules for a European one, are published, stable and shared across the industry. Your collective agreement is neither published nor stable nor shared. It contains reserve call-out windows, minimum days off patterns, trip trade rights, pay protection, junior assignment rules, hotel and transport provisions, and a hundred clauses that were negotiated to solve a specific historical grievance.

Vendor rule engines handle the regulatory layer well because it is common to all their customers. The contractual layer is where the friction lives. A clause saying a reserve cannot be assigned to a trip beginning before a certain hour following a specific prior duty type is simple in English and awkward in a configuration screen, so it gets approximated, and a human who knows better corrects the approximation. That knowledge is in no system.

What a custom build does: treat the rule set as versioned code with a test suite. Each rule is an isolated, named predicate with test cases written from real historical rosters, so when a new agreement is signed the change is a pull request with tests rather than a configuration project. Rules carry effective dates, because a contract signed in April with provisions starting in October means both versions must coexist and evaluate correctly for the period they cover. That single property, effective-dated rules with tests, is the strongest argument for building this layer, and it is where vendor systems most consistently disappoint.

Problem 2: qualifications and currency get checked at the wrong moment

A crew member is legal on a specific flight only if the type rating, line check, recurrent training, medical, recency and any special qualification such as an airport or ETOPS approval are current on that date. Most airlines hold that in a training system and import a status snapshot into the crew system. The failure is timing: the roster is built against a snapshot, training moves elsewhere, and the divergence surfaces on the day.

The incumbents all do currency checking. What they do less well is projection, which is the useful question. Not whether a crew member is current today, but whether on the fourteenth of next month, given the planned roster and booked training, they will still be current, and if not which trips that invalidates.

What a custom build does: evaluate qualifications as time-varying facts rather than a status flag, so the roster is validated across its entire span rather than at publication. Then the training department gets a forward view of who expires when against planned flying, and recurrent training slots get booked against the trips they will otherwise break. Airlines that get this right stop discovering currency problems at the gate and start seeing them six weeks out, which is the difference between a rescheduling and a cancellation.

Problem 3: an optimal pairing set and an acceptable one are not the same thing

Pairing optimisation is well studied and vendor solvers are good at it, minimising credit hours, deadheads, hotel nights and other measurable costs. What they optimise less well is what determines whether the roster survives, which is crew acceptance. A month of technically efficient pairings nobody wants generates trip trades, sick calls, open time and a reserve pool burning through the month, and that cost lands in operations rather than in the planning report.

We would not advise most airlines to write their own optimiser. A good commercial solver, or an open constraint solver applied by people who know column generation, will beat a first attempt. What is worth building is the objective function and the evaluation layer around it, because those encode your priorities rather than the vendor's defaults. Keep the solver as a component and own the model around it: weight the objective with what your crew community reacts to, which differs by carrier, and run the candidate roster through a simulation of each crew group's historical sick and trade behaviour before publishing, so reserve consumption is visible rather than discovered in week three.

Problem 4: day of operation is a different problem wearing the same clothes

Planning has hours or days and optimises cost. Recovery has minutes and optimises damage limitation under incomplete information, with four phones ringing. Systems treating recovery as replanning with a shorter horizon fail, because the controller has no time to evaluate a solution they cannot understand.

What a custom build does: rank a small number of legal options with consequences stated plainly, meaning which downstream flights each protects, which crew go illegal later, and what it costs. The controller chooses and the system never assigns silently, because a recovery tool is only used if the person using it can defend the decision afterwards.

The one place machine learning belongs in crew is here, narrowly: predicting reserve availability and sick call likelihood by crew group, base and day pattern from your own history, so reserve coverage is set from evidence rather than a number chosen years ago. Treat any AI crew scheduler making autonomous assignments with suspicion, because assignments carry legal weight and someone has to sign for them.

Problem 5: the crew member's experience is a phone call and a paper trail

The rostering system is built for the planner. The crew member gets a portal that is hard to use on a phone, so they call crew control instead, which is why the desk spends its day answering questions rather than solving problems. Assignments, acknowledgements, trade requests and call-outs happen partly by phone with a note typed afterwards, and when a dispute arises the evidence is that note. What a custom build does: a crew-facing mobile experience covering the four things crew do, which are see the roster, request a trade, respond to a call-out and submit a report, each action timestamped and acknowledged rather than reconstructed. Disputes about whether a call-out fell within the contractual window then resolve from a record instead of two conflicting recollections.

What this costs and how long it takes

A first release covering a legality engine with your regulatory and contractual rules, qualification and currency evaluation across the roster span, and controlled assignment with a full audit trail runs $150,000 to $300,000 and ships in 18 to 26 weeks. A full platform adding pairing construction with an embedded solver, bidding or preferential bidding, reserve management, recovery decision support and a crew mobile app runs $500,000 to $1,500,000 phased over 12 to 24 months.

What drives cost up in crew: the number of separate agreements, since pilots and cabin crew are two rule sets and a carrier with multiple bases or subsidiaries may have four. Regulatory scope, because operating under both FAR 117 and EASA rules doubles the legality model. Bidding, because a preferential bidding system is its own substantial product and seniority-based award logic is unforgiving. Integration into the systems owning the flight schedule, training records, payroll and hotel booking, which is four interfaces. And parallel running, which is not optional. What holds cost down: building the legality and currency layer first as a validator beside the incumbent, catching what it misses, and expanding once it has proven itself against real months.

Build versus buy, and the hybrid that usually wins

Buy if you operate a single fleet type with a modest crew complement on a stable schedule. AIMS covers that carrier well and a custom build would be a very expensive way to arrive at the same rosters. Buy if you are large and your agreements are conventional, because Jeppesen and Sabre have absorbed decades of edge cases you have not thought of yet.

Build when two or more of these are true. Your collective agreement contains work rules your vendor cannot express without a change request, and negotiations are now being shaped by software limitations. Your controllers routinely override the system because they know something it does not, which means the knowledge is outside the system. Your currency problems are discovered on the day rather than weeks ahead. You operate under two regulatory regimes and maintain a manual reconciliation between them. Or your reserve coverage is set by tradition and you have no evidence about whether it is right.

Our position: almost nobody should rebuild a crew optimiser, and a great many airlines should own their rule layer. The rules are your contract and your regulator, they change on a schedule you do not control, and the cost of expressing them badly is paid in cancellations and grievances. Owning that layer as tested, versioned, effective-dated code while keeping a commercial solver underneath is the hybrid that has worked best in the airline work we have delivered.

How to choose a developer for crew management software

Ask them how they would test a legality rule. The right answer involves replaying real historical rosters through the engine and asserting the outcome the airline actually applied, including the cases where the vendor system was wrong and a controller corrected it. If they talk about unit tests on synthetic data, they have not worked with regulatory logic.

Ask how they handle rules with effective dates, because a new agreement always starts partway through a bid period and both versions must evaluate correctly.

Ask what happens when the engine disagrees with the incumbent during parallel running. The answer should be a formal adjudication with your own crew planning leads rather than a bug queue, because sometimes the incumbent is wrong and that is what you are trying to find out.

Ask about the recovery interface specifically. If they describe an algorithm that reassigns automatically, they do not understand that a controller must be able to defend the decision to a union representative the following week.

Ask who owns the code and settle it before kickoff. You should hold the repository, the infrastructure accounts and the right to bring in another firm. At Digital Heroes the client owns the code from the first commit. With crew this is not merely commercial: the rule engine encodes your union agreement and your regulatory compliance evidence, and losing control of it is a labour relations exposure as much as a technical one.