How to prepare a hotel for a service-robot pilot

A pilot tests a question defined in advance

A useful pilot should answer a specific question. For example: can a robot welcome a guest, help them find a service and pass a complex question to staff? Guidance or delivery could be another use case. “Let the robot drive around the whole hotel” defines neither the scope of the test nor a clear outcome.

For a host role, prepare approved hotel information, define the limits of answers and assign responsible staff. Test not just the conversation but its outcome: whether help was received, whether contact with staff was confirmed and what happens if they are unavailable. Human assistance must remain available whenever the guest prefers it.

Preparing the site does not mean that any prototype is ready to operate among guests. Technical checks, risk assessment and a decision on permitted operating conditions must come first. This is a separate part of the project, not something a trial drive can replace.

1. Limit the first route

Choose dispatch, receiving, waiting and return points. Define excluded areas, who can assign tasks and what happens when a passage is blocked.

Survey more than straight stretches. Turns, space around doors, thresholds, carpets, slopes and places to pass people all matter. Measuring body width does not establish how much space the robot needs to manoeuvre with a load.

Glass partitions, mirrors, steps, sunny areas and temporary obstacles such as suitcases, cleaning carts and movable furniture need particular attention. Include them in the test programme rather than treating them as rare exceptions.

2. Address doors and lifts before launch

Navigating a floor does not imply the ability to call a lift or pass through a closed door. Routes between floors depend on building infrastructure and an agreed integration with it. Service-robot manufacturers also describe lift control as a separate technical solution. Pudu Robotics integration example.

Before a pilot, establish who maintains the equipment, which interaction methods are permitted and how failures will be handled. Work on lifts and access systems must be coordinated with the responsible organisations; independent modifications are not part of routine robot setup.

If integration is not yet available, limit the first route to one accessible area. This is more honest than including hidden staff assistance in a demonstration and calling the process fully autonomous.

3. Prepare charging and maintenance procedures

The charging location must be accessible for maintenance and must not obstruct passageways. Power supply, charger and operating conditions must be agreed for the specific system. A nearby socket alone does not make charging ready.

Simple operating rules are also needed: who inspects the robot, cleans its optics according to instructions, checks the load and takes damaged equipment out of service. Include these activities when assessing total staff effort during the pilot.

4. Agree on connectivity and data handling

Before launch, determine which functions require a network, what happens when connectivity is lost and who receives problem notifications. Check the actual route, including weak-coverage areas, not only the space near reception.

If cameras are used, separately establish whether recording occurs, where images are processed, who can access them and how long data is retained. A camera does not require video storage. Make these decisions with those responsible for IT, security and privacy, and determine the requirements for the particular site.

5. Assign responsibilities and pilot stop conditions

Staff must know how to stop the robot, whom to notify of a fault and when operation must not resume without a check. Every task needs a clear means of human intervention, not a hope that problems will resolve themselves.

Agree on success criteria before starting: acceptable task duration, intervention frequency and equipment availability. Separately define conditions for immediate suspension: hazardous behaviour, damage, unexpected departure from the permitted area or a protective-function failure. An incident-free short demonstration does not by itself prove system safety.

What the pilot should leave behind

The outcome should be a report recording tasks completed, where assistance was needed, staff time spent and limitations found. The decision may be to expand the route, improve the system or abandon the use case. Any of these conclusions is more useful than a demonstration without measurements.

SAIREX W1 is under development. Discussing a possible pilot starts with examining the task and site conditions; it does not mean the platform is already cleared to operate among guests.