One support brain: webchat, Zalo OA and Facebook Messenger

Vietnamese customers do not come to your website to ask questions. They message your Zalo OA, they comment-then-DM on Facebook, and only sometimes do they use the chat widget on your store. Building three separate bots for three channels triples your maintenance and guarantees inconsistent answers. The right architecture is one support brain — a single LLM service — behind thin channel adapters, so the same knowledge, the same policies and the same escalation logic serve every channel.

The architecture in one diagram's worth of words

1. Channel adapters — one per platform (webchat, Zalo OA webhook, Messenger webhook). Each adapter does exactly three things: normalize incoming messages into a common format, enforce that platform's policy constraints, and render outgoing replies in that platform's message types. Nothing else lives here.
2. The brain — a single service that holds conversation state, retrieves grounding documents, calls tools (order lookup, shipping rates), generates the reply, and decides when to escalate.
3. Knowledge layer — your product catalogue, shipping-rate table, returns policy and FAQ, indexed for retrieval. Product facts come from the same structured fact tables that power your AI-generated listings, so chat and product pages can never disagree.
4. Tool layer — live lookups: order status from Shopify, tracking status from the carrier (fed by the webhooks described in our ViettelPost automation guide), stock levels.
5. Escalation queue — a human inbox that receives the full transcript, the retrieved documents the bot used, and the reason for escalation.

Grounding: the difference between a bot and a liability

An ungrounded LLM will answer "can I return this after 30 days?" with whatever sounds plausible. Sometimes it invents a generous policy you never offered. A hallucinated refund promise is not a bug ticket — it is money, and possibly a public Facebook post about your shop breaking its word.

Order-status questions follow the same principle with tools instead of documents: the bot never states a delivery date it did not just fetch. "Your order left the Đà Nẵng hub this morning" comes from the carrier webhook data, or it does not come at all.

Xưng hô: the detail that makes or breaks Vietnamese support

Vietnamese has no neutral "you". The bot must choose a pronoun register — em/anh, em/chị, mình/bạn — and choosing wrong reads as either rude or absurd. The workable defaults: open with a polite, slightly deferential shop register (em for the shop, anh/chị for the customer), infer the customer's preference from how they address the bot, and stay consistent for the rest of the conversation. This is a system-prompt and conversation-state concern, not something to hope the model gets right per message. Test it with real Vietnamese speakers; it is the first thing customers notice and the last thing an English-speaking developer thinks about.

Platform policies are architecture requirements

Zalo OA: the 48-hour window and approved templates

Zalo Official Accounts can reply freely within a care window (48 hours from the user's last message). Outside it, you can only send pre-approved template messages (ZNS) — and templates require approval lead time. The adapter must track the window per conversation and, when it closes, either use an approved template or queue the message until the customer writes again. Design your proactive notifications (order confirmations, tracking updates) as ZNS templates from day one.

Messenger: the 24-hour policy

Facebook Messenger's standard messaging window is 24 hours from the user's last message, with tagged exceptions for specific use cases such as post-purchase updates. Same adapter pattern, different clock. The brain never needs to know about either window — it emits an intent ("notify customer of delivery"), and each adapter decides whether that is a free-form message, a template, or a queued item.

Log everything

Every conversation — customer message, retrieved passages, tool calls, generated reply, escalations — is logged to an audit store. This is your dispute evidence, your training data for improving retrieval, and in the worst case your proof of exactly what the bot promised and why.

Measuring whether it actually works

The headline metric is deflection rate: the share of conversations resolved without a human. But raw deflection lies — a bot that stonewalls customers "deflects" beautifully. Pair it with honest companions:

1. Resolution-confirmed deflection — the customer's last message indicates the answer worked, or they simply complete the purchase.
2. Escalation quality — when a human takes over, do they have everything they need, or do they re-ask the customer?
3. Contradiction rate — sampled weekly: answers that conflict with the policy document. Target: zero, because grounding makes it structural.

A well-grounded bot on these three channels typically handles the repetitive majority — "phí ship về Cần Thơ?", "đơn em tới đâu rồi?", size charts, return steps — and hands humans only the conversations that genuinely need judgement. That is the goal: not replacing your support person, but making sure their attention goes where it matters, exactly as the rest of the end-to-end automation stack does for shipping and invoicing.