The CUSS Handbook  /  Evaluating a common-use deployment

Evaluating a common-use deployment

Most common-use business cases are written as a comparison of unit prices, and most of the value and most of the risk sit somewhere else entirely. This page is about where to look.

Start with the problem, not the technology

Common use is a means to an end, and the end differs by airport. It is worth writing down which of these is actually driving the programme, because they lead to different specifications:

• Deferring capital works. Higher utilisation of existing hall space postpones terminal expansion. This is the largest financial argument and the one most often left implicit.
• Commercial flexibility. The ability to reallocate a hall between carriers without construction, on a timescale of days rather than years.
• Serving a long tail of carriers. Airlines with a handful of weekly departures cannot justify dedicated infrastructure. Common use is how they are served at all.
• Resilience. A generic estate can absorb a disruption by reallocating; a dedicated one cannot.
• Passenger throughput. Real, but the weakest argument to lead with, because throughput gains depend on adoption and adoption depends on things outside the platform.

The Airport Cooperative Research Program has published extensively on developing a common-use programme at a whole-airport level; its web resource on holistic common use programmes is a better starting point for the strategic layer than any vendor material, and its deep dive on programme development goes further into implementation.

Questions that belong in the requirement document

Ordered roughly by how much trouble they save later.

1. Which standard, which version? Name the Recommended Practice and the specification version, and be explicit about the CUSS 2 transition. A platform procured today against a retired generation is a short-lived asset.
2. What is certified, by whom, and with which counterparties? See certification. Insist on the version and the independence of the process.
3. Which carriers have working applications on this platform today? The gap between “supports the standard” and “this specific airline's application has been demonstrated on it” is where launch delays are manufactured.
4. What does system management actually give an operator? Ask for a demonstration against a fault, not a screenshot. Ask specifically how an operator identifies which unit in a hall of hundreds is failing and why.
5. How is availability defined and measured? A unit with a dead bag-tag printer is available by most naive definitions and useless in practice. Define availability by function, per device, per location.
6. How does a new airline get onboarded? Elapsed time, test environment, cost, and who bears it. This is the number that determines whether the flexibility you are buying is real.
7. How is accessibility satisfied and evidenced? Which units, in which clusters, with which functions, and who is accountable. See kiosk accessibility.
8. What is the recharge model? Per transaction, per position, per carrier, fixed? This determines whether airlines adopt, and no amount of platform quality compensates for a model they will not accept.
9. What is the exit? If the platform is replaced in seven years, what is reusable — enclosures, network, mounting, cabling — and what is stranded?

Numbers worth measuring

Before and after, and consistently:

• Adoption rate per carrier and per hall: what proportion of eligible passengers actually complete the self-service transaction. This is the single most informative number, and it varies enormously between airlines on identical hardware.
• Completion rate: of passengers who start, how many finish unaided. A low completion rate with high adoption is a design problem, not a capacity problem.
• Fallback rate: how many end up at a staffed desk anyway. Fallback is the true cost of a bad flow, and it lands on staff rosters rather than on the technology budget.
• Availability by function, as above.
• Onboarding elapsed time for each new carrier.
• Space released or deferred, expressed as capital works avoided, which is the metric the business case was actually built on.

Numbers that mislead

Transactions per hour under test. Measured in a lab with a cooperative operator, it bears little relation to a hall containing families, oversized bags and people flying for the first time.

Unit price. The purchase price of a kiosk is a small share of lifetime cost next to integration, certification, onboarding, maintenance and the eventual platform migration.

Number of airports a supplier lists. It says nothing about the size, the standard version, or how those deployments are running now.

Aggregate accessible-kiosk percentage. The US rule works per cluster, so an airport-wide figure can look compliant while individual locations are not.

The failure modes to plan against

The launch-carrier trap. Everything is proven with one airline, and the second one exposes assumptions baked into the platform. Onboard two carriers before go-live, ideally two with different application suppliers.

Availability defined too loosely, so a partially broken estate reports as healthy.

Accessibility left to the end, when it is a physical property of the enclosure, the controls and the application, and cannot be retrofitted cheaply.

No agreed operating model. The role split and the service level agreement are the operational design, not paperwork produced after selection.

Ignoring the standards roadmap. Buying at the end of a generation is how an estate becomes a migration project on day one.