It has its own address.

A customer opens the storefront's reception page to ask about a 30-cup team order: delivery to a specific district, Friday 3pm, and whether a VAT invoice is possible. The "Desk · Customer Service" avatar replies directly — yes to delivery with free shipping over 30 cups, yes to the VAT invoice — each answer backed by a cited source. The exact delivery time needs the manager's confirmation, so it's already been handed off, tagged "waiting for the owner to take over."

It has its own address plate

The same "Desk · Customer Service" avatar has three doors: a person reaches it directly on the web (karma…/a/qingshan); a group chat reaches it with an @-mention; and another agent can call it over an MCP endpoint — mcp://…/qingshan-desk, billed per call. Pull the platform out from under it and it's still there — that's what makes it a real avatar, not a chatbot widget.

A phone call comes in — it answers that too

A caller asks when the new storefront opens and whether there's an opening promotion. The avatar answers: October 18th, second drink half-price for the first three days — citing the store announcement as its source. The caller wants to reserve a table; the avatar logs a to-do — "10am Oct 18, table for 2 — pending manager confirmation" — and promises a text reply within 10 minutes. Web, group chat, phone call: one avatar, the same rules every time.

Real product UI: the Reception Desk

In the real product, this capability lives in the "Reception Desk" — a unified conversation entry point for visitors and customers, backed by the company directory and contact cards, so every conversation knows exactly who it's talking to.

The phone-call scenario above uses demo data — the phone channel isn't live yet, and the interface honestly labels it "demo data · phone channel not yet live." It's included anyway because it shows a capability that naturally extends from the same architecture: once a channel is connected, the avatar's identity, rules, and memory don't need to be rebuilt — they're reused as-is.

"Can answer" and "should answer" are two different questions

The most common failure mode for a customer-service avatar isn't answering wrong — it's making a commitment on the business's behalf where it shouldn't. Delivery fees, invoice types, business hours: this is information written into policy and public announcements, so the avatar can cite it directly and answer. Whether a specific time slot can be scheduled, whether a one-off discount is allowed, whether a refund is approved — these need real-time judgment or fall outside fixed policy, and the correct move is to hand off, not produce a plausible-sounding answer of its own. What the Desk avatar does throughout the examples above is exactly this: separate what has a documented basis from what needs the owner to take over.

Four steps to bring in a customer-service avatar

1. Write down exactly what it's allowed to answer directly. Delivery zones, minimum order thresholds, invoice types, business hours, standard packages — turn these settled policies into a knowledge source the avatar cites, rather than letting it infer them from conversation history. 2. Define clear hand-off triggers. Discount approvals, escalated complaints, requests outside existing policy — set explicit rules for when to transfer, instead of letting the avatar decide for itself whether it's allowed to answer. 3. Launch one channel, let it stabilize, then add the next. Web reception, group chat, phone — bring them in one at a time, and re-check hand-off coverage every time a new channel goes live. 4. Review hand-off tickets on a regular basis. These tickets reveal real demand that falls outside the avatar's current knowledge boundary — and are the evidence for whether to widen what it's allowed to answer directly.

How to tell whether it's actually working

Response speed is only the surface-level metric. What's worth watching more closely: first-contact resolution rate (how many questions get correctly answered without a human hand-off); among hand-off tickets, how many were things the avatar should have been able to answer but misjudged (fewer of these means the knowledge boundary is drawn well); cross-channel consistency (does the same question asked on the web and in a group chat get the same answer — inconsistency means different channels aren't really backed by the same avatar); and the customer's actual experience of hand-off wait time, not just what the system logs as response latency.

Common mistakes

The most common mistake is treating response speed as the only goal, which pushes the avatar toward giving a confident-sounding answer on uncertain questions instead of honestly saying "needs confirmation" — a wrong-but-confident answer does more damage than a slower, accurate one, because the customer will act on what it said. A second mistake is stopping after one channel goes live, missing the point that the value is in the same avatar being consistent across channels. A third is letting hand-off tickets pile up unreviewed, missing the chance to keep narrowing the knowledge-boundary gap.

Frequently asked questions

How is it billed when another agent calls it? Calls through the MCP endpoint are billed per call, with both the caller and the callee able to see itemized records in their own ledgers — not an opaque deduction. How long is customer chat history kept, and who can see it? Conversation records belong to the business that connected the avatar; retention policy and access control are set by that business, and records are never used as training data for other customers. What happens if the avatar made a wrong commitment before handing off? Every conversation has a full record, traceable to the exact reply that went wrong, so the business can follow up and correct it. This is also the reason contentious questions should be handed off before the avatar commits to a definitive answer, rather than fixed after the fact.

How one storefront actually adopted it

Qingshan Coffee first rolled out the Desk avatar at only one of its three locations. In that first week, the manager did exactly one thing each evening: spend 10 minutes reviewing every hand-off ticket from that day, flagging the ones where the avatar should have been able to answer but got it wrong. Week one had 6 of these, all related to "this specific store's business hours" — the avatar's knowledge source only had headquarters' unified policy configured, not store-level adjustments. Once that information was added to the knowledge source, the same category of error dropped to 1 the following week. Only after confirming this boundary-drawing approach actually worked did the other two locations come online, one at a time rather than all three together. Over the following month, the manager noticed the group-chat channel had a consistently higher error rate than the web channel — tracing it back, group-chat questions often dropped the subject ("open tomorrow?" without saying which store), and this specific kind of ambiguity got added as its own hand-off trigger, rather than letting the avatar guess a default answer.

Before extending a customer-service avatar to a voice channel like phone, run it on web and group-chat channels long enough to confirm the hand-off rules cover the vast majority of edge cases, then expand gradually to lower-tolerance channels like voice.