# A browser avatar for clear hotel service request handoffs

A guest asks a browser avatar for two extra towels. The avatar smiles and says, ‘Of course.’ The guest closes the page believing someone is bringing them. Reception has received nothing. This hypothetical failure is the reason to design the handoff before the conversation: a reassuring presentation can imply more progress than the underlying service has made.

For a hotel considering Kasamila, the useful question is whether an optional avatar helps an adult guest describe, review, and track one ordinary request accurately. This article proposes a limited pilot, not a deployed hotel system or a claim of improved service. Its central rule is that hotel evidence determines status; a fluent reply never does.

## Choose a narrow service boundary

Begin at one property with extra towels as the only request category. A human pilot operator monitors a hotel-owned queue and works with reception. The exercise covers drafting and handoff, not room booking, payments, room access, or property management system integration. It makes no delivery-time or deployment promise. Reception operations remain responsible for whether staff can accept the request and how actual service is performed.

Treat the pain points as hypotheses to test: guests may confuse sending with acceptance, correct a request by sending it again, or assume an animated acknowledgment means delivery is underway. Interviews with staff and a small observed exercise can establish whether those problems matter at this property. Do not present them as measured industry trends.

Start with a staff-assisted, anonymized prototype using fictional guest references. A shared lobby screen must not display or announce names, room numbers, or private request histories. Any later authenticated, private guest context needs separate hotel-owned privacy, identity, and security validation. No credentials need to be created for this concept. Emergencies, safety concerns, and medical issues go directly to hotel staff, outside the automated request flow.

## Make each status say exactly what happened

The draft screen might read, ‘Two extra towels. Please review before sending.’ Quantity and request wording remain editable. Until the guest selects the explicit send control, the interface says ‘Draft only. Not sent.’ Speech recognition, if offered, produces text for review rather than silently authorizing a request. The approved summary is the same in text and optional speech.

After sending, distinguish five evidence states. Drafted means there is no submission. Submitted to backend means the application backend has durably recorded the request and acknowledged that record, not that reception has it. A generic successful HTTP response is insufficient evidence. Staff queue acknowledged means the hotel queue has recorded the request, not that a person has read it. Staff accepted means an authorized staff member has accepted responsibility, without implying a delivery estimate. Fulfilled means the hotel has recorded completion under its agreed procedure.

Show the latest confirmed state beside the request reference and its update time. If completion is disputed, offer a staff contact route and preserve the record for review; do not argue with the guest or automatically create another towel request. A friendly animation, acknowledgment sound, or generated sentence cannot advance the state. Only the relevant backend, queue, or authorized staff evidence can do that.

![Original concept diagram showing five distinct hotel request states: drafted, submitted to backend, staff queue acknowledged, staff accepted, and hotel recorded fulfilled. Each step requires evidence from its owner. An uncertain acknowledgment triggers reconciliation of the same request identifier, not a second submission. Cancellation remains pending until acknowledged. Not a screenshot or deployment.](/portal/media/bd9e2552-7165-4811-8900-5978ea7dcb15)

Figure 1  Advance status only when the responsible owner provides evidence

Original concept / Not a screenshot or deployment

Use language appropriate to the evidence: ‘Reception queue has received your request. Staff acceptance is not yet confirmed.’ Avoid ‘Your towels are on the way’ unless the hotel deliberately supports that additional operational state. If the interface has no reliable estimate, it should say that rather than invent a countdown. A status screen can remain useful without keeping a presenter talking.

## Handle uncertainty without multiplying requests

Assign one durable request identifier at the guest-confirmed send boundary and use it as the idempotency key for technical retries. The server must recognize a repeated attempt as the same operation. A disabled button alone is insufficient: page refreshes, delayed responses, and reconnects can all repeat network activity. Keep any guest-visible reference separate from credentials or access tokens.

If an acknowledgment does not arrive, show ‘Submission status unknown. Checking the existing request.’ Reconcile the same identifier with the backend and queue before offering another send. Do not label a timeout as failure or treat silence as success. A late acknowledgment should update the existing record, with an audit trail, rather than create a second entry. Where reconciliation cannot resolve the uncertainty, ask the pilot operator to investigate.

