Beyond Coffee: Designing a Modular Beverage Station

Available in English

Modularity sounds efficient: begin with coffee, then add tea, cold dessert, alternative milk, or another offer as demand appears. In practice, every module adds more than menu items. It can add ingredients, storage states, cleaning paths, allergens, waste, failure modes, service parts, interface choices, and supplier dependencies.

A good module expands a coherent service. A weak module turns one station into several unfinished operating systems sharing a cabinet.

BeverageAutomata treats the robotic coffee station as the core V1 format. Fresh Chinese and other high-value tea, ice cream coffee and cold dessert, and oat or alternative milk are modular directions. They are not a claim that every configuration is built, proven, or available in every market.

Evidence boundary: The design tests below are editorial deployment guidance. A confirmed fact is limited to what a linked source documents; an inference is a design conclusion that still requires site-level testing. Any unbuilt combination is a concept until a selected technology pathway, site, and operating proof exist. Regulatory links identify relevant EU source material but do not replace local legal, food-safety, or engineering review.

Core station versus module

The core station should be able to operate as a complete service on its own. It needs a defined customer, menu, quality standard, ordering and payment journey, ingredient system, cleaning plan, support model, and economic purpose.

A module is justified only if it does at least one useful job:

• Serves a distinct demand segment or daypart
• Strengthens the site’s experience or product position
• Uses existing infrastructure efficiently
• Improves menu resilience or inclusion
• Creates enough incremental value to pay for its operating burden

“Customers might like more choice” is not enough. Choice can slow ordering, dilute ingredient turnover, increase stockouts, and make troubleshooting harder.

Before adding a module, write two statements:

1. Demand claim: Which users will choose this offer, when, and instead of what?
2. Operating claim: Which existing station capabilities can support it, and which new responsibilities must be added?

If either statement is vague, the module is not ready for configuration.

Fresh Chinese and other high-value tea

Tea should not be treated as coffee with different packaging. The offer can vary by leaf format, origin, oxidation, extraction method, temperature, strength, steeping sequence, and cultural expectation.

Demand & Site

Identify whether tea serves an existing audience, a particular daypart, a premium experience, or a gap in the coffee-led menu. A high-value tea offer may require more explanation and a longer decision time than a familiar coffee order. That changes interface and queue design.

Experience & Offer

The menu must explain enough to support a confident choice without becoming a lesson customers cannot finish. Name the tea, preparation method, serving size, temperature options, and relevant provenance accurately. Do not use origin as decoration when the supply record cannot support it.

Operations

Define leaf or concentrate storage, dosing, water temperature, extraction, residue removal, cross-contact controls, cleaning frequency, and quality checks. If different teas need incompatible preparation paths, the module may be several modules in disguise.

Unit Economics

Model ingredient yield, spoilage, preparation time, cup and filter consumables, menu price, and expected mix. A premium ingredient with low turnover can create waste even when gross margin per sold cup appears attractive.

Ecosystem & Regulation

Confirm traceable supply, labeling, import conditions where relevant, food-safety ownership, and the service partner’s ability to maintain the preparation hardware. A recipe that works in a test kitchen is not yet a regional supply system.

Ice cream coffee and cold dessert

Cold dessert can create a differentiated, highly visible offer. It also changes the risk profile of the station.

Demand & Site

Test seasonality, dayparts, family or leisure traffic, dwell time, and the relationship to the core coffee offer. An airport, shopping center, hotel, and workplace can produce very different dessert demand even with similar footfall.

Experience & Offer

Texture, temperature, topping sequence, visual presentation, collection timing, and melt behavior are part of the product. The station must communicate allergens and incomplete-order recovery clearly. A visually theatrical handoff cannot compensate for an unstable product.

Operations

The module may add refrigerated or frozen storage, temperature monitoring, dairy handling, topping replenishment, drip and spill control, more complex cleaning, and a different waste stream. The service design must cover what happens after a temperature excursion or a product that cannot be served.

EU food hygiene rules place responsibility for food safety on the food business operator and specifically identify maintaining the cold chain for food that cannot be stored safely at ambient temperatures. Regulation (EC) No 852/2004

Unit Economics

Model seasonality, energy, product loss during faults or cleaning, toppings, cups, spoons, labor, and service. Incremental revenue should be compared with the module’s incremental cost and the risk it adds to the core station.

External reference, with limits

