Reception Robot Speech: Testing Noisy Lobbies

A reception robot can look highly capable in a quiet showroom demo. The same robot in a lobby at nine in the morning, with a queue forming, a PA announcement overhead, a family talking near the entrance, and a visitor with an unfamiliar accent, may hear almost nothing reliably. Speech interaction degrades quietly. A robot that answers a misheard question without checking intent can send the visitor in the wrong direction and undermine trust.

This article is for the people who have to decide whether a reception robot's voice interface is good enough for a real space. It works through: defining the intended spoken tasks, characterizing the actual noise and speaking conditions, separating hearing from recognition from response, testing unknown questions and misrecognition, providing screen and human alternatives, and recording a representative test set. The guiding principle is that speech performance is an empirical property of a specific robot, in a specific room, and that a quiet demo tells you very little about either.

Define the Intended Spoken Tasks

"Speech recognition" is not one task. What the robot has to understand determines what success means, and the difficulty varies enormously across task types.

Fixed commands: a small set of known phrases, such as "where is the elevator" or "call the front desk." The vocabulary is closed and predictable, which makes recognition far easier.

Wayfinding: a large but bounded set of location questions, using vocabulary that may include names, floors, and departments the system has to know.

Open-ended questions: anything the visitor happens to ask, including questions the system was never designed to answer. This is the hardest task, because the input space is unbounded and the correct response may be "I don't know, let me get a person."

Define which of these the deployment actually requires, and for each, what a "success" looks like. For a fixed command, success is executing the command. For a wayfinding question, success is giving the right directions. For an open question, success may be routing to a human. Writing these down first prevents the trap of measuring a recognition accuracy that has nothing to do with whether the service completed.

Characterize Noise and Speaking Conditions

Speech performance in the real world is dominated by conditions that a demo environment omits.

Background noise: continuous sources like ventilation and equipment, and intermittent ones like announcements and door alarms. The character of the noise matters as much as its level; steady hum and sudden clatter interfere differently.

Multiple talkers: a lobby at peak has several conversations at once, and the robot has to separate the intended speaker from the surrounding voices. This is a much harder problem than single-source noise.

Distance: how far the visitor stands from the robot's microphones. Speech energy falls with distance, and the ratio of speech to reflected and ambient sound changes, which is why far-field performance is a distinct problem from near-field.

Reverberation: hard, reflective surfaces, common in lobbies and atriums, smear speech in time and degrade recognition.

Language and accent: which languages the deployment must handle, and which accents of those languages are common among its visitors.

All of these should be recorded for the actual space, not assumed from a specification. The microphone array and the processing may be capable, but their performance depends on the room. The relevant evidence is published research on far-field recognition: the September 2026 FFASR research preprint, with 15,637 utterances across nine acoustic conditions, including simulated far-field cases and a measured-versus-simulated office-lab pair, reported mean word error rates of 4.4% for near-field speech versus 41.3% in its static low-SNR condition, with a smaller additional penalty for a moving talker at matched SNR. That is a large gap, on simulated conditions, and it illustrates why near-field numbers cannot be projected to a noisy lobby.

Separate Hearing, Recognition, and Correct Response

Speech interaction is a chain, and a single accuracy number conceals where it fails.

Hearing, or pickup, is the microphone array and its front-end processing capturing a clean-enough signal. This stage is about array geometry, beamforming, echo cancellation, and noise suppression. Far-field pickup is an active area of design; product-level approaches range from multiple microphones with learned processing, as in Apple's 2018 account of Siri on HomePod, to specialized microphone arrays, and vendor claims about pickup distance should be treated as claims to be tested rather than facts to be relied on. Research is also moving toward spatial hearing. Work from Peking University, Tsinghua University, and Alibaba, reported in OmniEcho v2, targets spatial audio for embodied agents, using spatial audio and visual observations to reason about sound-source direction and location. That is a research direction, not a shipping feature, but it points at the same conclusion: the quality of the room shapes the quality of the pickup.

Recognition, or transcription, is the speech-to-text step that converts the captured signal into words. This is where accent, vocabulary, and noise interact, and it is where word error rate is measured.

Response, or understanding, is turning the transcribed words into the right action and answer. Accurately transcribing an unintended nearby talker can still trigger the wrong response; likewise, a correct transcript of the intended visitor's words does not prove that the answer is valid. A partial transcript can sometimes still support the intended task.

Measuring only recognition accuracy hides the fact that a service can fail at hearing (the signal was too degraded), at understanding (the words were heard but interpreted wrongly), or at response (the correct answer was not available). Record where failures occur, because each points to a different fix.

Test Unknown Questions and Misrecognition

The most important tests are the ones a demo avoids: the questions the robot cannot answer, and the times it hears wrong.

Design the behavior for the unknown question. When a visitor asks something outside the system's knowledge, the robot should acknowledge that it does not know and offer a path forward, such as displaying information or connecting a human, rather than guessing. A confident wrong answer is worse than an honest "let me get someone who can help," because it sends the visitor in the wrong direction and damages trust.

Design the behavior for misrecognition. When the robot hears a question as a different question, the visitor needs an easy way to correct it. Do not make louder repetition the only correction path. It can help an audibility problem but will not resolve every vocabulary, intent or response failure. A fallback to a screen, to a typed input, or to a human is the recovery path.

Test both deliberately. Prepare a set of questions the system should not be able to answer and confirm it declines gracefully. Prepare utterances the system is likely to mishear and confirm the correction path works. These tests matter more than a clean-conditions accuracy figure, because they are the situations that will actually occur in a busy space.

Provide Screen and Human Alternatives

A voice interface should never be the only way to get service.

Screen alternatives: the same information and routing that the voice system provides should be available on a touchscreen, so that a visitor who cannot be understood, or who prefers not to speak, can still be served. This is especially important when the failure is in hearing, because the visitor has no way to fix the robot's microphone.

Human alternatives: provide a visible, reachable route to staff during the deployment's service hours, and define the out-of-hours fallback. The robot should be able to hand off, and the handoff should be easy, not a last resort the visitor has to hunt for. Keeping a human in the loop is not a failure of the automation; it is what makes the service robust when the speech chain breaks.

The design principle is graceful degradation. If speech fails, the service continues through another channel. A deployment that forces continued voice interaction in an environment where voice does not work has confused the interface with the service.

Record a Representative Test Set

The evidence that the voice interface is fit for the space is a recorded test set, collected under real conditions.

Record the tasks, the conditions, and the outcomes. Tasks: the actual questions visitors ask, including the common ones and the unexpected ones. Conditions: the time of day, the noise level and character, the distance, the language and accent, and the number of simultaneous talkers. Outcomes: for each, whether the task completed, and if not, at which stage it failed, and whether it escalated to a human.

Start with scripted questions from authorized staff or volunteers so the pilot can measure task completion without collecting incidental visitor conversations. If recordings are needed, agree on authorization, notice, access and retention before collection, and remove identifying content before sharing test material.

The result is a table the buyer can act on: task by condition by completion, with the escalation rate. Where the numbers are unacceptable, the response is to adjust the channel mix rather than to claim a higher accuracy. Where the numbers are acceptable, the buyer has evidence rather than a demo. Speech performance measured elsewhere remains unverified for this deployment until the actual site conditions are tested.

Bring Real Lobby Conditions into the Speech Test

Share the intended visitor questions, service languages, typical speaking distance, peak noise conditions and the planned touchscreen or staff fallback. AIsirRobot can help compare reception-robot options and structure a preliminary site-acceptance checklist so the pilot measures completed tasks, not demo transcription scores. Assess the noisy-lobby reception application.