Eyrix — Blog

Charter and ACMI flight scheduling: why it's harder than a fixed timetable

A scheduled carrier flies broadly the same timetable every week: the network is fixed, the rotations repeat, and the planning problem is mostly to keep a known pattern running. Charter and ACMI operators have the opposite job. Every request is bespoke — a route, a date, a capacity someone asked for last week — and the fleet has to be re-planned around it against aircraft and crew that never sit still. The scheduling problem isn't maintaining a plan; it's rebuilding one, repeatedly, under time pressure.

Ad-hoc demand breaks the weekly rhythm

There's no repeating rotation to lean on. A charter that positions a tail to a station leaves it there for the next request to deal with; an ACMI contract commits an aircraft and crew to another operator's flying for a block of time, taking them out of your own pool. Each new booking reshapes what the rest of the fleet can do — so the plan you built on Monday is the wrong plan by Wednesday.

The constraints don't relax — the clock does

Charter and ACMI don't have fewer constraints than a scheduled airline. The same rules apply: aircraft fit and rotation, crew type-ratings and currency, maintenance windows, and EASA FTL rest and duty limits. What changes is that you're re-checking all of them against a moving fleet, often to quote a booking while the customer waits. The question "can we take this flight?" is really "does a feasible tail-and-crew rotation still exist if we add it?" — and that's a full re-plan, not a lookup.

Utilisation is the whole business

For a charter or ACMI operator, utilisation isn't a metric on a dashboard — it's the margin. Aircraft are multi-million-euro assets earning only when they're flying revenue legs, and every empty positioning leg or idle day between contracts is lost. Deciding which requests to accept, and how to rotate the fleet around them with the fewest deadhead hours, is the commercial core of the operation — not an afterthought once the schedule is built.

Why this is a solver problem

Answering "can we take this, and is it worth it?" by hand means holding fleet position, crew qualification, rest state and maintenance in your head at once, then re-solving on every new request. That's exactly what a constraint solver is for: given the current fleet and crew state, it works out whether a feasible rotation exists for a proposed booking, and how to place it for the best utilisation — in seconds, so the answer arrives while it still matters. For an operation that re-plans this often, that's the difference between quoting from a spreadsheet's guesswork and quoting from a plan you know actually closes.