Ground Handling Operations Software Problems: The 7 That Cost Real Money, and How to Avoid Them

Why does a handling project get scoped as an office allocation system?

The scoping failure that costs handlers the most is building the planning half and leaving the ramp half for later. The proposal covers rostering, resource allocation, a control room dashboard and airline reporting, and milestone capture is listed as a phase two item because ramp devices are awkward, expensive and hard to estimate. It is an entirely rational sequence and it produces a system that reports beautifully on numbers it did not observe.

Without capture at the point of the event, every downstream figure is a reconstruction. Your allocation engine is planning against a schedule rather than against reality, your service level reporting is built from the same paper sheets that lost you the last dispute, and your control room dashboard shows a turn as on time until somebody tells it otherwise. The phase two device rollout then has to justify itself all over again against a budget that has already been spent.

It also happens because the people writing the requirement sit in an office. The duty supervisor's improvisation is invisible from there, and so is the reason paper survives: it works with gloves on, in rain, behind an aircraft, with no battery.

The fix is to put capture in release one and design it on a ramp. Chocks on, ground power connected, doors open, first bag on belt, last bag, doors closed, pushback commenced, recorded at the moment they happen by the person doing the task, with identity and device position attached. Ask a prospective developer to stand a full shift before quoting. Everything that determines whether this software works is physical: noise, weather, glove size, the distance between stands and where a person can actually stop and tap a screen. A developer who designs it from a desk builds an application that stays on a desk.

What goes wrong with qualifications, equipment and station reference data?

Handlers rarely have a data migration in the traditional sense, which lulls people into thinking there is no data problem. There is, and it is worse, because the data does not exist yet in any structured form.

Qualifications are the first. Training records live in a spreadsheet per station, maintained by whoever the station manager delegated it to, with inconsistent naming for the same qualification across airports, expiry dates recorded in three date formats, and no reliable link between a certificate and a person's roster identity. Loading that as it stands produces an allocation engine that blocks half your workforce and clears people it should not.

The equipment register is the second. Most stations know which units they own and not much else: no consistent asset identity, no serviceability status outside a workshop system, and no record of which units were transferred between stations two seasons ago.

The third is station reference data. Stands, walking times between them, licence scope, the terms of each handling agreement and what each one includes versus charges separately. Every one of those differs per airport and most exist only as a contract PDF and local knowledge.

The fix is a station data pass before the build, run by an operations person and not by IT. Standardise qualification names across the network, reconcile every certificate to a roster identity, tag and register the equipment physically, and extract chargeable items from each handling agreement into a structured rate table. It is unglamorous work and it is the single highest value preparation available. Do it at one station first, prove the shape, then repeat.

Why do the airport and airline integrations break after launch?

Ground handling sits between two parties who both change their systems without consulting you, and you are the smallest party in every one of those relationships.

Airport feeds are the harder problem, and often more politically difficult than technically difficult. A collaborative decision making feed or an operational database is a different interface at every airport, obtaining access is a commercial negotiation you have to lead rather than a ticket your developer raises, and the terms of that access can be withdrawn or renegotiated. When a feed changes format or a schedule source moves, your allocation engine is planning against stale flight data and nobody sees an error, because a schedule that stopped updating still looks like a schedule.

Airline integrations are the second, with each carrier's messaging and reporting expectations differing, and a change to a reporting format usually arriving as an email to someone in commercial rather than to anyone technical.

Equipment telematics is the third and the least dramatic: units get swapped, devices get replaced, and the mapping between an asset and its tracker drifts until utilisation reports are quietly wrong.

The fix is staleness detection and one named owner per feed. Every inbound feed needs a freshness check that alerts when data stops updating, not just when a connection errors, because silence looks like calm. Assign each feed an owner on your side who is told when it breaks, and keep the access negotiation with the airport as an ongoing relationship rather than a one time project task. Ask any developer to name the specific airport system they have integrated with, not to claim airport integrations in general.

What happens when qualification enforcement and offline capture are missing?

Two gaps produce findings rather than inefficiency, and both are commonly deferred.

