A Visitor Guide Pilot for Showrooms and Exhibitions
A practical, conceptual pilot for helping showroom and exhibition visitors choose an approved route, understand an exhibit, and reach staff, with clear system boundaries, evidence measures and full-session cost control.
How to help visitors choose a useful route and understand an exhibit with Kasamila
A visitor has twelve minutes before a scheduled demonstration. They want to understand one product family, but the showroom is organized around several themes. A floor plan tells them where the displays are. It does not tell them which two displays would make the best use of their time.
That is a useful problem for a digital guide to address. A short conversation could identify the visitor's interest, suggest a route through approved exhibits, explain an unfamiliar concept and show where a specialist can help. A Kasamila avatar could present that explanation while the screen keeps the route and key facts visible.
This article proposes a bounded pilot for a brand showroom or exhibition stand. The visitor and venue are illustrative. No customer deployment, integration certification or performance improvement is claimed.
Make the visit easier to navigate
The initial research should focus on moments when visitors lose direction. They may not know the vocabulary used on exhibit labels, may miss a relevant demonstration, or may receive a generic tour despite having a specific interest. Staff may spend time repeating basic explanations when a visitor actually needs a product specialist.
These are hypotheses to check with the venue, rather than universal industry facts. Observe the questions people ask, identify which exhibits they confuse, and ask staff what a successful short visit looks like. The pilot should address one route through one area, with a small set of approved explanations.
Choose a task with an observable ending: the visitor selects a suitable exhibit and can explain why it is relevant. Do not make longer conversations or more screen attention the primary goal. The guide should help people return to the physical experience.
Turn a visitor goal into a short route
Consider a fictional materials showroom with three zones: an introduction, a comparison display and a staffed demonstration. The idle screen offers “Help me choose a route” and “Find an exhibit,” alongside a normal map. It identifies the guide as AI and offers touch or optional voice input.
The guide asks about an interest and available time without requesting a name or contact details. It recommends two stops from a venue-approved route list. Each stop has a short reason, a recognizable landmark and an estimated duration supplied by the venue. Estimates are guidance, not promises about queues or walking speed.
At a stop, an exhibit code or QR link can open a short explanation in the venue's own web application. That link is a proposed application feature, not a Kasamila tracking capability. The visitor can choose a basic explanation, a deeper technical answer or a question for staff. Keep technical claims tied to the approved exhibit record.
If a demonstration is unavailable, the application must use a current venue status or say it needs confirmation. It should offer an approved alternative route. Directions for restricted areas, emergencies or unverified accessibility requirements should go to venue staff; a generated map is not an authoritative route.
The visit ends with a readable next step: the selected exhibit, the staffed location, or an optional public information page. If contact capture is later added, make it a separate, explicit opt-in flow with its own purpose and data notice. A useful explanation should not require a sales lead.
Figure 1. Conceptual visitor route. Original illustration, not a product screenshot or deployed venue.
Give the content an operational owner
A route is only useful if it matches the physical venue. Build a small content register before connecting an LLM. Each exhibit should have an ID, location, approved description, permitted claims, related exhibits, language versions, review owner and last-checked date. Record a fallback when an exhibit is closed or an answer is unavailable.
Separate stable interpretation from changing operations. A product principle may remain accurate for months; a demonstration schedule or temporary closure can change during the day. Give those changing facts an agreed freshness limit. An expired schedule must not silently become a confident answer.
Have staff walk every suggested route. Check landmarks from the visitor's viewing position, test whether the route fits the proposed time budget, and review any accessible route with the venue's responsible team. The pilot should suggest only routes that have passed that review.
For a first release, a structured menu and approved answers may be enough. Add retrieval and a language model only where flexible questions create real value. The application should reject unsupported claims, show uncertainty and offer staff help when its approved information cannot answer the question.
Connect the avatar to the answer pipeline
Kasamila's public documentation describes audio-driven avatar inference and rendering in the browser. Its documented inputs include audio files, PCM or TTS streams and RTC audio tracks. The backend retains the permanent API key, and the browser receives a short-lived Runtime Token scoped to a template, origin and permitted modes. These are documented platform capabilities, not proof that a particular exhibition kiosk has passed acceptance testing. [1]
In the proposed guide, the venue application owns the route logic, answer selection and on-screen cards. If voice is used, speech recognition handles visitor input; the answer service uses the approved content; and text-to-speech produces the guide's reply. Feed assistant output audio into Kasamila, rather than using visitor microphone audio to animate the guide. The official voice integration notes describe this separation. [2]
Keep the displayed answer and spoken answer aligned. For a route, show the exhibit names and map while the avatar explains the choice. Do not ask the visitor to remember a long spoken itinerary. If a speech service fails, preserve a usable touch-and-text path.
The browser application, voice services, content system and media hosting require their own implementation. The documented geometry integration uses caller-hosted HLS media and a matching media descriptor. Permanent credentials must remain on the server; access to the session-issuing endpoint needs authorization and rate limits. [3]
Figure 2. Conceptual system boundaries. Connections are proposed implementation work, not certified integrations.
Build the pilot in a practical order
- Agree on the visit outcome. Choose the audience, area, approved routes and tasks. Name an exhibit-content owner, a venue operations owner and an integration owner. Decide what staff will do when the guide cannot help.
- Prototype the route without voice. Use exhibit cards, a map and a complete touch path. Check the content with staff and representative visitors before adding another interface layer.
- Add optional speech and the avatar. Keep the same route logic. Issue scoped runtime tokens from the protected backend, provide the matching media, and handle initialization failure without leaving a running session behind.
- Test the actual installation. Verify the selected browser, screen orientation, graphics capability, audio permissions, network, HLS delivery and recovery behavior on the intended device. Rehearse noisy conditions, interruptions, denied microphone access and several people nearby.
- Run a supervised comparison. Start in one area with staff available. Review errors daily, update the content register and use the agreed success criteria before deciding whether to expand.
An available browser SDK does not establish compatibility with every kiosk, signage CMS, operating system or embedded webview. Repository examples are development starting points; local tests do not certify a provider or a complete venue deployment. [4] Ticketing, badge access, CRM, appointments, payments and telephone calling remain outside this pilot. Any later integration needs its own requirements and acceptance test.
Test whether the visible guide adds value
The avatar may give a route explanation a consistent presenter and make a spoken interaction easier to recognize. It may also distract from the exhibits or add waiting time. Both outcomes are plausible. Treat the incremental value as a testable hypothesis.
Use three versions with the same approved content, maps, placement and task scope: a touch-and-text guide; a voice guide with the same screen content; and that voice guide with the Kasamila avatar. The avatar-versus-voice comparison isolates the visual layer more closely. The touch comparison tests whether conversation helps the task at all.
Randomize sessions where practical, or rotate comparable time blocks and report the limitations. Record language, task type, noise and demonstration availability. Avoid comparing a quiet weekday with a crowded event opening and attributing the difference to the avatar.
Measure outcomes separately. Track starts among observed opportunities, correct route selection among started in-scope tasks, and verified answer accuracy among reviewed answers. Check comprehension with a short voluntary question about the exhibit. Record time to a usable route, abandonment, staff-help requests and whether the receiving staff actually acknowledged a request.
Also measure operational effort: content maintenance, staff corrections, browser recovery, speech failures, rendering failures and cost per correctly completed task. Report sample sizes and uncertainty. Set acceptable accuracy, service quality and cost thresholds before the trial; do not invent favorable targets afterward.
Figure 3. Conceptual pilot evidence. Metric definitions only; no measured results or claimed uplift.
Control the full cost of an interaction
Ordinary Kasamila API/SDK sessions are billed from creation using server elapsed time, including listening, speaking, silence and hidden canvases. Stopping audio does not end the session. The documented ending is SDK destroy() or the authorized session-end operation. An unended lease consumes its full duration; early termination returns unused reserved time under the documented lifecycle. [1]
Keep the idle map and attract screen outside an active runtime. Start a session when the visitor chooses the experience, warn before an inactivity timeout and end it after completion, failure or handoff. Use bounded leases and backend reconciliation because a browser close event alone is an incomplete cleanup strategy. Confirm actual session closure in test records.
Budget speech recognition, language-model and TTS usage separately from avatar runtime. Add template work, media hosting, devices, integration, support and any required concurrency capacity. Divide the agreed cost total by correctly completed tasks, and show one-time implementation cost separately from recurring operation. Free portal previews do not make third-party API/SDK operation free. Confirm the applicable plan, quotas and expiry rules before purchase. [1, 3]
Keep the visitor in control
Provide captions, readable maps, visible microphone state and a complete non-voice path. Test reach, focus order, contrast and language clarity on the physical installation. These are acceptance requirements, not a claim of accessibility certification.
Use anonymous aggregate events where they answer the pilot question. Avoid raw audio, full transcripts, identity recognition and cross-visit tracking by default. If external speech or AI services receive visitor audio or text, document that data flow and configure retention accordingly. Browser-side avatar rendering does not make those separate services local.
The first decision is whether the guide helps a visitor choose and understand a relevant exhibit. The second is whether a visible avatar improves that result enough to justify its extra cost and operational work. A focused comparison can answer both before a venue commits to a wider rollout.
Sources
Public documentation checked on 17 October 2026. Proposed routes, workflows, safeguards and pilot design are recommendations, not product claims.
[1] Kasamila Runtime API and Web SDK integration guide
[2] Kasamila realtime voice integration notes
[3] Kasamila developer handbook
[4] Kasamila developer resources and example validation limits