Find out where your employees already work, then decide where the bot lives
Many teams frame the selection question as "which of DingTalk, Feishu or WeCom has the stronger bot". That is the wrong question. The gap in bot capability ceilings across the three is far smaller than the gap caused by whether employees are willing to open it.
The right questions are two:
The five dimensions below exist to answer the second question: when you need entry points on multiple platforms, which dimensions become real differences and which are essentially the same everywhere.
Feishu has the most open custom-app model of the three: create an app, request permissions, obtain app_id and secret, then configure event subscription webhooks. Permission granularity goes down to reading messages, sending messages and reading the contact list as separate requests, which suits engineering teams that want fine-grained control.
WeCom has two bot types: group bots (mostly webhook push, easy to configure but limited capability) and custom apps (requiring a corp ID and secret, capable of more but with many backend options that often trip up first-time configuration).
DingTalk integrates tightly with internal management scenarios. QR-code binding and organisation sync work out of the box, while the interface shape for custom capability is relatively fixed.
| Platform | Minimum viable setup | Who it fits |
|---|---|---|
| Feishu | Custom app + event subscription, permissions requested as needed | Engineering teams that need precise permission control |
| WeCom | Group bot webhook (simple) / custom app (full) | Quick validation, or an existing WeCom ecosystem |
| DingTalk | QR-code binding + organisation sync | Companies already running OA and approval flows on DingTalk |
For setup details, see Feishu AI Bot in 30 Minutes, How to Build a WeCom AI Bot and How to Connect a DingTalk AI Assistant.
This is the most underestimated dimension. At-mentioning a bot in a group and asking it in a direct chat are two very different interaction densities.
The advantage of the group scenario is that one question lets a whole team see the answer, which produces a natural diffusion effect. It fits "spectator-style" needs such as policy Q&A and status queries. Feishu and DingTalk both give a smooth in-group mention experience; WeCom applies stricter limits on message visibility in external groups that include customers. That is a compliance design, not a defect, but it changes how you use it: external groups suit one-way push rather than multi-turn Q&A.
The direct chat scenario is where real work happens. An employee privately asks "what was the reconciliation process for this client last quarter", and the assistant needs to search the knowledge base, check permissions and summarise. All three accept direct messages, but whether the assistant can write the result straight into a file depends on the bot's capability boundary, not on the platform itself.
The three platforms differ in permission granularity, but what matters more is which layer performs permission management.
If the AI bot is a native custom app inside the platform, permissions follow the platform admin and IT already knows the drill. If the bot is an independent AI layer, it carries its own model for granting capability by role: skills on and off, command allow and deny lists, knowledge base visibility scopes and remote tool loading are all managed on the AI side, decoupled from the IM platform.
That difference is invisible when you only have one platform, and becomes decisive when several platforms coexist: three permission configs mean that when something fails you cannot tell which layer blocked it. In a multi-platform setup, permissions should be centralised in the AI layer while the IM platform only lets messages in.
One easily missed point: auditability. Who asked what, when, and which files the assistant touched — can all of it be reviewed. Auditability is the precondition for loosening permissions; without it, IT will never approve.
This is the dimension most worth asking about and least often asked. Where do your policy documents live?
If documents live in Feishu Docs, the Feishu bot has the shortest retrieval path. If they sit in DingTalk attachments or internal systems, you must extract them into a unified index first. If they live in WeCom chats and documents, permission complexity is highest, because chat history mixes personal and business content.
In a cross-platform setup there is one more concern: the knowledge base needs departmental boundaries. A customer service script handbook should be visible only to customer service, finance rules only to the relevant departments. When you run multi-platform access, isolate the knowledge base by department rather than by IM platform — otherwise the same person can switch IM clients and read another department's material.
Finally, check whether it can reach business systems: CRM, ticketing, ERP, internal databases. All three provide open interfaces, and the real difference lies in whether you can use one unified protocol rather than integrating each platform separately.
The less painful route is to connect internal systems through a standard protocol such as MCP: start and stop each server independently, and control which remote tools each agent may load, per department. Integrate once and all IM platforms share the same toolset instead of rebuilding integration for each.
See Connecting AI Agents to IM Platforms for the related architecture.
If your employees are spread across Feishu, WeCom, DingTalk, Weixin and QQ, the most reasonable architecture is: IM platforms serve as entry points only, while AI capability is centralised.
The benefits are direct:
Binding is usually a one-off step: administrators scan a QR code to bind Feishu, WeCom and Weixin, then configure bot accounts for QQ, Teams and WhatsApp. Bind once and the whole company can use it, with no per-employee setup.
One point per question. 0-3: connect one primary platform only. 4-7: primary platform plus one secondary entry point. 8 or more: adopt a multi-platform unified backend.
| # | Question | What it means for selection |
|---|---|---|
| 1 | Which IM is primary? What share of users sit there? | The largest platform is your first entry point — do not spread effort evenly |
| 2 | Is a second IM platform in daily use? | If yes, plan multiple entry points or adoption dies on friction |
| 3 | Do customers in external groups need to be served? | If yes, evaluate WeCom external group capability separately |
| 4 | Do you have engineers who can configure apps and permissions? | If not, prefer the lowest-threshold onboarding path |
| 5 | Where are policy documents primarily stored? | This decides which platform has the shortest retrieval path |
| 6 | Do departments need to see different content? | If yes, the knowledge base must support departmental isolation |
| 7 | Will IT allow file and command permissions for the bot? | If not, build auditability first or nothing moves |
| 8 | Does the bot need internal systems? How many? | Several systems means prefer a unified protocol over per-platform integration |
| 9 | Which platform already runs your OA, approval or scheduling? | Stay with the existing ecosystem to minimise migration cost |
| 10 | Can budget and compliance absorb running several platforms? | If not, go deep on one rather than shallow on three |
Feature lists and real usage scenarios are different things. Employees will use a tool in one place, and that place sets the ceiling. Define the scenario before choosing the platform.
Cheap short term, expensive later: three permission sets, three knowledge bases, three audit logs, and no way to localise a failure. Centralise in the AI layer and keep IM as entry points only.
Model capability is at the same level across all three platforms. The real difference is entry point and integration. Settle platform and entry points first, otherwise you pay for capability you never use.
The capability gap between DingTalk, Feishu and WeCom AI bots is not large enough to agonise over. What actually separates outcomes is whether employees adopt the tool and whether the company dares to grant it permissions.
So the order should be: find out which platform employees are on, decide how many entry points you need, and only then choose the onboarding route and model capability. Get selection right once and everything downstream has a foundation.