Guest experience
The guest-facing layer: kiosk, QR and surveys
The guest-facing layer covers everything a visitor touches: a self-service ordering kiosk, table QR menus with a live order tracker, and short surveys shown on the robot's own body display. Requests raised here become ordinary tasks in the same queue staff use, so nothing runs as a parallel system.
The part nobody trains for
Staff can be trained. Guests cannot. Anything a visitor touches has to work on the first attempt, without instruction, on whatever phone they happen to own — and it has to work for somebody who did not come to the venue to learn a system.
That constraint shapes the whole guest layer. There is no app to install. The kiosk runs on a screen in the venue. The table experience opens in a browser from a QR code. The survey appears on the robot itself, in front of the person who just had the interaction.
Kiosk and table, one catalogue
The kiosk is for the visitor standing in front of a screen: browse, choose, order. The table QR flow is the same catalogue in the guest's own hand, plus a live tracker for the order they just placed and a way to raise service requests — calling a waiter, asking for the bill.
Both read the same catalogue. That is a deliberately boring design decision and it prevents the failure that catches most venues eventually: two menus that drift apart until a guest orders something that was withdrawn last month.
Guest requests are just tasks
When a guest asks for the bill, that does not enter a special customer queue. It becomes a runtime task flagged as customer-originated and it is scored by the same assignment loop that handles everything staff created — priority, distance and battery, re-evaluated every two seconds.
Two systems that both dispatch robots will eventually disagree about which robot is free. One queue with a source label cannot.
Surveys at the moment, not the morning after
A survey emailed the next day measures who reads email. A survey on the robot's body display, immediately after the delivery, measures the delivery. Hybot shows short surveys there, and the submission does something useful as well as informative: after a brief delay it auto-confirms the robot's waiting confirmation step, so the robot releases itself and moves on.
That is the small kind of design detail that only shows up once you have watched people actually use a robot in a room full of other people.
What this is not
Hybot is a robot management platform with guest-facing surfaces attached. It is not a point-of-sale system, and whether it can talk to yours is a question about your system's API rather than a yes/no we can answer on a web page. Ask us about your stack and we will tell you what is involved.
Where this fits
Alongside fleet management, task automation and advertising on robot screens, under the platform overview.
Deeper reading:
Frequently asked questions
Do guests need to install anything?
- No. The kiosk runs on a screen in the venue and the table experience opens in a phone browser from a QR code. Requiring an app download at the moment of ordering is the single most reliable way to lose the order, so there is no app.
What can a guest ask for from the table?
- They can browse the menu, order, follow the order status live, and raise service requests such as calling a waiter or asking for the bill. Each request becomes a runtime task marked as customer-originated and is scored in the same queue as staff tasks.
Where are surveys shown?
- On the robot's own body display, at the moment of the interaction rather than in an email the next day. Submitting the survey also auto-confirms the robot's waiting step after a short delay, so the robot releases itself without anyone tapping a button.
Is the menu the same across kiosk and table?
- Yes. Both read the same catalogue, so a change to an item or its availability is made once. Maintaining two menus that drift apart is a support burden that eventually surfaces as a guest being charged for something that no longer exists.
Does this replace point-of-sale?
- No. Hybot is a robot management platform with guest-facing surfaces attached to it. Integration with an existing point-of-sale is an integration question, and the honest answer for any specific system is that it depends on that system's API.
Where this fits
This page is part of The platform behind every Hybot robot. If you are working through the topic in order, these are the neighbouring pages.
Robot fleet management across every site
Hybot fleet management shows every robot across every location in one view, queues remote commands, monitors heartbeats and rolls out updates per project.
How Hybot decides which robot does what
Hybot re-scores the task queue every two seconds and assigns each job by priority, distance and battery, with multi-step workflows and confirmation waypoints.
Advertising on robot screens
Hybot can schedule media to robot screens across a venue or a whole estate, with campaigns managed centrally and measured against the fleet's own counters.
See it running
A demo is the fastest way to judge whether this fits how your venue actually works.