BellaBot: six months of telemetry in a 120-seat restaurant

The site is a full-service restaurant in a CIS city of a million: two dining rooms, an open kitchen, peaks at 12:00–14:00 and 19:00–22:00. The robot was launched under our Restaurant package — floor mapping, call stations on tables, staff training. The whole launch window took six weeks, four of which were shipping.

From here on, data only. Telemetry is collected as part of the Standard service plan; the owner saw the same numbers in quarterly reports and approved publication without naming the venue.

Average delivery time at peak dropped 19% — not because the robot is faster than a waiter, but because dishes stopped waiting at the pass: the machine works through the call queue while people stay with guests. The runner role disappeared entirely — two shifts of back-and-forth gone from the rota. An unexpected bonus the owner noticed himself: tips went up, because waiters now spend a third more time at the tables.

A word about the team. For the first two weeks the shift treated the machine as an auditor: “now everyone can see who walks how much”. The turn came when the cooks realised the robot takes the least loved runs — the far tables and the terrace. By the end of month one the shift had named the machine, and the head waiter was reassigning zones around its route himself. This is a typical adoption curve and worth planning for: two weeks of resistance is the norm, not a failure.

Both cases were closed under Standard with no invoice to the owner. A telling detail: the restaurant learned about the first incident from us — monitoring caught the anomaly before the shift noticed it.

Put call stations on every table from day one — we started with twelve “hot” ones and the robot ran underloaded for three weeks. And a 12-millimetre threshold by the bar, “perfectly normal”, cost us two weeks of detour routing. Threshold work is now in our site survey checklist by default.

The most common pre-sales question is “how does this talk to our till?”. The honest answer: on this site — it doesn't, and that was a deliberate decision. The loop is built around the call queue: a press on a table station goes to the orchestrator, the kitchen sees calls on a KDS screen (kitchen display system — the pass monitor), waiters get pagers. The robot pulls tasks from the queue by priority: zone, waiting time, charge level.

POS integration earns its keep when you need every delivery tied to a receipt and per-dish analytics — typically chains of five or more venues with their own analytics team. For a single restaurant it adds two to three weeks of negotiations with the POS vendor and a real budget line, while changing nothing about revenue. Our advice: start with stations and grow into POS integration when the data need appears, not on principle.

• ▸16 call stations — one per table including the bar and terrace; two spares in the manager's drawer.
• ▸A KDS screen at the pass — call queue and machine status; cooks stopped shouting “pick up twelve”.
• ▸A Wi-Fi survey before launch — two dead zones closed with an extra access point; the robot needs coverage on 100% of the route.
• ▸No POS integration — deliberately: for a single venue it does not pay itself back.

Over 182 days the machine went through two scheduled maintenance visits — quarterly per the plan. Each takes about two hours without stopping the shift: sensor and lidar cleaning, battery capacity measurement, wheel module check, firmware update with a rollback path in case of regression. All of it is inside the Standard plan, together with the remote monitoring that caught the sensor strip incident before the staff did.

The detail you will not see in a price list is the regional spare parts stock. The bumper on day 121 did not sail from Shenzhen for six weeks — it arrived from the regional warehouse in two days. In food service that is the difference between “the machine limps for two days” and “the machine sits idle for a month while the staff unlearns the routine”.

• ▸Bumpers and trim — the top consumable: contact with chairs and trolleys is inevitable.
• ▸Wheel modules as assemblies — swapped on site in 20 minutes, no alignment needed.
• ▸Sensor strips and trays — the parts a thousand hands touch every day.
• ▸One swap battery per region — for cells that degrade ahead of schedule.