Five principles for a more dynamic airport support model

Airports rarely need to replace an entire support model in one step. The practical route is to agree the operating principles, understand where the current model sits against them, and test a dynamic approach within one terminal, process or operating window.

The five principles below come from ESP supporting operationally critical aviation systems across 300+ US airports, backed by a global IT-support footprint spanning 160+ countries.

In brief. A dynamic airport IT support model aligns engineering capacity with operational demand. It follows five principles: resource around the airport’s operating rhythm; prioritise passenger and operational impact; pool appropriately trained capability; use data to intervene earlier; and contract for operational outcomes alongside technical SLAs.

Dynamic support means putting the right capability in the right place at the right time and increasingly, acting before it is needed.

Why dynamic support is now practical

The operating data needed to make support more dynamic is increasingly available. SITA reports that 60% of airports already use AI in passenger-flow management, and 48% plan cross-silo data streaming, sharing and synchronisation by 2027. That is a stronger foundation for forecasting pressure and placing engineering capacity deliberately than most airports have had before.

48% of airports plan cross-silo data streaming, sharing and synchronisation by 2027.

Source: SITA Air Transport IT Insights 2025

Data alone does not create a dynamic service. Airports still need agreed decision rules, trusted ownership and contracts that allow insight to change priorities, staffing and preventive activity. That is where most models fall short, and it is what the five principles address.

1. Start with the operational rhythm

Resource design should reflect when demand occurs, not the airport’s opening hours or a historic roster. Passenger peaks, flight waves, seasonal patterns and operational hand-offs move pressure around the airport through the day. Support capacity should move with it and a model that cannot show how it does so is a fixed model, whatever the contract calls it.

Readiness question: Where does operational pressure move during the day, and does support capacity move with it?

Ask any provider: Show us last month’s engineer positioning against the flight schedule.

2. Prioritise impact, not just the asset

The importance of a device depends on passenger demand, available redundancy, location, alternative processes and the consequence of delay. A uniform response target is simple to write but rarely reflects the operational impact of a failure. ESP scores criticality in context rather than by asset class; the scoring model is part of how we design a service, not a schedule we publish.

The difference becomes clear in two everyday airport scenarios. In each case, the technical fault is relatively contained; its priority changes with the operational context around it.

Example 1 – e-Gate

An intermittent document-reader fault on a single E-gate may have little operational impact when passenger demand is low and other gates are available. During a peak arrival or departure period, however, the same fault can quickly reduce processing capacity and contribute to growing passenger queues. ESP considers demand, location and available redundancy when prioritising engineering resource.

Example 2 – Self-service kiosk

 A printer failure on one self-service kiosk may be minor when alternative kiosks are available. In a high-volume area during a busy departure period, the same fault can reduce available capacity, add to passenger queues and place extra pressure on airport or airline teams. ESP considers passenger demand, redundancy and alternative processes to direct resource where the immediate operational risk is greatest.

In both examples, operational context does not replace or override agreed response and resolution targets. It helps ESP decide how best to deploy available engineering resource within the contractual SLA – for example, prioritising a fault approaching its threshold with no immediate redundancy over a lower-impact incident that remains comfortably within its SLA.

3. Pool capability where it makes sense

Contract boundaries often prevent capable people from solving nearby problems. Sharing appropriately trained and security-cleared engineers across equipment types, suppliers, contracts or customers improves utilisation, resilience and skill development, and removes duplicated standby capacity. It also demands escalation, ownership and priority rules that a single-contract provider never has to build. ESP operates shared, security-cleared engineering teams across multiple airport customers: an arrangement that is simple to describe and hard to retrofit into a single-contract model.

Readiness question: Are contract boundaries preventing capable people from solving nearby problems?

Ask any provider: Which of your engineers on this site are cleared and trained to work across more than one contract, and how is priority decided between them?

4. Use data to intervene earlier

Combining passenger forecasts, incident history, device health, usage patterns and stock data allows a provider to prevent avoidable disruption, prepare for likely incidents and position people and spares before pressure arrives. The value lies less in the data that most airports already hold than in the decision rules that turn a signal into an action, and in a contract that permits the action.

Readiness question: Which recurring incidents could be predicted, prevented or resolved before a user reports them?

Ask any provider: How many dispatches did you avoid last quarter, and how do you know?

5. Contract for outcomes as well as response

Clear service commitments should remain. But a contract that rewards only rapid reaction after failure gives the provider no reason to prevent it. Operational measures such as avoiding passenger-impacting incidents, or protecting processing capacity during critical windows should sit alongside technical SLAs. Designing those measures so that they are fair, auditable and leave no ambiguity over accountability is contracting work in its own right. ESP builds it into the commercial model with each airport rather than adding it as a schedule.

Readiness question: Does the contract reward improvement, or mainly rapid reaction when something fails?

Ask any provider: Show us a contract where you are measured on what did not happen.

The ESP Dynamic Support maturity model

From principles to a pilot

The purpose of a pilot is not to prove that every support activity should become variable. It is to identify where fixed capacity is essential, where shared capability is stronger and where data can safely shape a more responsive service.

ESP runs this as a structured readiness assessment and controlled pilot within one terminal, process or operating window, with a baseline agreed at the start and a decision on refinement or scale at the end. A dynamic model should be more efficient because it is more closely aligned to how the airport actually works. That is the standard we ask to be judged against.

Frequently Asked Questions

Source: SITA, Air Transport IT Insights 2025 – Airports. Read the report