Insights / What airline crew rostering teaches small-team scheduling
The same problem, with the consequences visible
Every organization that runs shifts builds a roster. Most build it the same way: a manager, a spreadsheet, a few evenings, and a set of rules that live in the manager's head. It works until the manager changes, or the team grows past the point where one head can hold the constraints, or somebody notices that the same person has worked every Saturday for three months.
Airlines hit that wall decades ago and could not afford to stay there. A crew member who exceeds the legal duty limit grounds the flight. A captain without a current qualification on the type cannot fly it. A roster that is systematically unfair produces a grievance, then a strike. So airlines wrote the rules down, built systems to apply them, and developed habits that a small team can adopt in an afternoon. Three of them do most of the work.
Habit one: the rules are written before the roster is built
Airline rostering starts from a rulebook, not from a blank grid. Maximum duty hours, minimum rest between duties, maximum consecutive days, required days off per month, qualification currency. Every one of these is written down, and the roster is checked against them mechanically. A roster that violates a rule is not "a bit tight." It is invalid.
Small teams usually have the same rules and have never written them down. Nobody works more than five days running. Two new hires never share a night. The senior nurse covers Tuesdays because of the clinic. These rules exist; they are just unwritten, which means they are applied inconsistently and cannot be handed over. The single most useful hour in fixing a small-team roster is spent writing the rules the current scheduler already follows. Once they are text, they can be checked, argued about, and given to software.
Habit two: constraints are sorted into hard and soft
Not all rules are equal. An airline splits them into two kinds, and the split is the design decision that makes the roster solvable.
| Kind | Airline examples | Small-team equivalents | What the roster does with them |
|---|---|---|---|
| Hard (never broken) | Legal rest minimums, duty-time limits, qualification currency, minimum crew per aircraft | Legal working-time limits, licensed staff on every shift, minimum headcount, approved leave | Any roster that breaks one is rejected outright |
| Soft (satisfied as far as possible) | Requested days off, preferred routes, even distribution of unpopular duties, back-to-back pairings | Shift preferences, weekend fairness, avoiding split shifts, keeping regular teams together | Weighted; the roster maximizes how many are met and reports which were not |
The mistake small teams make is treating everything as soft, so the roster quietly breaks a legal limit to honor a preference, or treating everything as hard, so no roster is possible and the manager gives up and does it by hand. Sorting the rules is the fix. It is also the conversation that surfaces disagreements about what actually matters, which is better had once than every month.
Habit three: fairness is measured, not felt
Crew rosters are published with statistics: hours flown, nights away, weekends worked, per person, per month, against the fleet average. Fairness is not a feeling the scheduler has about the roster. It is a number anyone can check. That transparency is what stops the argument before it starts, and it is what protects the scheduler from the accusation of favoritism.
A small team can do this with three columns on the roster: weekends this month, nights this month, unpopular shifts year to date. Publish them. The person who has worked four Saturdays will see it, and so will everyone else, and the next roster corrects it before anyone has to complain. Fairness that is visible is also fairness that can be automated: a solver can be told to minimize the spread of those three numbers, and it will.
What changes when the rules are text
Once the constraints are written and sorted, the roster stops being a craft and becomes a constraint problem, which is something software solves well. Enter the staff, their availability, the hard rules, the soft preferences and the minimum cover, and a month comes out that meets every hard rule and as many soft ones as possible, with a list of the ones it could not. The manager's job shifts from building the grid to reviewing the exceptions, which is the job that actually needs a human.
This is the design behind Airffic Shift: plain-language rules in, a month's roster out, existing fixed shifts left untouched. The guide to AI shift scheduling walks through what the rules look like when written for a machine. The more important result is not the hours saved on drafting. It is that the roster now survives a change of manager, because the rules are in the system rather than in the person.
The two things airlines get wrong, so you can avoid them
First, over-optimization. A roster tuned purely for cost produces pairings that are legal, efficient and hated, and the airline pays for it in fatigue and turnover. Small teams should weight the soft constraints heavily enough that the roster looks like one a fair human would have built. The efficiency gain is in the hours not spent building it, not in squeezing the schedule.
Second, rigidity. Airline rosters are published weeks ahead and then disrupted daily; the recovery process matters more than the original plan. A small team needs the same: a clear rule for who covers a sick call, a way to swap shifts that keeps the hard constraints intact, and a roster that can be rebuilt from the current state rather than from scratch. The article on redundancy covers why the cover plan is part of the roster, not an afterthought.
Where to start
Write down the rules the current scheduler follows. Sort them into hard and soft with the team in the room. Add three fairness columns to the published roster. That is an afternoon's work, needs no software, and fixes most of what is wrong with most small-team rosters. The software comes after, and it works far better when it inherits rules a team has already agreed on than when it is asked to invent them.