Welcoming & Advertisement

A robot in a public space is a different proposition from a robot in a warehouse, and the differences are not technical ones.

Decide who owns what it says.

A model answering freely about your promotions will eventually state a price that has changed or a stock level it cannot know. The document backend exists for exactly this: the robot answers from sources you upload and control, and keeping those current is a job somebody has to hold. Agree what it says when it does not know, and prefer a robot that hands over to a person too readily over one that improvises.

Decide what it does with people.

If it carries a camera, someone will ask what is recorded, for how long, and on what basis. A local model on your own hardware answers much of that by keeping the footage in your building. It does not answer all of it, and a robot interacting with the public is a data-protection question worth putting to your own counsel before the launch date rather than after it.

Decide what happens when it fails.

It will be blocked, crowded, asked something absurd, and photographed constantly. The failure behaviour is the product: a machine that stops politely and says so reads as competent, and one that keeps trying reads as broken.

Then agree what success is.

Conversations held, questions answered without a handover, customers actually guided to a shelf, over a stated period. An event robot is measured on attention and a shop robot is measured on whether it saved anyone time. Those two lead to different builds, and deciding which one you are buying is the whole job of the requirements document.