A browser avatar that explains return options

A proposed ecommerce support pilot with merchant controlled decisions

A shopper has two items from the same order and one simple question: “Can I send these back?” A useful answer may be different for each item. One might be eligible to request a return. Another may need a staff review because its condition is unclear. An animated face does not resolve those differences. A well-designed support page does, and an optional spoken explanation may make that page easier to understand.

This article proposes a narrow Kasamila pilot: explain verified return information in an authenticated merchant website, while keeping return approval, refund decisions and payment actions in the merchant's existing workflow. It is a design proposal, not a customer deployment or a tested Shopify integration. The first question is whether an avatar helps customers understand their next step better than the same page with text or voice alone.

Start with the order rather than a general answer

Returns are a poor place to let a language model improvise. A useful explanation depends on the item, the relevant dates, the applicable policy, and any exception that requires a person. A statement about an entire basket can be wrong even when it sounds reasonable for one item.

There is another subtle source of error: the policy shown on a website today may not be the policy that applies to an older purchase. Shopify's documentation says changes to return rules apply to future orders rather than existing orders. Its self-serve flow also distinguishes the customer's request from the merchant's review and approval or decline. These distinctions are a practical reason to preserve the applicable rule context and the actual workflow state. They are not evidence that Kasamila already reads Shopify order data. [1, 2]

For a first pilot, select one merchant, one language and a limited set of ordinary return questions. Exclude disputed decisions, suspected fraud, chargebacks, product safety incidents and requests requiring legal interpretation. Staff should handle those through their established processes. The assistant must not describe the store's policy as the whole of a customer's legal rights.

Give each item a readable answer before adding a face

Design an item-level status card that works without audio. It should show the selected item, what the merchant system can currently establish, the reason, and one clear next action. “You can submit a return request” is different from “Your return is approved.” “Refund initiated” is different from “Money received.” Use the exact status the authoritative workflow supplies, without upgrading it to a more reassuring phrase.

A proposed assessment record might contain an internal item reference, the policy reference applicable to that order, relevant verified dates, a machine-readable status, a customer-safe reason, an allowed next action and a freshness limit. The merchant's engineering team must define this record against its actual data model. This is an application design, not a Kasamila API object or a claim that a commerce platform exposes every field in this shape.

Keep uncertainty visible. If the item condition is unknown, say what needs review. If the policy reference is missing, do not silently apply today's rule. If an order service is unavailable, display the last confirmed information only when the merchant's policy permits that, clearly marked with its limitations; otherwise withhold the assessment and offer a support route. Never invent a return deadline to fill an empty field.

Figure 1. Conceptual design, not a product screenshot or deployed system.

Follow one customer through the page

Consider an illustrative shopper, Maya. This is a fictional journey, not a customer result. Maya opens the merchant's authenticated order page and selects one item. The existing account system determines which order she is allowed to see. A typed order number in the conversation is not proof of identity, and the voice layer does not become an authentication method.

The page retrieves the verified assessment for that item and displays a short card. Maya can read it immediately. If she chooses “Explain this,” the application can offer spoken narration with an optional Kasamila avatar. If she only wants the card read aloud, there is no reason to require microphone permission. Ask for microphone access separately only when she chooses a conversational mode, and keep typing available.

Suppose the verified state says a request can be submitted. The narration explains that next step and the review that follows; it does not promise acceptance or a refund date. Maya then selects the second item. The application cancels the earlier narration, clears any queued explanation, and obtains the second item's assessment. The avatar must not keep talking about the first item over the second item's card.

The second item needs manual review. The page gives a reason the merchant has approved for customer display, shows the existing support option, and lets Maya choose whether to continue there. If the pilot transfers a short summary, show its contents first and limit it to the selected item, the question and the verified status. Do not send a whole transcript, delivery address or unrelated purchase history merely because it is available.

In this first pilot, the avatar service does not create a return, issue a label, approve an exchange or refund a payment. A clearly labelled link may take the shopper into the merchant's existing return-request interface. That workflow retains its own review, confirmation and permissions. Keep the distinction visible even when the two experiences share a page.

Figure 2. Conceptual design, not a product screenshot or deployed system.

Assign authority to the right system

The merchant owns policy wording, exceptions, support escalation and the decision about which information may be displayed. Its account and order services own access control and transaction state. An application-specific assessment layer turns those authorized records into an explainable result. If the merchant cannot supply a trustworthy assessment, improving the data process comes before improving the avatar.

The language and speech components can turn an approved result into a concise explanation. For high-consequence details such as dates, money and eligibility status, prefer fixed wording or constrained templates populated from verified fields. A model may help restate an explanation, but its answer must not replace the policy decision. Do not let customer text or retrieved content grant permission to access another order or invoke a refund action.

Kasamila's documented browser Runtime is the visual and audio-driven avatar layer. Its public integration guide describes keeping permanent credentials on the backend and providing scoped browser access. The public repository describes MCP for server-side session orchestration; browser Runtime handles the visible rendering path. Neither an example nor a local mocked test proves that this returns workflow has been integrated end to end with a merchant. [3, 4]

The application also owns synchronization. Associate every explanation with the selected item and assessment version. When either changes, invalidate the old narration before speaking again. Test interruptions, reconnection and duplicate messages. A visible “End” control should end the avatar runtime session, not merely silence its audio.

Build the pilot in a safe order

First, map the existing return journey with a support lead. List the few questions that can be answered from verified data and the cases that must go to staff. Record who approves wording, which policy applies to each test order and what constitutes a stale result. Use synthetic orders and non-sensitive examples during development.

