Solicitar piloto

Search

Article · Deployment Systems

Why Airports Matter as Reference Nodes

Airports can reveal whether beverage automation works across demand, experience, operations, economics, and ecosystem constraints, but they are demanding places to prove it.

BeverageAutomata Editorial7 min read

Available in English

An airport can make an automated beverage station highly visible. Visibility is not the main reason the site matters.

Airports concentrate multiple user groups, irregular peaks, extended service windows, multilingual journeys, payment expectations, concession structures, security boundaries, and tightly managed facilities. A station that works there can generate unusually rich deployment evidence. A station that merely attracts attention can also fail in unusually public ways.

That makes an airport a potential reference node: a location where evidence can teach another site what conditions matter. It does not make every airport a good site, or every airport result transferable.

Evidence boundary: Cologne/Bonn Airport and Barcelona-El Prat examples below are external cases. Their official pages confirm configurations and locations, not utilization, uptime, profitability, or current expansion. BeverageAutomata’s first flagship showcase target is a European airport. It is a target, not a completed BeverageAutomata deployment.

What makes a location a reference node

A reference node is more than a prestigious address. It has four properties.

  1. The operating context is legible. Readers can identify the users, site zone, offer, roles, and constraints.
  2. The evidence covers the system. The record includes customer behavior, operations, economics, and partner performance, not only installation photos.
  3. The limits are visible. Novelty, seasonality, temporary promotions, missing data, and exceptional support are disclosed.
  4. Transfer requires conditions. Another site can state what it would need to reproduce before expecting a similar result.

An airport is useful because it puts many of those conditions under pressure at once. That is also why a successful demonstration inside a terminal should not be mistaken for a mature operating reference.

There is no single airport customer

“Passenger traffic” is too broad to be a demand model. An airport station may serve:

  • Departing passengers before security
  • Departing passengers after security
  • Arriving passengers at baggage reclaim
  • Connecting passengers near gates
  • Lounge guests
  • Airline, airport, retail, and service employees
  • Meeters, greeters, drivers, and other landside visitors

Each group has different dwell time, urgency, repeat potential, price context, and access.

Cologne/Bonn Airport announced two MyAppCafe robot baristas in Terminal 2 in May 2024. One was placed in the publicly accessible departures area and the other at baggage reclaim. That confirms two different site positions. It does not confirm that they serve the same demand or perform equally. Official airport source

For a real Pilot, those positions would need separate hypotheses. The departures unit might be affected by time-to-flight and pre-security alternatives. The baggage-reclaim unit might encounter waiting parties, arriving passengers, and access restrictions. These are deployment inferences, not reported outcomes from Cologne/Bonn.

Experience is part of throughput

Airport users may be tired, hurried, carrying bags, traveling with children, unfamiliar with the language, or unsure whether they have time to order. The interface is therefore not decoration around technical preparation. It determines whether theoretical capacity can become completed orders.

A deployment should test:

  • Whether the menu can be understood quickly
  • Whether language selection is visible before a customer commits
  • Whether allergen and ingredient information is accessible
  • Whether payment methods fit local and international users
  • Whether order status and collection are unambiguous
  • Whether the station works for different heights, mobility needs, and baggage situations
  • Whether a failed order has an immediate recovery path
  • Whether the queue remains clear of passenger flow

The Cologne/Bonn announcement confirms app or on-device ordering, cashless payment, multiple cup sizes, hot and iced drinks, and paid extras. Those are offer facts. The announcement does not report completion rates, accessibility testing, failed-order rates, or passenger feedback. A Reference should preserve that distinction.

Barcelona-El Prat provides a useful adjacent example. Aena’s page for the SELF robotic restaurant in Terminal 1 says a robotic arm manages and delivers orders with the help of human staff. That phrase is operationally important: the public experience can feature automation without hiding the support model. Official Aena source

The difficult work sits behind the passenger view

