The Market Formation Framework

Technology readiness answers a narrow question: can the system perform its intended task under defined conditions?

A deployment has to answer a larger one: can this site, offer, operating model, and local ecosystem turn that capability into a service worth continuing?

BeverageAutomata uses five dimensions to make that question testable:

1. Demand & Site
2. Experience & Offer
3. Operations
4. Unit Economics
5. Ecosystem & Regulation

Together they form the Market Formation Framework, the shared language across Evaluate -> Deploy -> Operate.

Evidence convention: External examples below establish only the observations linked to their sources. Hypothetical examples are labeled. Neither type is a performance benchmark or a BeverageAutomata deployment claim.

Why machine-first evaluation fails

A specification sheet can describe preparation steps, dimensions, theoretical capacity, supported recipes, and software features. It cannot tell an airport where technicians will enter a secure area, a hotel who will replenish milk after breakfast, or a workplace whether demand will survive a change in attendance.

Machine-first evaluation fails in three common ways:

• It treats traffic as demand without examining users, dayparts, visibility, dwell time, or willingness to pay.
• It counts removed tasks but omits new work in cleaning, monitoring, support, and exception handling.
• It projects technical throughput into revenue without accounting for queue behavior, menu mix, downtime, or site cost.

The framework does not make technology less important. It places technology inside the conditions that determine its value.

1. Demand & Site

This dimension defines the opportunity before selecting a configuration.

Ask:

• Who is the user: passenger, employee, guest, shopper, student, or existing F&B customer?
• Is demand repeat, impulse, captive, event-driven, or amenity-led?
• Which dayparts matter, and how uneven are the peaks?
• Does the site offer visibility, dwell time, safe queue space, and a clear customer path?
• Are power, water, drainage, connectivity, ventilation, and service access suitable?
• Who controls the location and can approve changes?

External observation: Cologne/Bonn Airport placed one robot barista in a publicly accessible departures area and another at baggage reclaim. The official announcement confirms two distinct passenger contexts, not that both produced equal demand. Source

Inference: A useful site plan would treat those positions as separate demand hypotheses and compare dayparts, conversion, menu mix, and service access rather than aggregating them as one “airport” result.

2. Experience & Offer

This dimension defines what the customer is actually being asked to adopt.

Ask:

• What menu solves the site’s service problem?
• What level of quality and consistency is required?
• How should price relate to staffed alternatives, convenience, and location?
• Can a first-time user order, customize, pay, wait, and collect confidently?
• Are language, accessibility, allergen information, and error recovery built into the journey?
• Does automation support the venue’s brand, or compete with it?

External observation: The Niska ice-cream bar opened at Melbourne’s Federation Square with one robot handling ordering, another scooping, and another adding toppings. A contemporary trade report documents the sequence and the public retail setting. Source

Inference: The visible sequence made preparation part of the experience. That can attract attention, but attention is not the same as repeat demand, acceptable service time, or willingness to pay. Those require separate evidence.

3. Operations

This dimension makes the remaining work visible and assigns it.

Ask:

• Who cleans each food-contact and customer-contact surface, and how is completion recorded?
• Who replenishes ingredients and consumables, at what trigger and from what storage?
• What is monitored remotely, and who receives alerts?
• Which incidents can on-site staff resolve, and which require a trained service partner?
• What spare parts, response windows, and escalation paths are realistic in this region?
• Who owns food safety, customer recovery, waste, and end-of-day procedures?

External observation: Reuters reporting republished by the World Economic Forum described Dubai’s RoboCafe as using robots for order preparation and delivery while people handled surface sanitization and technical glitches. Source

Confirmed fact: Some visible service steps were automated in that reported setup.

Inference: A transferable operating model would still need the frequency, skills, access, parts, cost, and accountability behind the human interventions. The report does not provide those details.

4. Unit Economics

This dimension tests whether the complete system can support a progression decision.

Build the model from site-level drivers:

• Transactions by daypart
• Average selling price and menu mix
• Ingredient, cup, topping, and waste cost
• Payment fees and taxes
• Site rent, concession, or revenue share
• Cleaning, replenishment, monitoring, and management labor
• Preventive maintenance, repairs, parts, and local support
• Downtime and failed-order recovery
• Depreciation, lease, financing, or pathway-specific capital cost

Hypothetical example: A station may reduce counter staffing for part of the day but require two refill visits, remote monitoring, and a service call allowance. The correct comparison includes all four effects. It does not count removed counter hours while treating the new work as free.

No universal transaction target, payback period, or Pilot duration belongs in the framework. The threshold depends on the site’s commercial purpose. A paid airport concession, an employer-funded amenity, and an experience-led hotel lobby can use the same station while requiring different evidence.

5. Ecosystem & Regulation

This dimension checks whether the deployment can exist locally, not only technically.

Ask:

• Which venue, technology, service, operations, ingredient, and experience partners are required?
• Can ingredients, consumables, and parts be supplied consistently?
• Who is the food business operator, and which approvals and records are required?
• Do payment, tax, privacy, cybersecurity, and data practices fit the market?
• Are language, accessibility, allergen, electrical, machinery, and facilities requirements addressed?
• Does the local service model match the promised operating window?

External observation: Cologne/Bonn Airport’s announcement names the airport, the MyAppCafe technology, and MyCoffeeTech franchisees as operators. Source

Inference: That named role structure is more useful for transfer than a machine-only description. It still leaves concession terms, cleaning responsibility, service levels, and current performance unknown.

The dimensions are a system

The framework matters most where dimensions collide.

A cold-dessert module may strengthen the offer but add cold-chain and cleaning burden. A high-traffic site may support demand while raising rent and restricting maintenance access. A larger menu may improve choice while slowing first-time ordering and increasing waste. Remote monitoring may reduce inspection visits while creating new connectivity and data responsibilities.

These are not reasons to reject automation. They are the design work that turns a possibility into a selected pathway.

Evaluate -> Deploy -> Operate

The same framework should survive the whole lifecycle.

Evaluate

Define users, site, offer, responsibilities, economic assumptions, and local dependencies. The Readiness Assessment identifies whether the opportunity is Ready to Explore, Needs Design Review, or Too Early for Pilot. An outcome is guidance, not acceptance.

When appropriate after qualification, a paid Deployment Blueprint can turn the five dimensions into a selected configuration, proof plan, responsibilities, and decision gates. It is not vendor-neutral sourcing or an arbitrary procurement specification.

Deploy

Confirm utilities, access, menu, payment, ingredients, cleaning, training, support, approvals, data permissions, and launch controls. Every assumption that matters to progression should have an owner and a way to be observed.

Operate

Compare evidence with the original assumptions. Do not allow installation to become the success metric. Review demand, customer completion, quality, incidents, labor, support, costs, compliance, and partner performance together.

How the framework governs the public product

• Readiness uses the five dimensions to expose missing conditions before a Pilot promise is made.
• Deployment Blueprint turns a qualified opportunity into a pathway-specific design and proof plan.
• Pilot tests the smallest complete operating system that can answer a real progression question.
• Market Reference records what was observed, what may transfer, and what remains unknown.
• Operate uses actual evidence to stop, redesign, extend, progress, or expand.

This common language prevents each stage from quietly changing the definition of success.

A concise opportunity worksheet

Write one evidence-backed sentence for each line:

Dimension	Current claim	Evidence available	Critical unknown	Owner	Decision date
Demand & Site	Who will use it, where, and when?
Experience & Offer	What will they buy and why?
Operations	Who keeps the service working?
Unit Economics	Which assumptions make continuation rational?
Ecosystem & Regulation	Which local conditions must align?

If a line cannot be completed, that is useful information. It identifies work for evaluation or a reason to wait. If every line is complete but unsupported, the opportunity is still a story rather than a deployment case.

Next step: Check Readiness against all five dimensions.