Airline Operations Control Centre Software: What Actually Happens in the First Hour After a Hub Closes

Why a control centre with a serious system still runs on a whiteboard

A thunderstorm cell parks over your hub at 15:40. Ground stop. Fifty inbound aircraft hold or divert, the afternoon bank collapses, and by 17:00 the evening bank has nothing to build on. In the control centre the duty manager stands at a whiteboard because the whiteboard is the only surface in the building where aircraft rotations, crew legality, maintenance slots, airport slots, curfews at three destinations and the connecting passenger load appear at once. On the desks are six screens showing six systems, each authoritative about one dimension and silent about the others.

The decisions made in that hour are among the most expensive an airline makes all year. Cancel a rotation or run it late. Swap tails and break a maintenance plan. Ferry an aircraft empty to protect tomorrow. Each choice trades cost against recovery speed against tomorrow's integrity, and the person making it has partial information and a room full of noise.

Lufthansa Systems NetLine/Ops, Sabre AirCentre and NAVBLUE N-Ops and Crew all exist to solve exactly this, and all three contain real engineering. The two complaints we hear consistently from operations directors are worth stating fairly. The first is that these platforms assume you buy the surrounding suite, so a carrier running a different crew system or a different maintenance system pays for integration work that never quite closes. The second is that the recovery optimisers propose solutions controllers do not trust, because the reasoning is not visible and a duty manager cannot sign a decision they cannot explain to a regulator, a union or a chief executive the next morning.

So the whiteboard survives inside a building that has spent millions, and the operation runs on the judgement of a few experienced people. That judgement is excellent, and it is also unrecorded, unscaled, and sometimes on annual leave.

Problem 1: there is no single picture, and building one manually costs the first twenty minutes

The information a controller needs during recovery lives in at least five places: schedule and movement data, rotations with tail assignments, crew rosters with legality state, maintenance status including deferred items and planned inputs, and airport and air traffic constraints such as slots, curfews and stands. Each has an owner and a screen, and the join happens in a human head under time pressure.

What a custom build does: one timeline. Aircraft down one axis, time across, with rotations as blocks that carry their crew legality state, their maintenance constraints and their slot position as visible properties rather than as things you look up elsewhere. When a controller drags a rotation to a different tail, the consequences light up immediately: this crew now goes illegal at the third sector, this tail misses its scheduled maintenance input on Thursday, this departure now falls outside its slot. Nothing is committed until the controller commits it. The value is not automation, it is that the first twenty minutes of a disruption stop being spent assembling a picture that could have been assembled continuously.

Problem 2: recovery optimisers propose plans nobody will sign

Automated recovery is technically achievable and commercially oversold. The mathematics of reassigning tails and crews under constraints is well understood. The reason controllers override it is not stubbornness. It is that a recovery plan carries consequences a model does not see: the station manager at one outstation who cannot handle a late turn tonight, the commercially important passenger group on a particular flight, the regulator who will ask why a crew was extended, the union representative who will ask the same question differently.

What a custom build does: propose fewer options and explain each one completely. Three ranked plans, each showing which flights are protected, which are cancelled, which crews are affected and how, what it does to tomorrow's first wave, and an estimated cost. The controller picks, adjusts and commits, and the system records the choice and the alternatives that were on the table. That last part matters more than it sounds: after a bad day, the review meeting currently runs on memory. With the alternatives recorded, it runs on evidence, and the operation actually learns something.

Problem 3: the constraints that break your plan arrive from systems that do not know each other

Maintenance is the classic one. A tail swap that looks free in the ops system consumes the maintenance opportunity engineering planned for Thursday night, and nobody finds out until engineering does. Crew legality is second, particularly downline under flight and duty limits, where the swap is legal now and illegal at sector four. Slots are third: a departure slot or a coordinated airport slot is a hard constraint a rescheduled departure may violate silently. Curfews at noise-restricted airports are fourth, and they are absolute in a way that costs a diversion.

The incumbents integrate to these when you buy their whole stack. When you do not, the integration is a project you fund and maintain, and the practical result is that the constraint reaches the controller through a phone call from the department that owns it.

What a custom build does: pull those constraints in as live feeds and evaluate them at the moment of the proposed change, not after. Maintenance opportunities become blocks on the same timeline. Crew legality is evaluated forward across the whole pairing, not just the next sector. Slot and curfew validation runs on every proposed movement. This is unglamorous integration work and it is the majority of the value, because the expensive mistakes in an OCC are almost never a bad judgement call. They are a good judgement call made without one piece of information.

Problem 4: the passenger consequence is invisible at the moment of decision