Niska’s robotic ice-cream bar opened at Melbourne’s Federation Square in 2019 with separate robots for ordering, scooping, and toppings. A contemporary trade source documents the public retail sequence. Niska’s later history says the system was subsequently dismantled and modified for another market. That lifecycle is more informative than treating the launch as permanent scale. Contemporary report Niska history

The sources do not provide independently verified profitability, uptime, or labor data. The transferable lesson is that a dessert module can require an entire orchestration layer, and that localization may be significant.

Oat and alternative milk

Alternative milk may look like a small ingredient substitution. It touches recipe behavior, storage, allergens, cleaning, supply, interface, and price.

Demand & Site

Measure actual selection or unmet demand by site and daypart. Do not use a general market trend as the station’s demand forecast.

Experience & Offer

Test taste, texture, temperature, and recipe performance for each supported drink. The interface should state the ingredient and any surcharge before payment. “Plant-based” should not be used as a shortcut for allergen-free or universally suitable.

Operations

Define storage conditions, opened-product life, separation or agitation needs, line assignment, purge or cleaning procedures, and out-of-stock behavior. Decide whether the module shares a path with dairy or uses dedicated components, then document the consequences.

Unit Economics

Include purchase cost, yield, opened-pack waste, cleaning, dedicated hardware where needed, and demand sensitivity. A rarely selected option can create disproportionate waste; a frequently selected option can justify a more robust dedicated path.

Ecosystem & Regulation

Confirm supplier continuity and accurate ingredient and allergen information. In the EU, allergen information is mandatory for non-prepacked food offered to final consumers. European Commission guidance

Local requirements and recipes still need market-specific review.

Shared systems and module-specific burden

The strongest modular architecture shares stable infrastructure while isolating risks that should not be shared.

System	Potentially shared	Often module-specific
Customer journey	Display, payment, order status, receipt	Education, modifiers, allergen prompts, collection instructions
Site	Power, water, drainage, network, footprint	Refrigeration, ventilation, storage, waste route, service clearance
Preparation	Some robotics, cup handling, telemetry	Extraction, frozen dispensing, toppings, milk paths, temperature control
Supply	Ordering process and inventory records	Tea formats, frozen mix, toppings, alternative-milk suppliers
Cleaning	Scheduling, records, escalation	Food-contact paths, dairy and allergen controls, defrost or sanitation cycles
Service	Monitoring platform and first response	Module skills, tools, spare parts, calibration, recovery procedure
Economics	Site cost, payment fees, shared labor	Ingredient yield, energy, waste, maintenance, seasonal demand

Sharing hardware is not automatically efficient. If a shared component allows one module’s fault, allergen risk, or cleaning cycle to stop every offer, separation may be worth the cost.

A module decision scorecard

Evaluate each proposed module from 0 to 2 on the questions below. A score is a discussion tool, not an approval algorithm.

Demand & Site

• Is there site-specific evidence of demand?
• Does the module serve a defined user or daypart?
• Does the site support its storage, utilities, and customer flow?

Experience & Offer

• Does it strengthen a coherent menu?
• Can users understand price, ingredients, allergens, and collection?
• Has quality been tested in the intended configuration?

Operations

• Are cleaning, replenishment, monitoring, and recovery assigned?
• Can the core station continue safely if the module is unavailable?
• Are staff time, access, training, and records realistic?

Unit Economics

• Is incremental demand separated from substitution of core drinks?
• Are waste, service, energy, and downtime included?
• Is there a clear decision threshold for keeping the module?

Ecosystem & Regulation

• Are suppliers, parts, support, and approvals available locally?
• Are food-safety and allergen responsibilities documented?
• Can the module be supported for the promised operating window?

Any zero in safety, regulatory responsibility, or operational ownership is a stop condition, regardless of the total.

Add, sequence, or reject

There are three responsible outcomes.

Add now when demand, configuration, ownership, supply, economics, and compliance are sufficiently defined to test together.

Sequence later when the module is promising but would obscure the core station’s proof. Establish the coffee operating baseline first, then add one module with a separate question and measurement plan.

Reject for this site when the module weakens menu coherence, creates unsupported operational burden, lacks supply or service coverage, or cannot meet safety and economic requirements. Rejection is a design decision, not a judgment on the category.

The aim of modularity is not the largest menu. It is a station that can evolve without losing clarity, safety, serviceability, or economic control.

Next step: F&B and ingredient teams can Apply to Partner; site owners evaluating a configuration should Check Readiness.