Qualification enforcement is the first. Ramp work is qualification bound: pushback, de icing, dangerous goods acceptance, loading supervision and airside driving each need training and currency, and your licence scope at one airport may not match another. Where the system reports on qualifications rather than blocking on them, a supervisor is the only control, and the audit finding arrives eventually. Expiry forecasting is the neglected half: at most stations recurrent training is booked reactively, after somebody has already dropped off the roster and a shift has already been broken.

Offline capture is the second. Coverage drops behind an aircraft, in a hold and in parts of every apron. A system that requires connectivity to record a milestone will be abandoned within a fortnight and replaced by the paper sheet it was bought to eliminate, which means you have paid for the devices and kept the problem.

The fix is enforcement at assignment and offline as a design assumption. Qualifications belong to the person with expiry dates, and the allocation engine should be incapable of proposing an assignment the person is not currently qualified for at that station, with a forecast telling the training coordinator which qualifications lapse in the next six weeks and which shifts that will break. Capture must work fully offline and reconcile on reconnection, with explicit rules for a milestone recorded late rather than an improvised guess, because a reconciliation rule invented after the fact is the thing an airline will challenge.

Should you build custom or configure what you already own?

If you run a single station with a handful of airline contracts and a stable schedule, do not build. A shared roster, a radio and a competent duty supervisor genuinely handle that, and software would be overhead you fund forever. That is a real answer and we give it.

If you are a large handler whose operation fits the model, configure INFORM GroundStar and adapt your processes towards it. Its allocation engine has absorbed a great deal of genuine operational complexity and reproducing that from scratch is a poor use of capital. Ink Aviation and TAV Technologies serve real handlers too and deserve a look on their own terms.

Where configuration strains is the station specific constraint set: licence scope that differs per airport, collective agreement rules on break windows and mid shift task changes, partly shared equipment pools, and evidence requirements driven by the exact wording of your handling agreements. Those are not features a vendor withheld, they are properties of your business that a general product cannot know.

Build when two or more of these are true. You operate multiple stations with different licence scopes and no single system covers them all. You regularly absorb delay penalties you believe were not yours. Your equipment pool is unmeasured and fleet decisions rest on opinion. Qualification currency lives in a spreadsheet beside a roster that can assign anyone to anything. Or chargeable extras are captured on paper and you suspect a meaningful share never reaches an invoice.

How do hidden costs get into the quote?

Four items reliably arrive after signature. Stations, quoted as a multiplier when the truth is that the first station carries almost all the cost and the tenth carries almost none, so a proposal priced per station is either padded or has not understood the work. Airport feeds, quoted as integrations when obtaining access is a commercial negotiation with its own timeline. Airline integrations, priced as one item when each carrier is separate. And ramp hardware, including the mounting, charging, replacement rate and the offline behaviour that turns a tablet application into a ramp application.

The fifth is language. Multi language matters more than people expect on a ramp, and it is rarely in the first estimate.

The fix is to price the first station honestly and name the feeds. Ask what release one covers at one station, what the incremental cost of station two is, which airport systems are named in scope and who leads the access negotiation, which carriers are included, and what the assumed device failure and replacement rate is. A vendor who answers those five has planned an operation. One who quotes a platform per station has planned a spreadsheet.

What separates a handling build that works from one that fails?

The builds that work start at the busiest station and measure two numbers. Delay penalties avoided and chargeable extras that now reach an invoice are both directly observable within a quarter of going live, which is unusual in operational software and means you should insist on tracking them rather than accepting a general efficiency story. Start where volumes are large enough that the numbers are unambiguous.

They treat the unglamorous billing capture as a priority rather than an afterthought. An additional service requested by an airline representative on the day, recorded at the point of service on the same device that captured the milestone with the requester's name attached, is the least interesting feature in the build and frequently the one that funds it. Extras written on paper and keyed weeks later are extras that partly evaporate.

They give the supervisor a live picture rather than an instruction. The commonest cause of a late start is not a shortage of people, it is not knowing which people are genuinely free, so the system should show current task and next free time for every person and every unit and propose reallocation when the schedule moves. The supervisor still decides. That distinction is what gets the system used instead of overridden.

And they settle ownership before kickoff: repository, infrastructure accounts and the right to bring in another firm, in writing. At Digital Heroes the client owns the code from the first commit. In this sector the point is commercial rather than technical. Your timestamp record is the evidence behind every delay dispute and every contract renewal, so a vendor who controls access to it controls your negotiating position with your own customers.