AI assistant in WhatsApp, VK, Telegram, or MAX — is not four separate “brains,” but one managed conversational backend with channel adapters. It detects intent, looks up answers in the knowledge base, calls CRM/other tools based on permissions, hands the conversation off to a human, and the adapter applies the rules of each specific platform.
Choosing “where the audience is largest” is not enough. You need real intent and entry points, an official API, outbound messaging rules, UI, identity, cost, delivery quality, and a migration plan. Features, pricing, policies, and availability change: check them again before launch.
Short answer: pick one high-volume intent, map its volume and channels, define the required capabilities and constraints, then verify them in the official documentation. Pilot one channel, but separate the shared core from the adapter right away so the second channel does not require rewriting everything.
Key points in one minute
- Use official APIs, not emulation of a personal client.
- Do not equate a messenger ID with a CRM customer without linking.
- Separate accepted, sent, delivered, read, and failed.
- Store opt-in, template, and opt-out rules by channel.
- Do not let a document or message change the system policy.
- Human handoff should have a queue, owner, context, and return state.
- Choose the channel using a weighted matrix, not preference.
Contents
- What to compare
- The CHANNEL method
- WhatsApp Business Platform
- VK
- Telegram
- MAX
- Unified architecture
- Identity, consent, and outbound
- Human handoff
- Reliability and security
- Metrics
- Pilot and acceptance
- Frequently asked questions
- How AI Dawn builds an omnichannel assistant
- Conclusion
What to compare
| Criterion | Question |
|---|---|
| audience/entry | where and how do people start the conversation? |
| official access | what type of account, API, and review are required? |
| initiation | when can the business message first? |
| interface | buttons, menus, media, web/mini app? |
| identity | what ID does the bot receive, and how do you link it to CRM? |
| delivery | what webhooks/statuses are available? |
| operations | is there an inbox, roles, handoff, export, and audit? |
| constraints | policy, rate, template, geography, data, cost, and change risk? |
The weighting is set by the business. For support, inbound, history, and handoff matter; for reminders, outbound policy and statuses matter; for a complex form, Mini App/WebView matters.
The CHANNEL method
- C — Client: audience, intent, entry point, and accessibility.
- A — API: official access, events, UI, and limits.
- N — Norms: consent, initiation, templates, content, and opt-out.
- A — Architecture: adapter, identity, RAG, tools, CRM, and handoff.
- L — Logs: delivery truth, audit, incidents, portability, and exit.
A channel passes only if it covers the hard constraints. A high audience score does not make up for a blocked outbound scenario you need.
WhatsApp Business Platform
The official WhatsApp Business Platform gives businesses an API layer; inbound and status events come through webhooks. Do not replace it with an unofficial WhatsApp Web automator: the approaches have different reliability, policy, and account risk.
Before launch, check onboarding, business verification, the phone number, templates, customer-service window, consent, category, pricing, and availability in the required jurisdiction. This article does not lock in these changeable parameters.
VK
VK bot documentation and community messages define the community, token, events, and messages layer. VK makes sense when the entry point is tied to a community, content, and a VK audience.
Check event types, keyboards, media, community permissions, rate limits, and the mini app integration against the current API version. Do not assume a user ID alone authorizes a CRM action.
Telegram
Telegram Bot introduction notes an important boundary: a bot cannot start a conversation with a user on its own. Bot API is the HTTP interface for messages, updates, buttons, files, and other objects. Mini Apps are useful for catalogs, forms, and a personal account area.
The bot token is a secret with full control over the bot; store it in a secret manager, rotate it, and do not put it in a prompt or repository.
MAX
Official MAX API describes the HTTPS API, messages, inline keyboard, contact/location requests, Webhook, and Long Polling. As of 08/10/2026, the documentation recommends Webhook for production and requires HTTPS with a trusted certificate. It also describes request_contact with a hash to verify that the user shared the phone number linked to their MAX account.
This does not mean automatic identification in an internal CRM: the business defines linking and the required assurance level. Because the API is evolving quickly, the adapter should be explicitly versioned.
Unified architecture
channel/webhook → verify/dedupe → adapter → conversation state → policy → RAG/tools → response plan → adapter/render → send → status reconciliation → CRM/audit.
The shared core stores the intent taxonomy, knowledge, policy, tool permissions, handoff, and eval. The adapter stores event mapping, channel/user/message IDs, buttons/media, text limits, initiation/template rules, send method, statuses, and errors. That way, the prompt does not decide whether a message can be sent: policy and the adapter do.
Knowledge is returned with a citation/version; the principle is described in the RAG guide. The CRM record is handled by the schema and tool gateway, not free text.
Identity, consent, and outbound
The identity map links channel + channel_user_id to an internal party only after an explicit procedure. An address, username, or phone number can change; merge/split and recovery require audit. The identity level depends on the action: FAQ and order status lookup are not the same risk.
The consent registry stores purpose, channel/address, source, wording/version, timestamp, proof, and withdrawal. The outbound policy checks the channel rule, user initiation/window, approved template, frequency, quiet hours, suppression, and opt-out before send. Applicable legal grounds are determined by counsel and the business privacy owner.
Human handoff
Handoff packet: channel/conversation, verified identity level, intent, summary, user messages, retrieved evidence, tool actions/results, reason, urgency, and next safe action. The operator receives the queue and ownership; the bot stops responding except for explicitly allowed service messages.
Returning to the bot requires a close reason and reset/continue policy. Without that, the bot may interrupt the operator's conversation. General principles of support automation are given in the AI for support article.
Reliability and security
The server verifies the webhook, deduplicates the event ID, quickly acknowledges receipt, and processes through a queue. Outbound requests receive an idempotency key, correlation ID, and status. Stuck states are reconciled; retries must not create duplicate actions.
Tokens and webhooks are isolated by channel. Minimum controls: secret manager/rotation, least privilege, tool allowlist, encryption, retention, audit, DLP/redaction, rate/abuse limits, prompt-injection defense, incident response, and kill switch. A channel outage moves the conversation to waiting, not to a hidden duplicate on another channel.
Metrics
| Layer | Primary | Guardrail |
|---|---|---|
| acquisition | started qualified dialogue | consent/source defect |
| response | supported resolution | unsupported answer |
| tools | confirmed business action | wrong/duplicate write |
| delivery | terminal status | stuck/failed unnoticed |
| handoff | accepted by owner | lost context/queue |
| experience | completion/repeat contact | complaint/opt-out |
| portability | adapter change effort | core coupled to channel |
Metrics are calculated by channel, intent, version, and cohort. An average does not hide failure in one adapter.
Pilot and acceptance
- One intent, audience, and baseline across channels.
- Hard constraints and weighted scorecard.
- Check the official API/policy/cost as of the date.
- Shared core and one adapter contract.
- Identity, consent, outbound, and handoff policies.
- Frozen eval for answer, tool, channel rendering, and failures.
- Shadow, then limited public traffic.
- Incident/rollback and
scale / revise / stop.
Acceptance: scorecard and source snapshots; architecture/data flow; adapter contract; identity/consent registries; prompt/knowledge/tools; eval; status reconciliation; dashboards/alerts; handoff; runbooks; token rotation; export of conversations, knowledge, policy, and adapter code.
Frequently asked questions
Which messenger is best?
There is no universal winner. The best channel covers the business's specific audience, intent, initiation, UI, identity, operations, and hard constraints.
Can you launch all four channels at once?
Technically yes, but a pilot on one channel makes it faster to separate a core error from an adapter error. The architecture is still omnichannel from the start.
Can the bot message first?
It depends on the channel, message type, user initiation, template/consent/policy, and permissions. That is a policy engine check, not an LLM decision.
Do you need a separate CRM?
Not necessarily. You need a single source of truth for the customer, request, action, and ownership. That can be the current CRM/help desk with the necessary API.
How do you avoid losing the conversation during a failure?
Verify and deduplicate webhooks, store conversation state, process through a queue, reconcile statuses, and have a degraded mode with a queue for humans.
What should be migrated when changing channels?
Intent taxonomy, knowledge, prompt/policy, tool schemas, eval, conversation records within retention periods, identity links with a basis, consent/opt-out, metrics, and handoff rules. Secrets and channel IDs are not migrated as universal identity.
How AI Dawn creates an omnichannel assistant
AI Dawn can study intents and channels, build a shared conversational core, RAG and tool gateway, develop official WhatsApp/VK/Telegram/MAX adapters, integrate CRM/help desk, configure identity, consent/outbound, handoff, eval, monitoring, launch, training, and support.
The safest first step is one intent and one official channel: lock in the baseline, API/policy snapshot, knowledge, identity level, allowed tools, handoff, and critical failure, then launch a limited pilot. Discuss the project.
Conclusion
Do not choose WhatsApp, VK, Telegram, or MAX based on a single audience number. The CHANNEL connects the customer, the API, compliance requirements, architecture, and logs. Hard constraints filter out the wrong options first; after that, the scorecard compares what remains.
One shared core and versioned adapters provide omnichannel capability without duplicating logic. Official APIs, verifiable identity, policy checks before send, final delivery states, and a full handoff matter more than a model’s demo reply.