What a greeting robot needs before the language model

A greeting robot is easy to imagine and easy to get wrong, because the part that makes it actually work is rarely the part anyone buys first.

The requirements document comes before the hardware.

It settles the argument everyone has later: what the robot says, when it says it, what happens when a child stands directly in front of it, and how anyone on shift can tell it is actually working. Greeting a visitor, waving, answering questions about a range of products, and walking someone to a shelf are four different jobs, and a written specification is what separates them before anything is ordered.

Mapping and navigation are only needed if the robot moves.

A unit standing at an entrance and greeting whoever arrives needs neither, and assuming otherwise is a common and avoidable cost. A unit that has to lead a visitor somewhere needs both, and every route it takes has to be step-free from end to end, which is a site survey question rather than a robot one.

Perception and localisation are what let it notice someone is actually there.

Without them, a robot greeting an empty doorway on a fixed timer is worse than no robot at all, because it reads as broken rather than absent.

The language model is the item worth thinking hardest about, and it is not free.

Without one, the robot says exactly what it was scripted to say, reliably, forever. With one, it answers questions nobody anticipated, sometimes well and sometimes not. The account is the customer's own, whether that runs through a commercial provider or a local deployment, and usage is billed directly rather than passed through a supplier's invoice. Deciding who owns what the robot says once it can improvise is worth settling before the model is switched on, not after it has answered a pricing question with a number that changed last week.

A standard configuration takes 12 to 16 weeks to deliver from a firm order, and every unit ships with a 12 month warranty handled inside the EU. Both numbers are worth having in hand before the requirements document is written, because a launch date set against neither tends to move.