Reception and concierge robots for UK workplaces

A reception robot should make a defined visitor journey easier. It should not become an obstacle between a visitor and the person who can help them. The strongest deployments give the robot a small number of clear interactions, make human escalation obvious and preserve an accessible non-robot route.

This guide helps UK workplaces scope a reception or concierge pilot before they compare social and service robots. It is operational guidance, not a claim that a particular model will navigate, integrate or converse successfully in your building.

Map the visitor journey first

Write down what happens from arrival to handover. A useful map may include:

1. The visitor finds the reception point.
2. They choose a language or accessible alternative.
3. They identify the host or destination.
4. The system notifies a person or provides directions.
5. The visitor receives a badge or waits in a defined area.
6. A staff member takes over when the process does not fit.

Now choose one or two stages for the robot. Trying to make it greet, identify, register, guide, answer open questions, print badges, control doors and entertain people in one launch increases both integration work and failure paths.

Good task statements are bounded: “Offer three destination choices and call the staffed desk when the visitor selects help.” Weak statements rely on human judgement the machine has not demonstrated: “Understand every visitor and solve their problem.”

Choose interaction before appearance

Reception robots fall into different practical formats.

• A fixed or mostly fixed social robot can deliver a scripted welcome, show information and call a staff member.
• A wheeled guide robot can lead visitors on validated indoor routes, subject to doors, lifts, traffic and navigation conditions.
• A mobile display robot can present wayfinding or campaign content without pretending to hold a natural conversation.
• A premium expressive humanoid can anchor a staffed demonstration or event, but may not provide building navigation.

Pepper is a recognisable legacy social platform, but the manufacturer says it is definitively out of stock. Any UK deployment therefore needs the exact hardware generation, battery condition, supported software and cloud dependencies confirmed. The Pepper documentation should be checked against the serial-numbered unit rather than treated as universal.

Engineered Arts describes Ameca as an expressive humanoid interaction platform. It is not a walking concierge or labour robot. A PUDU KettyBot-style platform may provide mobile advertising and guidance functions, but the UK-listed KettyBot must not be assumed to have every current KettyBot Pro feature. Model generation matters.

Design the human escalation route

Every screen should provide a clear way to reach a person. Every spoken interaction should have a fallback when speech recognition fails, the visitor does not want to talk, or the request is outside the script.

Define:

• who receives help requests;
• the expected response during staffed hours;
• what happens outside staffed hours;
• what the robot says when the connection fails;
• how a visitor abandons or corrects an interaction;
• who can pause the robot or move it out of service;
• where urgent, safeguarding or security issues go immediately.

Do not use a conversational model as the authority for building access, emergency instructions, HR matters or security decisions. Keep approved information narrow and version controlled. If an answer could materially affect a visitor, route it to a person.

Preserve an accessible alternative

Do not make successful robot use a condition of entering, checking in or receiving help. Test the experience with different heights, mobility aids, vision, hearing, speech and language needs. Consider screen reach, glare, text size, audio volume, captioning, interaction timeouts and the physical space needed to approach and turn away.

The practical rule is simple: provide the same destination through a staffed, phone, text or conventional signage route. Ask disabled users to test the actual setup before launch. This article does not make a legal accessibility determination; it identifies evidence a workplace should gather.

Also inspect circulation. A robot parked in front of the desk can create a pinch point. A guide robot can attract followers who block a corridor. Test queues, passing space and emergency routes at representative occupancy, not only in an empty lobby.

Decide what data is genuinely needed

Cameras and microphones may support navigation or interaction, but that does not mean the organisation needs to identify people or retain recordings. Document each sensor, its purpose, what data leaves the device, who receives it, retention, remote access and the behaviour when cloud services are unavailable.

The Information Commissioner’s Office provides current guidance on video-surveillance data protection principles and separate guidance on monitoring workers. Use those sources with your privacy lead. Do not assume a supplier’s default setting matches your purpose, signage or retention policy.

Create a data map before connecting visitor records, calendars, access-control systems or analytics. Give the supplier only the access needed for the agreed workflow. Record how access is removed after a trial.

Run a representative pilot

Test the actual reception at quiet and busy times. Include expected visitors, unannounced arrivals, delivery drivers, people with no appointment, non-native English speakers and people who immediately request human help. Do not record personal details in the pilot report unless required and appropriately controlled.

Measure workflow facts rather than novelty:

• proportion of attempted journeys completed without staff correction;
• requests escalated and time to human response;
• navigation interventions by location and cause;
• abandoned interactions;
• accessibility issues and alternative route use;
• incorrect, outdated or unapproved answers;
• daily setup, charging and support work.

Do not convert smile counts, photographs or dwell time into a business result without a defined method and purpose. The pilot should decide whether the workflow is reliable and acceptable, not prove that visitors enjoy robots.

Questions for a supplier demonstration

Ask the supplier to show, not just describe:

• the exact model and software version;
• local and cloud-dependent functions;
• the visitor-data flow and administrator controls;
• route editing, door and lift assumptions;
• speech fallback and human handover;
• emergency stop, manual movement and recovery;
• accessibility settings;
• support response and offline procedure.

Then put the answers into acceptance criteria. The robot deployment checklist provides the wider site-to-handover structure.

If you have a reception journey in mind, share the task and constraints for research guidance. Include a floor plan, visitor types, required integrations and the human fallback. That gives Robotysys context for relevant research without implying that a demonstration or supplier offer is available.