At a glance
- Client: Budapest Airport, ground handling
- Product: OptiFlight, built on our four-layer stack, with erdosP-3 as the solver
- Status: in production, with more than 42,000 assignments made so far
- Scale: 120 staff in one roster, 35 qualifications, and about 130 unexpected events a week
- Connected to: more than 15 airport systems, including the AODB and Veovo
- Results: 19% fewer paid hours, 72% fewer SLA breaches, 1,600 fewer overtime hours and 120 fewer planning hours a month
The problem
Ground handling is the most variable operation we work in. Flights move by the minute, and staff can’t be swapped for one another. Who can do pushback, de-icing or loading depends on their qualifications, their training and the hours they have already worked.
At Budapest Airport, 120 people work from one roster and hold 35 different qualifications between them. About 130 unexpected events hit that roster every week: sickness, no-shows, late arrivals, delays and schedule changes.
Before OptiFlight, shifts were flat. Each one was sized for the busiest hour of the day and held from start to finish. Quiet hours were paid in full, and the peaks were still short, so the gaps were filled with overtime called in at short notice. Planners matched qualifications, rest rules and the collective agreement by hand. The roster, leave, training expiry and reports all lived in separate Excel files.
What we built
OptiFlight assigns staff to flights and turnaround tasks, and it keeps doing so while the day runs.
Track. Card readers record who arrived and who left, against the plan.
Understand. OptiFlight joins flight data from the AODB and Veovo with the task record and the roster. It plans from actual and scheduled times (ATA, STD) instead of a fixed timetable. Delays show up on the timeline as they happen. Each flight pair gets its ground time and task list fitted to the SLA, and overlapping assignments are flagged before they reach the ramp.
Manage. Each task is assigned and closed against the plan, so the record shows who did what, and when. New shifts and call-ins go out to staff as notifications.
Optimize. erdosP-3 holds Budapest Airport’s rules: qualifications and certifications, availability, rest rules, walking time between stands, the SLA and the collective agreement. When a flight is delayed or someone calls in sick, it re-solves only the part of the plan that changed and leaves the rest alone.
Re-plan in words. A supervisor can type one sentence, such as a sick call for the afternoon shift, and get back a re-solved shift. Every rule still holds in the new plan. The language model handles the conversation, the solver does the calculation, and every decision can be traced back to the rule behind it.
Close the loop. At the end of the day OptiFlight compares the plan with what actually happened and produces a certificate of completion. The measured task durations go into the next plan, so each plan is built on how long the work really took.
What changed
| Measure | Result |
|---|---|
| Paid hours | 21,000 → 17,000 a month at the same flight volume (−19%) |
| SLA breaches | 72% fewer |
| Overtime | 1,600 fewer hours a month |
| Planning time | 120 fewer hours a month |
The roster, leave, training expiry and reports now all come out of one system.
Source: production data, Budapest Airport.
Why it worked
- The rules are data, not code. Qualifications, rest rules and the collective agreement are set up as constraints in the solver. When a rule changes, we update the data and don’t have to rebuild the software.
- Only what changed gets re-planned. A delay or a sick call doesn’t throw out the whole day. The rest of the plan stays as it was, so staff aren’t moved around without a reason.
- Every decision can be traced. Supervisors can see which rule put each person on each task, so they can check a change before they act on it.
Where it applies
The same approach fits any handler that runs crews and equipment against a schedule that keeps moving. The constraints differ from one airport and contract to the next, and each set is configured as data in the solver. A new site means new data and new connections to its systems. The engine stays the same.