Zalo OA AI Chatbot for Business: Architecture and Checklist

Separate built-in Zalo Chatbot, Dynamic API and custom AI

The built-in Zalo Chatbot for an Official Account uses flows, rules, keywords, buttons and information-collection components. It is suitable for greetings, menus, stable FAQs, basic branching and out-of-hours responses. Not every automated flow should be described as a generative AI chatbot.

Dynamic API is a Zalo Chatbot component that retrieves real-time data from a business system, such as order status, loyalty points or account information. It works when an answer has a clear structure and the source system offers a reliable API. Dynamic API does not turn the whole flow into an assistant that understands every question.

A custom AI chatbot adds language understanding, knowledge retrieval, tool orchestration and output controls. Connecting it through Zalo OA OpenAPI and webhooks introduces additional operating responsibilities: authentication, user mapping, conversation state, models, data, CRM, logs, retry and human handoff. Add this layer only when its value clearly exceeds the added complexity.

• ✓Flows and keywords: stable questions, limited exceptions and approved responses.
• ✓Dynamic API: structured lookup with a defined schema and access model.
• ✓Custom AI: varied questions, substantial knowledge or controlled orchestration across systems.

A good chatbot does not try to keep every conversation with AI. It knows when to answer, when to clarify and when to route to the right person.

Verify Zalo OA prerequisites before designing AI

Current Zalo Chatbot documentation requires a verified OA using a supported service plan. The OA pricing page also differentiates message allowances, Chatbot access and OpenAPI request limits by plan. These conditions can change, so the project team must verify the live account and current documentation before committing scope or price.

When internal-system integration is required, identify the necessary OpenAPI permission groups, application authorisation process, available webhooks and limits for the specific OA. Zalo lists permission groups for UID messaging, user and OA management, content and calls; a project should not assume that every account can use every API.

Test on a real device running Zalo. Content, buttons, forms and media can differ from a desktop preview. Maintain test accounts and data, a revocation procedure and a named owner for platform-plan or policy changes.

• ✓Verified OA, appropriate plan and a business-controlled account owner.
• ✓Confirmed OpenAPI permissions, webhooks, limits and test environment.
• ✓Application accounts, tokens, secrets and administration that do not depend on one individual or supplier.
• ✓Content and journeys validated on mobile devices before customer release.

Choose a measurable use case with a safe exit

The first use case should happen frequently, have verifiable answers and carry controllable consequences when wrong. Product FAQs, opening hours, service conditions, lead intake, appointments and order-status lookup are clearer starting points than an assistant expected to advise on every topic.

For leads, the bot can collect the minimum fields one at a time, confirm them and create a CRM record. For support, it can classify the issue, collect an order reference and offer approved guidance before handoff. For lookup, it should call an API only after establishing the right user and access level.

Do not let AI commit prices, change orders, issue refunds, expose account information or provide high-consequence advice without proportionate authentication and approval. During a pilot, AI should answer or propose within a narrow boundary; important actions remain with a person or a deterministic workflow.

• ✓FAQs with an accountable source and effective date.
• ✓Lead capture with consent, deduplication and an assigned follow-up owner.
• ✓Order or appointment lookup after appropriate verification.
• ✓Support triage and routing instead of attempting to resolve every case.

Architecture from Zalo OA to AI, CRM and business systems

An observable architecture commonly includes Zalo OA receiving a message; a webhook or integration layer normalising the event; a conversation orchestrator deciding between a flow, knowledge retrieval, a tool call or handoff; adapters to CRM, orders and appointments; and finally logs, metrics and a failure queue. Clear layer responsibilities prevent incidents from becoming an opaque chain.

Inbound events may be repeated or arrive out of order, so handlers need idempotency, timestamps and consistent conversation state. When a supporting API is slow or fails, the bot must state the limitation rather than invent data, with a retry or handoff path. Platform limits belong in the design rather than becoming a production surprise.

A CRM should not receive every raw message without a business need. Map the channel identifier, consent, intent, campaign source, conversation summary, owner and handling status. Collect sensitive data only when the use case requires it, with appropriate retention, access and logging.

• ✓Webhook gateway: authentication, normalisation, duplicate protection and retry queue.
• ✓Conversation orchestrator: state, policy, tool permissions and handoff decisions.
• ✓Knowledge and tools: approved sources, schema-bound APIs, timeouts and output validation.
• ✓Operations: traceable logs, metrics, alerts, exception views and runbooks.

Knowledge data and guardrails for AI responses

Begin with content that has an accountable owner: FAQs, catalogues, return policies, service guidance and support procedures. Each source needs a version, effective date and access rule. If two documents conflict, the model cannot determine which is authoritative; the editorial process must resolve that first.

With RAG, answers should be grounded in relevant source passages and retain an internal reference that staff can inspect. When evidence is absent or confidence is low, the bot should clarify, disclose its limit or hand off. A prompt that demands an answer every time encourages guessing.

User messages, uploaded documents and tool output are untrusted by default. Prompt injection may try to override policy, reveal instructions or trigger an inappropriate tool. Reduce risk with least privilege, separation of data and instructions, action allowlists, input and output validation, and approval for consequential changes.

• ✓Index approved material and remove expired versions.
• ✓Use refusal and handoff thresholds instead of forcing an answer.
• ✓Do not place secrets, tokens, entire CRM datasets or unnecessary personal data in prompts.
• ✓Test out-of-scope questions, prompt injection, conflicting sources and tool failures.

Design human handoff as a primary workflow

Handoff is not a vague fallback added at the end of the project. It is a primary flow requiring triggers, routing, service levels, bot state and a route back to automation. Triggers can include an explicit request, risky intent, repeated misunderstanding, a priority customer or a failed business API.

At handoff, the bot should produce a concise summary of the need, verified information, attempted steps and reason for escalation. The agent needs context without making the customer repeat everything. The bot must pause while the agent works so both do not respond at once, then reactivate only on an agreed event or timeout.

In built-in Zalo Chatbot, keywords and flows can lead to a support path. Deeper assignment, CRM synchronisation, agent state or per-conversation AI pause may require a separate OpenAPI or omnichannel layer and must be validated against the actual account capabilities.

• ✓A visible request-to-agent button or phrase.
• ✓Routing by topic, branch, customer and operating hours.
• ✓A summary and verified details attached to the ticket or lead.
• ✓Explicit bot pause, agent ownership, timeout and reactivation states.

A 30-day pilot and production checklist

In week one, select one use case and establish a baseline: conversation volume, response time, handoff rate, common failure modes and the related business outcome. In week two, prepare knowledge, flows, handoff and CRM mapping. During week three, run internally and in shadow mode against sanitised real conversations. In week four, open to a limited customer group, review daily and decide whether to expand, adjust or stop.

Evaluate quality rather than containment alone. A bot that keeps many conversations but gives the wrong policy or loses leads creates no value. Track correct resolution, human correction, time to an agent, out-of-scope traffic, API failures and guardrail blocks.

Friday Works can support discovery, prototyping, the Zalo OA to AI/CRM integration and operational controls. Scope is confirmed only after checking the OA, API rights, data, use case and target systems; we do not assume an integration that the account or official documentation has not confirmed.

• ✓OA plan, API permissions, webhooks and limits checked in the live environment.
• ✓An evaluation set containing valid, out-of-scope, conflicting and adversarial cases.
• ✓Handoff, bot pause, retry, logs, alerts, retention and access tested.
• ✓Named owners for content, systems, operations and stop decisions when quality falls.