Controllers optimise the aircraft and crew network because that is what they can see. Passenger impact sits in the reservation system and surfaces later, at which point cancelling the flight with 40 passengers and 12 connections has already been treated the same as cancelling the flight with 160 passengers and 90 connections onto long-haul.

What a custom build does: put the connection and reaccommodation consequence on the same screen as the operational one. Not the full reaccommodation engine, which belongs in the passenger service system, but the number that changes the decision: passengers at risk, connections lost, how many can be reaccommodated within a defined window, and how many face an overnight. Carriers that surface this consistently change which flights they cancel, and the change usually pays for the build on its own through reduced duty of care and rebooking cost.

Problem 5: delay attribution is filled in later, so nothing is learned

Delay codes are assigned after the fact, often by someone reconstructing events from a movement log. The result is a distribution of codes that is directionally true and specifically useless, with a large bucket of reactionary delay that nobody digs into. Since improvement depends on knowing which primary delays cascaded furthest, the analysis that would actually change your schedule buffer does not happen.

What a custom build does: capture the cause at the moment of the decision, since the controller knows exactly why they held that departure, and then compute the reactionary chain automatically from the rotation graph rather than asking a human to attribute it. Post-operation reporting then answers the question that matters, which is which primary events generated the most downstream damage, by station and by cause. That is the input to buffer and bank structure decisions worth far more than the software.

What this costs and how long it takes

A first release giving controllers a single live timeline with crew, maintenance and slot constraints evaluated in place, plus manual recovery with consequence preview and a decision audit trail, runs $130,000 to $275,000 and ships in 16 to 24 weeks. A full platform adding ranked recovery proposals, passenger impact, curfew and slot validation across the network, and post-operation delay attribution runs $400,000 to $1,000,000 phased across 12 to 20 months.

What drives the number up in an OCC specifically: the number of upstream systems and how willing their vendors are to expose data, which is a commercial question as much as a technical one. Real-time requirements, because a control centre screen that lags by two minutes will be abandoned. Multi-hub or multi-AOC operations, since each carries its own bank structure and rules. Passenger data access, which usually means working through a reservation system integration with its own constraints. And twenty-four seven operational support, which is a genuine ongoing cost that should be budgeted from the start rather than discovered.

What holds the number down: building the picture before building the optimiser. In every OCC project we have delivered, the single timeline with live constraints delivered most of the operational benefit, and automated recovery delivered the rest much later.

Build versus buy, and where the line falls

Buy if you already run a vendor's full suite and it works. If NetLine or AirCentre owns your schedule, crew and operations together and your controllers trust it, building alongside it creates a second source of truth, which in a control centre is dangerous rather than merely wasteful.

Buy nothing at all if you are a small point to point operator without bank structure. A duty manager, a whiteboard and a phone genuinely handle twenty aircraft, and software will not improve that operation enough to justify itself.

Build when two or more of these are true. Your crew or maintenance system is not from the same vendor as your ops system, so the constraints reach controllers by telephone. Your controllers rebuild the day on paper during disruption because no screen shows the whole picture. Your recovery decisions cannot be reconstructed afterwards, meaning your post-disruption reviews run on memory. Your delay attribution is filled in later and your reactionary bucket is large and unexamined. Or you have a bank structure at a hub where cascading failure is the dominant cost and nobody can see the cascade forming.

Our position: the value in an OCC build is concentrated in the picture and the audit trail, not in the optimiser. Vendors sell the optimiser because it demonstrates well. Controllers use the picture because it lets them do their job faster with less risk, and the audit trail is what turns a bad day into an improvement rather than an argument. Build in that order and the project survives its first real disruption.

How to choose a developer for operations control software

Ask them to spend a shift in your control centre before they quote. Anyone who will not is guessing, and the details that matter here are behavioural: how many screens a controller has, what they shout across the room, which phone rings most.

Ask how they will handle a proposed change that is legal now and illegal at the fourth sector. If they do not immediately talk about evaluating the whole pairing forward, they will build a system that produces confident wrong answers.

Ask what they have integrated in real time, naming the specific system and interface: movement messages, a crew system, a maintenance system and a reservation system are four problems with four latency profiles. Ask what happens to the screen when a feed goes quiet, because a stale display in an OCC is worse than a blank one.

Ask how the recovery proposal explains itself. If the answer is a score, controllers will ignore it. It needs to state which flights are protected, which crews are affected and what tomorrow looks like.

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. For a control centre this is an availability question too: a system your controllers depend on during disruption must be one you can fix or move without waiting for a vendor to prioritise you.