Introduction

Retail signage is usually a one-way medium: the screen shows a promotion, a product demo, or a brand message, and the customer either notices it or walks by. If you want the screen to actually participate in the interaction, you need two things at once: a voice agent that can respond naturally, and a visual face that is synchronized tightly enough with the speech to feel conversational rather than dubbed.

That combination is what realtime avatars are for. In practice, the implementation challenge is not “make a talking head.” It is stream audio and video with low enough latency that turn-taking still feels human, while keeping the system operationally sane in a store: kiosk hardware, flaky networks, privacy constraints, rate limits, and a clean way to update prompts or avatars without shipping a new app.

By the end of this post, you should be able to design a voice-enabled retail signage experience that:

• listens to a customer,

• generates a voice response,

• renders a synchronized avatar face on the display, and

• does so in a way that is practical to deploy in a retail environment.

What “voice-enabled signage” actually means technically

A retail signage avatar is not the same as a prerecorded promo video. It is closer to a realtime media session with an AI agent attached.

The basic pipeline looks like this:

1. The screen captures user speech through a mic, or a nearby kiosk/assistant captures it.

2. An ASR/voice agent stack turns speech into text and decides on a response.

3. The agent produces audio output, usually in streaming chunks rather than a full sentence at once.

4. A video face is driven from the agent’s output so lip movement and facial motion stay aligned with the audio.

5. The client renders that video at low latency, often over WebRTC or a similar realtime transport.

The critical point is that the avatar is not “doing speech synthesis” by itself. The important part is synchronization: the face must track the agent’s audio stream closely enough that the viewer perceives a single speaker. If audio arrives late, video arrives out of order, or the response has to buffer too much, the whole interaction feels broken.

For retail, the interaction design usually ends up in one of two modes:

• Passive signage with interruption: the avatar runs a scripted or semi-scripted loop, but can interrupt the loop when a customer starts talking.

• Conversational kiosk: the avatar only speaks in response to customer input, which is better for product discovery and guided selling.

In both cases, latency is the constraint that matters most. Once your response time creeps above a couple of seconds, the conversational illusion degrades quickly.

Designing for the store floor

A retail environment is noisy, visually busy, and operationally hostile in small ways that matter. The system design should reflect that.

Keep the interaction state simple

Don’t treat the display like a general chatbot terminal. Signage works better when the agent has a narrow job:

• answer product questions,

• surface current promotions,

• help customers compare a few SKUs, or

• route to staff when confidence is low.

That keeps the prompt short, reduces hallucination risk, and makes it easier to control what the face says on screen. In a store, correctness beats creativity.

Separate the media session from business logic

The avatar session should be a thin realtime media layer. Business logic should live elsewhere: inventory lookup, promo rules, store hours, loyalty data, or escalations to a human associate.

That separation matters because you will likely want to update store-specific behavior without touching the media stack. For example, a holiday display may need different prompts, different product knowledge, and different rates for how often it speaks. Those changes should be configuration, not a redeploy.

Plan for timeouts and fallbacks

Retail signage cannot assume every conversation will complete successfully. You need explicit fallback behavior for:

• mic failure,

• network interruption,

• agent timeout,

• user silence, and

• excessive latency.

A good fallback is a non-interactive looping visual with an obvious “tap to talk” or “say hi” cue. When the realtime session comes back, the kiosk can resume from a clean state instead of trying to recover a half-dead conversation.

Transport and latency: why WebRTC-style delivery matters

Realtime avatars are usually delivered over a streaming transport rather than “generate a file, then play it.” That distinction is important because the face and voice must stay aligned while the response is still being produced.

In practice, low-latency streaming buys you three things:

• Faster first frame: the customer sees the face start speaking quickly.

• Better turn-taking: short pauses feel natural instead of broken.

• Less buffering: the client can render incrementally instead of waiting for a complete asset.

That said, low latency does not mean “accept every possible network condition.” You still need to tune for your deployment environment. A mall kiosk on wired Ethernet is very different from a pop-up installation on guest Wi‑Fi. Test with the real network path, real display, and real microphone hardware.

Practical implementation pattern

If you are building the agent yourself, the cleanest architecture is usually:

• one component handling speech and agent logic,

• one media layer for the avatar stream, and

• one thin UI shell in the kiosk or signage app.

That gives you room to swap the agent backend without reworking the display. Here is a simplified shape in Python for provisioning an avatar session from a backend service; exact request fields depend on the API docs, so treat this as a pattern rather than a drop-in snippet:

import os

print(session)

import os

print(session)

import os

print(session)

Your application would then hand the returned session information to the client responsible for rendering the avatar. In a retail kiosk, the UI usually only needs enough data to join the live session and display the face; it should not need direct API credentials.

Where Protoface fits in

This is the part where Protoface is useful: it gives you the avatar layer without forcing you to build the low-level media plumbing yourself. For voice-agent deployments, the most direct integration is the LiveKit Agents plugin, which drops a synchronized talking video face into an existing voice agent. If you are already using LiveKit for realtime audio, that keeps the architecture simple: your agent handles the conversation, and the plugin handles the avatar stream.

A minimal usage pattern looks like this:

# Pseudocode: exact import paths and setup are in the docs/repo

)

# Pseudocode: exact import paths and setup are in the docs/repo

)

# Pseudocode: exact import paths and setup are in the docs/repo

)

If you are not on LiveKit, the REST API and Python SDK let you create and manage avatars and sessions from your own backend. That is useful when your retail app needs to set up sessions dynamically based on store, language, campaign, or user segment. The docs at docs.protoface.com and the integration examples in the GitHub repositories are the right place to check exact request shapes and lifecycle details.

For web-only signage, customer-managed iframe embeds are often the simplest operationally: you can add an interactive avatar to a site or kiosk shell without exposing an API key in the browser. That model also gives you controls that matter in shared environments, like parent-origin allowlisting and per-embed limits on voice, instructions, duration, and IP-based usage.

In other words, you can choose the surface that matches the deployment:

• LiveKit plugin when you already have a voice agent and want a face.

• REST API / Python SDK when your backend provisions sessions dynamically.

• iframe embed when you want a browser-safe, no-backend kiosk or web experience.

Retail-specific gotchas

A few practical issues come up repeatedly:

• Audio feedback: if the display mic can hear the kiosk speakers, you will get self-triggering loops. Use directional mics, echo cancellation, or physical separation.

• Display placement: an avatar that is too small or too high on the wall loses conversational presence. Eye line matters more than people expect.

• Prompt discipline: avoid long, brand-heavy instructions. The avatar should sound like a capable associate, not a marketing script.

• Usage controls: store deployments need guardrails. Limit interaction duration and scope so a kiosk cannot be monopolized indefinitely.

• Observability: log session starts, turn durations, failures, and handoffs. In-store debugging is much easier when you can reconstruct the media/session timeline.

Also remember that “better visuals” are not always better for signage. A simple, stable face with consistent lip sync usually outperforms a flashy avatar with occasional mismatch. The human brain is very tolerant of modest visual realism, but not of broken timing.

Conclusion

A voice-enabled retail signage experience is essentially a realtime conversational system with a face attached. The engineering work is about latency, synchronization, and operational constraints, not just avatar appearance. Keep the agent focused, keep the media path short, and keep the deployment model simple enough that store teams can live with it.

If you want to build this with less infrastructure work, start with the integration surface that matches your stack, then move to the docs and examples for the exact session and avatar fields. The quickest next step is to read the docs, pick a quickstart, and test the full loop on the actual kiosk hardware you plan to ship.

Useful starting points: docs.protoface.com and the quickstarts linked from the GitHub organization.