Cancellation needs the same precision. ‘Cancellation requested’ means a message has been sent for review; it does not mean ‘Cancelled.’ Staff may already be handling the request. Only show cancellation as confirmed after the hotel system or authorized operator acknowledges it under the agreed procedure. Preserve unresolved cancellation status and offer staff assistance instead of promising to stop service.

Before the first exercise, define the queue operator’s routine. The operator checks the request reference, approved summary, latest event, and unresolved exceptions. Staff acceptance is an explicit action by an authorized person, not a side effect of opening a dashboard. Define who may record completion and what they must check first. If a shift changes, the incoming operator needs the outstanding queue and its uncertain cases, not a reassuring transcript alone.

## Keep people and systems in their proper roles

The guest owns review and consent to send. The hotel application owns validation, request identifiers, reconciliation, and the evidence-based display. The queue and authorized staff own acceptance and completion. Any language model helps interpret wording within the permitted category; it cannot invent inventory, change service status, or authorize submission. Speech services transform input or output, subject to separate data review.

Kasamila presents browser avatars. [1] Its guide places permanent keys on the backend and short-lived tokens in the browser Runtime SDK, which renders audio-driven avatars with WebGL. MCP server tooling supports orchestration rather than replacing that renderer. LLM, STT, and TTS services are separate responsibilities and charges. [2] Keep the hotel request record authoritative regardless of which presentation or speech components are available.

![Original concept responsibility map. The guest reviews and confirms. The hotel application validates and reconciles the request. The hotel queue and authorized staff own acceptance and completion. Kasamila provides avatar presentation; optional language and speech services cannot change hotel status. Separate columns are not credential or data-flow arrows. Not a screenshot or deployment.](/portal/media/20ff4e40-19f2-4728-9389-97a10a36ff01)

Figure 2  Keep service responsibility separate from optional presentation

Original concept / Not a screenshot or deployment

## Make quiet text the dependable default

Open with a readable text form and status area. Let the guest choose audio or the avatar; use a neutral service voice without simulated staff identity or claims that someone is already acting. Stopping speech or hiding the presenter should leave the reviewed summary and current status accessible. Do not require a microphone to ask for towels.

Announce status changes programmatically without moving keyboard focus, following the design rationale in W3C’s status-message guidance. [4] If quantity is missing or invalid, describe the problem in text and retain the rest of the draft rather than merely redisplaying the form. [5] Make sound user-initiated and provide a visible way to stop it, informed by W3C’s audio-control guidance. [6] These are design references, not a claim that the prototype conforms to WCAG.

Review whether the same status terms are understood across the languages included in the test. Translation should preserve distinctions such as queue receipt versus staff acceptance. Keep sensitive operational details out of speech, notifications, analytics, and shared-screen recovery views. Agree a minimal retention period with the hotel before collecting test records, and use anonymized observations wherever possible.

## Compare the avatar with simpler alternatives

Run three matched conditions: text only; identical voice plus text; and avatar plus that same voice and text. Hold the request scenario, approved wording, backend behavior, and waiting times constant. Otherwise, a better script or faster queue could be mistaken for an avatar benefit. Participants should be free to switch to text or stop.

Ask guests what has happened, what remains unconfirmed, and what they would do next. Record review corrections, duplicate avoidance, escalation to staff, staff handling time, anonymized complaints, and cost per correctly understood handoff. Distinguish technical failures from misunderstandings. A longer conversation is not a success measure; it may mean the guest cannot tell whether anything has been sent.

Agree the sample plan and go or no-go criteria before looking at results, including how missing responses and accessibility barriers will be reported. A small pilot can expose confusing states without proving broad commercial gains. Keep the avatar only if it provides a credible benefit over the identical voice-and-text condition and remains manageable for staff.