Second, build the text-only card and test it independently. Confirm that users cannot cross account boundaries, that mixed baskets retain item-level differences, and that changing the selected item cannot reuse the wrong explanation. Test missing dates, missing policy history, already-open requests, declined requests and unavailable services. The expected answer for each case must be specified before the test runs.

Third, add voice and then the avatar behind explicit user choice. Validate the actual audio format, buffering, browser behavior and lifecycle with the selected speech provider. Run tests on the browsers and devices the merchant intends to support. Do not infer mobile WebView, native app, kiosk or payment compatibility from a desktop browser example. No production credentials need to appear in browser code.

Fourth, retain the original text path and human support route throughout the pilot. Keep controls keyboard-operable, provide visible text for the explanation, and announce meaningful asynchronous status changes appropriately. W3C guidance on keyboard access, audio control and status messages provides useful design criteria; it is not a certification that this proposed interface is accessible. Test with relevant users and assistive technology. [5]

Finally, appoint a named operator to stop the experiment if the page exposes another person's information, states an unsupported approval, speaks about the wrong item or continues billing after the intended end. These are release gates, not acceptable trade-offs for a more engaging presentation.

Measure whether the avatar earns its place

A longer conversation is not necessarily a better return experience. A shopper might simply be confused. Compare three versions with the same verified content and next-action buttons: text, text with optional voice, and the same voice with an optional avatar. Keep wording, policy logic, support availability and task difficulty as consistent as possible. Randomize assignment where practical and record the actual mode used, because some people will decline audio or the avatar.

The primary measure should be next-step comprehension: can the shopper accurately distinguish requesting a return from receiving approval, and identify what to do next? Also measure unsupported-status errors, successful navigation to the correct existing workflow, time to the correct next step, support escalation quality, accessibility failures and cost per correctly completed explanation. A completion event alone does not establish understanding.

Include negative cases. Can a shopper understand “we need a review” without interpreting it as a rejection? Does the avatar's confident appearance make an uncertain answer seem final? Can a keyboard-only user finish without voice? Assess these alongside preference ratings. Define the merchant's minimum useful improvement and maximum acceptable cost before launch; report sample sizes and uncertainty rather than claiming a lift from a handful of sessions.

If voice alone provides the same benefit at lower cost and with fewer failures, keep voice alone. If the text card works best, keep the text card. The avatar should remain only where evidence supports a worthwhile contribution for the audience and task.

Figure 3. Conceptual design, not a product screenshot or deployed system.

Control runtime rather than just audio

Kasamila's published runtime documentation states that elapsed session runtime is billed while running, listening or silent. Stopping audio is not the same as terminating a runtime session. The integration must explicitly destroy or otherwise end the authorized session and verify its lifecycle state. A hidden tab, muted speaker or finished sentence must not be treated as evidence that billing ended. [3, 4]

Start the avatar session only after the customer selects it. Propose a bounded explanation session with a visible End control, an inactivity policy and backend termination safeguards appropriate to the integration. Handle navigation away and reconnects explicitly, then compare the application event log with provider usage records. Do not depend on a browser unload event alone as proof of successful termination.

Budget using measured runtime, the current applicable Kasamila rates and any applicable template or concurrency charges. Add LLM, STT and TTS costs separately where those services are used, plus hosting and support work. For example, the planning formula is the sum of actual billable avatar runtime multiplied by the applicable rate, other applicable Kasamila charges, external speech/model usage and operating costs. This is a budgeting structure, not a quotation. No numerical price or trial allowance is assumed here; verify current portal conditions before a funded pilot. [6]

Explain clearly and leave decisions where they belong

A useful returns assistant makes the next step understandable without making the decision appear more certain than it is. Kasamila can be evaluated as the optional browser presentation layer for that explanation. The merchant still needs trustworthy policy history, authorized order access, clear item-level states and a working human route.

The most valuable pilot result may be a simpler interface rather than a more animated one. Start with a correct answer, let the customer choose how to receive it, and keep only the presentation features that improve understanding without increasing risk or wasting runtime.

Sources

[1] Shopify Help Center, Setting up return and cancellation rules. Supports order-applicable rules and the effect of rule changes on future orders. https://help.shopify.com/en/manual/fulfillment/managing-orders/returns/return-rules

[2] Shopify Help Center, Setting up self-serve returns and cancellations. Supports separating a customer return request from merchant review. https://help.shopify.com/en/manual/fulfillment/managing-orders/returns/self-serve-returns/setup

[3] Kasamila Runtime integration guide. Browser rendering, backend credential boundary and runtime lifecycle. https://github.com/kasamila/kasamila-dev/blob/main/docs/api_v1_runtime_integration_guide.en.md

[4] Kasamila Runtime release contract and public repository. Runtime billing and lifecycle; public integration material is not proof of this proposed merchant workflow. https://github.com/kasamila/kasamila-dev/blob/main/docs/sdk_2_runtime_release_contract.en.md ; https://github.com/kasamila/kasamila-dev

[5] W3C WAI, Understanding Keyboard, Audio Control and Status Messages. https://www.w3.org/WAI/WCAG22/Understanding/keyboard.html ; https://www.w3.org/WAI/WCAG22/Understanding/audio-control.html ; https://www.w3.org/WAI/WCAG22/Understanding/status-messages.html

[6] Kasamila portal, current commercial conditions. https://www.kasamila.com/portal?lang=en