Airports add constraints that a normal retail site may not share.

Access and security

Ingredients, consumables, tools, and technicians may need access to controlled zones. A repair that takes thirty minutes on a workshop floor can create a longer service interruption when travel, screening, permits, escorts, or restricted working windows are involved.

Facilities

Power, water, drainage, network access, fire rules, waste routes, and floor loading have to fit the selected position. A compact customer footprint can still require back-of-house storage and a practical service path.

Concessions and commercial roles

The airport, concessionaire, franchisee, technology provider, ingredient supplier, payment provider, and service partner may all hold different rights and responsibilities. The Cologne/Bonn announcement, for example, identifies MyCoffeeTech franchisees as the operators of the two units. It does not publish the airport’s concession terms or full responsibility matrix.

Food safety and service recovery

Long availability creates recurring cleaning, replenishment, temperature, allergen, and waste work. When a drink is incomplete or unsafe, the operating model needs a fast human response even if the normal transaction is automated.

The test is not whether these constraints can be listed. It is whether named parties can meet them at the intended operating hours and record what happened.

Unit Economics and the novelty trap

An airport can produce high visibility and strong initial curiosity. Neither is durable demand.

A credible economic review separates:

  • Passersby from people who begin an order
  • Begun orders from completed and paid orders
  • First-time curiosity from repeat employee or frequent-traveler use
  • Gross sales from site, ingredient, payment, labor, support, and downtime costs
  • Theoretical capacity from realized throughput at actual peaks
  • Launch-period support from the support model expected after the Pilot

It also identifies the station’s commercial purpose. A unit may be expected to generate direct profit, extend service into an underserved daypart, improve a lounge offer, serve staff, or test a new concession format. Those are different objectives and require different progression gates.

There is no responsible universal claim that airport traffic guarantees attractive economics. Traffic is an input. The location, offer, conversion, cost structure, and operating burden decide what that input becomes.

What evidence should an airport Pilot produce?

Across the Market Formation Framework, a useful proof package would include:

Dimension Evidence to collect
Demand & Site Relevant traffic, transactions, dayparts, conversion, queue behavior, repeat use, and site interruptions
Experience & Offer Menu mix, price response, ordering completion, language use, accessibility findings, complaints, refunds, and quality checks
Operations Uptime definition, incidents, cleaning and refill work, labor time, stockouts, service access, response time, and waste
Unit Economics Revenue, ingredient and consumable cost, payment fees, site cost, labor, support, downtime, and sensitivity to demand
Ecosystem & Regulation Partner performance, access approvals, food-safety records, supply continuity, payment reliability, and facilities compliance

Metrics need definitions. “Uptime” might exclude planned cleaning, network outages, ingredient stockouts, or payment failures unless the team agrees otherwise. A Reference that publishes a percentage without the denominator, time window, and exclusions is difficult to transfer.

How evidence transfers to another node

Before another airport, station, or transport hub learns from a result, compare:

  • Passenger and employee mix
  • Airside or landside position
  • Dwell time and peak pattern
  • Menu, price, and staffed alternatives
  • Payment and language requirements
  • Concession and site-cost structure
  • Security and maintenance access
  • Local ingredient and parts supply
  • Cleaning, replenishment, and service coverage
  • Food-safety, accessibility, data, and facilities rules

The transferable asset is not “a robot worked at an airport.” It is a documented relationship between conditions, operating choices, evidence, and decisions.

Why the first node matters

BeverageAutomata is building toward a European airport as its first flagship showcase target because such a node can make the deployment system visible: market evaluation, site design, partner roles, operations, economics, and evidence can be examined together.

That ambition creates a stricter standard, not permission to claim a result early. Until a deployment is delivered, operated, evidenced, and approved for publication, it remains a target.

Next step: Parties with authority over a real airport or transport site can Apply for Pilot. Technology, service, ingredient, and operating contributors without site authority should Apply to Partner.