Airport technology RFPs are often where digital ambition either becomes measurable progress or an expensive distraction. In 2026, airports are under pressure to reduce queues, improve passenger experience, increase non-aeronautical revenue, and strengthen operational resilience at the same time. This article explains how to write airport technology RFPs that define the real problem, set verifiable outcomes, and help you choose systems that deliver more than a glossy dashboard and a marginal gain.
Key Takeaways
- Start with the operational problem, not the product category.
- Write requirements that are measurable, testable, and tied to airport KPIs.
- Assess total cost, integration risk, and change management before vendor demos.
- Use pilots and acceptance criteria to prove value before full rollout.
What problem are you actually trying to solve?
The warning from former ACI chief Luis Felipe Oliveira is sharp because it reflects a painful reality: airports can spend heavily on technology and still see only small improvements if the requirement is vague. A passenger app, a biometrics lane, a queue-management platform, or a digital wayfinding layer may look modern on paper, yet fail to move the metrics that matter if the airport never defined those metrics in the first place.
Before a supplier conversation begins, the airport team should be able to answer one direct question: what would success look like in the terminal, on the curb, and in the commercial zone? If the answer is buried in generalities such as ‘better experience’ or ‘more efficiency,’ the procurement is already at risk. Clear intent is the difference between buying software and buying outcomes.
That is why the most effective airport digital strategy starts with pain points, not features. Are you trying to reduce missed flights caused by slow security processing, increase retail dwell time, improve resource allocation, or unify data across operational systems? Each goal leads to a different solution architecture, a different set of stakeholders, and a different definition of value.
What should a strong airport technology RFP actually contain?
A modern airport RFP should read like a decision tool, not a wish list. It needs enough precision to help vendors understand the environment, but enough flexibility to let them propose the best route to the result. The strongest documents usually include the same core elements: business objectives, current-state baseline, functional requirements, integration requirements, cybersecurity expectations, support model, and acceptance criteria.
Start with the operational baseline
Describe how the airport works today. That means passenger volumes by terminal or pier, peak-hour congestion points, existing systems, device inventory, manual workarounds, and known failure modes. A supplier cannot design a credible solution if it has to guess whether the airport struggles most with curbside flow, document verification, checkpoint throughput, or retail conversion.
The baseline should also include the constraints that shape real-world performance. Legacy infrastructure, fragmented data ownership, union rules, physical space limits, and seasonal traffic swings all matter. Airports are living systems, not blank slates, and an RFP that ignores this context invites oversimplified proposals.
Define outcomes in measurable language
Replace vague aspirations with measurable targets. Instead of asking for ‘improved passenger satisfaction,’ specify the operational change you expect to see: reduced average queue time, faster self-service adoption, fewer manual interventions, higher first-time success rates, or more accurate passenger flow visibility. These targets should be tied to a baseline and a measurement method, or they will be impossible to prove after deployment.
When requirements are written this way, the airport can evaluate bidders against evidence rather than rhetoric. It also becomes easier to reject proposals that promise everything while proving nothing. Clear, verifiable requirements are central to disciplined procurement practice, and that approach aligns with the ISO/IEC/IEEE 29148 requirements engineering standard, which emphasizes defining requirements in ways that can be validated and traced through delivery.
Demand integration, not just functionality
In airports, standalone tools rarely stay standalone for long. Passenger processing platforms must often connect to AODB, FIDS, biometric identity systems, queue analytics, retail systems, baggage operations, or building management systems. If integration requirements are left vague, the airport may end up with a polished interface that still requires manual reconciliation behind the scenes.
Strong RFPs ask vendors to explain data models, APIs, interoperability standards, and ownership of interfaces. They should also specify whether the solution must support open architecture, real-time event sharing, offline fallback, and scalable multi-terminal deployment. In 2026, software that cannot integrate cleanly is not an asset; it is a future bottleneck.
How do you prove the investment will pay back?
Airport technology investment is often justified with language that sounds persuasive but remains untested. The better approach is to build a benefits model that connects the proposed system to a named business outcome. If the airport is buying a queue-management platform, for example, the value may come from reducing passenger frustration, improving staff deployment, and freeing capacity during peaks. If it is buying a self-service solution, the value may come from higher transaction speed, better throughput, and lower reliance on manual check-in.
The trick is to separate direct value from indirect value. Direct value is easier to measure: shorter processing times, fewer manual exceptions, stronger uptime, or lower support calls. Indirect value may be equally important, but it should still be described carefully: improved dwell time, higher retail conversion opportunities, or better staff productivity. When both are included, the airport can build a more realistic return-on-investment case without overstating the result.
Examples help sharpen the analysis. If a terminal is experiencing chronic peaks at security or check-in, even a modest reduction in friction can create a visible shift in passenger flow and staff workload. But the improvement has to be measured from a stable baseline, using the same method before and after deployment. That is why post-implementation review should be designed before procurement is complete, not after the contract is signed.
Which technologies need the strictest requirements?
Some airport technologies are especially vulnerable to hype because they are sold as transformation engines. Biometric boarding, smart queue systems, airport apps, wayfinding platforms, and AI-assisted operations tools can be powerful, but only when the airport defines where they fit in the passenger journey and how they will be governed.
Passenger-facing systems
For apps, kiosks, and digital wayfinding, requirements should focus on usability, accessibility, content accuracy, and multilingual support. Passengers do not care that the backend is elegant if the interface is confusing, slow, or inconsistent across devices. If the airport serves international travelers, accessibility and language support should be treated as core requirements, not optional extras.
Identity and throughput systems
Biometric and document-verification systems need especially careful scoping because they sit at the intersection of experience, security, and privacy. The RFP should define the trust model, fallback process, consent handling, retention rules, and operator training requirements. It should also require vendors to describe failure handling, because even a high-performing system needs a human-safe backup when capture quality is poor or network conditions are unstable.
Operational analytics and AI tools
Analytics platforms sound persuasive because they promise visibility, prediction, and optimization. Yet an airport gains little from a model that cannot explain its outputs, integrate with live operational data, or support practical decision-making during disruption. The requirements should ask how the tool will be validated, how often it refreshes data, and how staff can act on its recommendations without creating new complexity.
How do you separate real fit from polished vendor promises?
The most expensive procurement mistakes often begin with a convincing demo. A vendor can make almost any airport process look simple in a controlled presentation, so the RFP process must force proof. Ask suppliers to respond to real use cases from your airport, not abstract feature lists. The best responses will show how the solution behaves under pressure, during irregular operations, and across different terminals or passenger profiles.
Score proposals with a weighted model that reflects airport priorities. Technical fit matters, but so do implementation risk, support quality, integration effort, cyber posture, and total cost of ownership. A cheaper proposal that needs endless customization or costly third-party middleware can become far more expensive than a slightly higher-priced alternative that fits the environment cleanly.
References should also be interrogated with discipline. Do not ask only whether the vendor was ‘good to work with.’ Ask how long deployment took, what changed after go-live, which metrics improved, where the gaps were, and what would be done differently in a second rollout. Those answers reveal maturity far more clearly than a polished case study.
What does a future-ready procurement process look like in 2026?
Future-ready procurement is not about chasing the newest tool. It is about building a repeatable discipline that lets the airport adapt without starting from zero every time a new problem appears. That means involving operations, security, IT, commercial teams, facilities, and customer experience leaders early enough to shape the brief, rather than asking them to react to a nearly finished requirement.
It also means treating change management as part of the solution. A brilliant system that staff do not trust will underperform. A powerful platform that requires too much manual correction will drain the very efficiency it was supposed to create. Training, adoption support, governance roles, and escalation paths should therefore appear in the RFP, not as an afterthought but as part of the delivered value.
Cybersecurity and data governance deserve equal weight. Airports manage sensitive operational and identity-related information, and every additional platform expands the attack surface. The procurement should ask vendors to explain encryption, access control, logging, incident response, data residency, retention, and patching responsibilities in plain language. If the answer is unclear, the risk is not theoretical; it is operational.
How can airports turn RFP discipline into visible passenger value?
The real power of a strong RFP is that it forces the airport to make choices before money is spent. It prevents technology from drifting into the terminal as a vague promise and instead ties it to a measured outcome: shorter waits, calmer flows, better staff allocation, clearer information, stronger revenue capture, or more resilient operations.
That is the lesson hiding inside the current warning from airport leaders: technology does not fail because it is modern, and it does not succeed because it is fashionable. It succeeds when the airport knows exactly what it wants, can measure whether it got it, and can hold every bidder to the same standard. If you are preparing an airport technology RFP now, start by writing the one sentence that defines the operational problem, then build every requirement backward from that sentence.
Frequently Asked Questions
How do we define success if the airport wants several things at once, like shorter queues and higher retail revenue?
Use a hierarchy of outcomes rather than one broad goal. Identify the primary KPI, such as queue time reduction, and then list secondary benefits like dwell time or retail conversion. In the RFP, specify how each metric will be measured and which team owns it, so vendors optimize for the full business case instead of one isolated function.
Why is it risky to ask vendors to propose the solution before we define the problem in detail?
Because vendors will usually answer with the tool they already sell best, not necessarily the tool that fits your airport’s bottleneck. If the problem is unclear, you may compare polished demos that solve different issues. A precise problem statement helps you filter out attractive but irrelevant proposals and avoid buying technology that does not change airport performance.
What level of detail should be included in the operational baseline without turning the RFP into a technical report?
Include only the details that affect solution design and measurable outcomes: traffic volumes, peak periods, current systems, known bottlenecks, manual processes, and infrastructure constraints. You do not need a full engineering dossier, but you do need enough context for vendors to understand where the airport is starting from and what conditions their solution must work within.
How can an airport evaluate integration risk before choosing a vendor, especially when existing systems are legacy or fragmented?
Ask bidders to describe exactly how their system connects to current platforms, what data it requires, what interfaces it supports, and what dependencies could delay deployment. Require references for similar environments and a phased integration plan. The key is to test whether the solution fits your architecture, not whether it works in a controlled demo.
Why are pilots and acceptance criteria emphasized so strongly in airport technology procurement?
Because airport technology often looks successful in presentations but performs differently under real passenger flow, staffing constraints, and data conditions. A pilot lets you verify actual behavior before committing fully. Acceptance criteria turn subjective promises into pass/fail checks, making it much easier to confirm whether the system delivers the operational value the RFP promised.
What is the most common mistake airports make when comparing technology bids?
They focus on feature lists and total price instead of outcome certainty. A cheaper bid can become expensive if it needs heavy customization, difficult integrations, or extra staff to manage it. Comparing bids on measurable results, implementation risk, support model, and lifecycle cost gives a far more realistic view of which proposal will create passenger value.