![Original concept pilot comparison with three conditions: text only, identical voice plus text, and avatar plus the same voice and text. Match wording, backend behavior, and waiting times. Measure state understanding, corrections, duplicate avoidance, escalation, staff handling, complaints, and cost. Keep a text waiting screen and end the avatar session. Not a screenshot or deployment.](/portal/media/9449934f-f371-4ec3-b3a6-f8726a2008a8)

Figure 3  Compare matched experiences and protect the waiting period

Original concept / Not a screenshot or deployment

## End the avatar while staff do the work

Ordinary Runtime billing runs from session creation until a confirmed end or lease expiry. Call destroy() or the authorized end endpoint and verify termination server-side; do not rely on UI hiding or expiry. Listening, silent, muted, or hidden states are still active; audio off is insufficient. [2] The proposed waiting screen should therefore remain lightweight text, without a live avatar session while staff handle the request.

For planning only, 80 optional avatar interactions averaging 90 billed seconds total 120 session-minutes. An unintended extra minute each adds another 80 minutes. These are illustrative volumes, not observed hotel usage or quoted prices. Budget separately for staff time, support, content maintenance, and the other services used. Set an agreed spending cap and session limits before any paid test; this article does not authorize one.

A session budget should have an owner and an observable stop condition. Record the start and confirmed end for each test interaction, then compare those records with the metered account view. Investigate unmatched records before expanding the trial. If the presenter cannot start, retain the text pathway; if ending cannot be confirmed, flag it to the technical owner without claiming the session is closed.

## Rehearse the failures before a guest pilot

Test queue failure, a late acknowledgment, a retry, page closure, and a provider outage. Confirm that none creates duplicate requests or invented status. Test cancellation before and after staff acceptance. Reopening a page should recover the permitted record safely, not expose the previous guest’s details. A lost connection must leave an honest uncertainty message and a clear route to a person.

Check the actual browser, graphics capability, network, and audio environment, including foreground and background behavior. Verify termination after every exit and failure path. Repository checks do not constitute credentialed production provider end-to-end validation. [3] The hotel application and chosen providers still need a complete rehearsal with the operator who will handle exceptions.

Rehearse with fictional destinations so no real delivery depends on the prototype. Actual room delivery would require a separately validated, hotel-owned mapping between an authenticated guest and the permitted service destination. Neither a typed room number nor a conversational claim establishes that entitlement. Keep that identity mapping outside the avatar’s responsibilities.

Before paid implementation, identify the real project owner and payer, intended devices, approved budget, procurement route, and reception capacity to own the queue. Agree who can stop the pilot and review its findings. Those are qualification questions, not a proposed contract or a delivery commitment. Expansion beyond one property and one request category should require a fresh decision.

A successful handoff leaves the guest with an accurate understanding and staff with one clear, actionable request. The avatar earns its place only if it improves that outcome without obscuring uncertainty, exposing private information, or keeping unnecessary sessions alive. The towels still depend on the hotel.

## SOURCES

Checked 28 October 2026

[1] Kasamila official portal

[https://www.kasamila.com/portal?lang=en](https://www.kasamila.com/portal?lang=en)

[2] Kasamila Runtime integration guide

[https://github.com/kasamila/kasamila-dev/blob/main/docs/api_v1_runtime_integration_guide.md](https://github.com/kasamila/kasamila-dev/blob/main/docs/api_v1_runtime_integration_guide.md)

[3] Kasamila developer resources

[https://github.com/kasamila/kasamila-dev](https://github.com/kasamila/kasamila-dev)

[4] W3C Understanding Status Messages

[https://www.w3.org/WAI/WCAG22/Understanding/status-messages.html](https://www.w3.org/WAI/WCAG22/Understanding/status-messages.html)

[5] W3C Understanding Error Identification

[https://www.w3.org/WAI/WCAG22/Understanding/error-identification.html](https://www.w3.org/WAI/WCAG22/Understanding/error-identification.html)

[6] W3C Understanding Audio Control

[https://www.w3.org/WAI/WCAG22/Understanding/audio-control.html](https://www.w3.org/WAI/WCAG22/Understanding/audio-control.html)