Crew Roster Planning for Business Aviation Operators: Why Duty-Centric Beats Flight-Centric
Crew planning is one of the areas where business aviation differs most sharply from scheduled airline operations — and where software built around the wrong mental model quietly makes a planner's life harder every single day.
Airlines plan crews around pairings: multi-day sequences of flights, built weeks in advance from a schedule that is known, stable, and repeatable. The pairing is the atomic unit; crew members are slotted into pairings, and the roster is essentially the sum of those assignments. This works because the flying program exists before the roster does.
A business aviation operator lives in the opposite world. Charter and private flight departments typically build next month's roster before most of next month's flights exist. A trip may be booked with 48 hours' notice, moved twice, and cancelled the day before departure. You cannot assign crew to flights that haven't been sold yet — and yet the roster still has to be published, legal, and fair.
This is the fundamental distinction: airline crew planning assigns people to flights; business aviation crew planning assigns people to duties.
The duty roster as the primary planning object
In a business aviation operation, the roster is a calendar of duty states, not a list of flight assignments. A well-structured duty catalogue typically includes:
-
On duty — available for flying, usually tied to a specific aircraft tail or aircraft type
-
Off duty — protected rest days, vacation, days off after blocks of work
-
Standby — home, airport, hotel, or reserve standby, each with different FDP and duty-time treatment under the operator's OM-A Chapter 7 (in Europe derived from the flight time limitation rules of Regulation (EU) No 83/2014, Subpart FTL of Part-ORO)
-
Training — simulator sessions, line training, ground courses
-
Other duty types — office days, positioning days, medical, admin
The single most important design decision is that "On" duties are planned against a tail or an aircraft type, not against flights — in Leon this is configured directly in the duty definitions, where a duty can carry a specific registration or a whole type. The planner's question for any given day is not "who flies leg X?" but "is D-ABCD covered tomorrow — do I have a current, qualified captain and first officer on duty for that tail?" Flights come and go; coverage per tail per day is the invariant the operator must protect.
From this follows the planner's real checklist for every day of the roster period:
-
Coverage — each active tail (or type, for larger fleets) has a complete, legal crew complement on duty.
-
Balance — days on and days off are distributed fairly and within contractual and regulatory limits.
-
Validity — licences, medicals, and endorsements are valid on that day, not just at publication time. Under EASA rules these requirements sit in Part-FCL and Part-MED of Regulation (EU) No 1178/2011, and it is the operator's roster — not the pilot's memory — that has to guarantee them day by day.
-
Currency — recent experience will still hold on the day of the duty, for the type the crew member is rostered on. The canonical example is FCL.060, which requires 3 takeoffs and 3 landings in the preceding 90 days on the relevant type or class before carrying passengers.
Note the phrasing: validity and currency are checked for a day and an aircraft type — not for a flight. On the day the roster is built, the flight often does not exist yet. Any crew rostering system that can only validate a crew member "against a flight" simply cannot answer the questions a business aviation planner is actually asking.
Where the flight-centric model breaks down
Most flight operations software grew out of dispatch. In dispatch, the flight-centric view is the natural one — a dispatcher works trip by trip, leg by leg, and everything (handling, permits, fuel, catering, crew) hangs off the flight. For OPS, that is exactly right.
Carry that same model into crew planning, however, and friction appears immediately:
-
You can't roster against a schedule that doesn't exist. A flight-centric roster is empty until flights are booked — which for a charter operator means the roster would be built days, not weeks, ahead.
-
Every schedule change becomes manual crew work. New booking? Someone has to remember to crew it. Cancelled trip? Someone has to remember to un-crew it. Aircraft swap? Someone has to re-check qualifications. In a business where the schedule changes hourly, this doesn't scale.
-
Compliance checks fire too late. If FTL, currency, and endorsement validation only runs when a crew member is attached to a flight, problems surface at the worst possible moment — when the trip is already sold and departure is imminent — instead of at roster-building time, when there is still room to fix them.
-
Positioning is invisible. In a duty world, a crew member's next duty may start where the aircraft is, not where the crew member last landed. Continuity has to be evaluated against both.
The conclusion many operators reach after years of spreadsheets or dispatch-first tools: the crew planning workflow needs a day-aircraft-centric, duty-centric perspective — where the two fixed coordinates of every planning decision are the calendar day and the aircraft, with flights layered on top later, even inside a system whose OPS side rightly stays flight-centric. A mature flight management system supports both views and keeps them synchronized.
What a duty-centric crew planning workflow looks like
In a properly duty-centric flight operations platform, the workflow inverts: the duty roster is the source of truth, and flight assignments are derived from it.
1. Crew are assigned to duties; flights inherit the crew
The planner builds the roster in a calendar or timeline view — assigning "On" duties on a tail or type, standby, training, and off days, often from repeatable work patterns (e.g. a 5-4-5-5 rotation). When a flight is then booked on an aircraft, the system already knows who is on duty for that tail on that day and auto-assigns them to the flight, on the correct positions derived from their ratings and the roles defined on the duty. When a flight is cancelled or moved to another day, the crew assignment follows the schedule change instead of leaving stale data behind; when the tail changes within the same type, assignments can be preserved. Where a change creates a gap — an "On" duty shortened, an "Off" duty extended — a good system doesn't just flag the hole, it suggests replacements from among the other crew on duty for that aircraft.
The planner stops chasing individual bookings and instead manages one thing: is every tail covered, every day, with legal crew?
2. Validation runs per day, against the duty's aircraft
Because "On" duties carry an aircraft context, compliance checks can run the moment the duty is planned — long before any flight exists:
-
FTL is computed over duty periods, not flights — which is exactly how the regulations define it: EASA's Subpart FTL frames its cumulative limits and rest requirements around duty and duty periods, of which the flight duty period is only a subset. A standby day with zero sectors still consumes duty time and shapes the surrounding rest requirements; cumulative limits, days-off rules, and weekly recurrent rest are evaluated across the whole roster, with violations flagged directly on the calendar as it is being built.
-
Currency and endorsements are validated for the day and the aircraft type attached to the duty. A quick visual indicator next to each crew member — the way Leon's crew currency dots work in the crew calendar, reflecting the specific tail or type of the group they're planned on — tells the planner at a glance whether that person will be current and legal on that duty, even in draft mode. The same crew member can legitimately show green for one type and red for another.
-
Custom roster rules (operator-specific business logic: crew pairing restrictions, base rules, contractual day counts) can be layered on top — Leon exposes this as scriptable roster validation — and evaluated against the daily activity set, including the aircraft assigned to each duty.
This is the practical payoff of the day-aircraft-centric model: problems are caught at planning time, weeks out, when swapping two duties fixes them — not on departure day.
3. Continuity and positioning consider the aircraft, not just the crew member
In pairing-based airline planning, crew continuity is trivially about the crew member: pairings begin and end at base. In business aviation, the aircraft roams. A duty-aware system evaluates schedule continuity against both the crew member's last known location and where the aircraft attached to their duty will be — and turns the gap into a positioning task (airline ticket, ground transport) that is itself a rostered activity feeding into FTL. Repositioning stops being tribal knowledge and becomes a visible, planned, and legally accounted-for part of the roster.
4. Publication, notification, and acknowledgement close the loop
A roster that crews haven't seen is a liability. The final — and often underestimated — pillar of the workflow is controlled communication:
-
Draft vs. published. Planners work in a draft layer invisible to crew, iterate freely, then publish a defined period. Crew only ever see a deliberate, finished roster — never work in progress. This isn't just good practice: ORO.FTL.110 explicitly obliges operators to publish duty rosters sufficiently in advance for crew to plan adequate rest, which presupposes a controlled publication step rather than a continuously mutating schedule.
-
Automatic change notifications. Once published, changes reach crew by email (with a work schedule attached) and by push notification in a crew mobile app, with edits made in quick succession intelligently grouped so crew aren't spammed by every keystroke.
-
Roster acknowledgement. Crucially, notification alone isn't confirmation. A robust system tracks acknowledgement per duty day and per flight assignment: the planner sees, on the roster itself, whether each change has been sent, seen, and confirmed by the crew member — and if the day changes again after confirmation, the acknowledgement resets and must be renewed. That granular feedback loop is what turns "we emailed the roster" into demonstrable assurance that every crew member actually knows their current schedule. Under a management system compliant with ORO.GEN.200 — and in line with the fatigue management guidance of ICAO Doc 9966 — that kind of documented, closed-loop communication is exactly the evidence auditors ask for.
Two perspectives, one system
None of this argues against the flight-centric view — dispatchers need it, and it remains the right lens for OPS. The point is that crew planning is a different workflow with a different natural unit of work, and forcing it through a dispatch lens is the root cause of most crew-planning pain in business aviation.
The operators who run the smoothest crew operations are the ones whose flight management software lets each team work in its native perspective: OPS thinks in trips and legs; crew planning thinks in days, duties, and coverage — while the system keeps both in sync automatically. Flights inherit crews from duties. Schedule volatility is absorbed by automation instead of manual rework. Compliance is enforced on the roster, not discovered on the ramp. And every crew member has confirmed they know exactly where they need to be.
For a business aviation operator, that is what modern crew rostering looks like: not a better way to assign pilots to flights, but a system that understands you're often planning for flights that don't exist yet — and makes that not just workable, but safe. It's the philosophy we've built crew planning around at Leon Software, shaped by years of watching how business aviation operators actually work — but whichever platform you use, the duty-centric test above is the right one to apply.