What WeCom already covers
- Notices, chase, read / unread
- Punches and simple leave
- Org directory sync
- Pushing to-dos to phones
It is the comms layer and the identity layer—not a contract library, and not a permission engine.
Many companies stop at this sentence: everyone is already in WeCom, so another back office would be a duplicate. What duplicates is “we can send a message,” not “we can run a ticket.” Enough or not depends on whether you need a chat—or a work entry you can chase, search, and hand over.
What your own back office must carry
- Approval routing by amount and department
- Contract versions, renewals, and a seal ledger
- Permissions that change when the role changes
- A full trail audit can export
Tickets, permissions, and ledgers live in your library. Chat only wakes people up.
How Feishu, DingTalk, and a custom back office differ: see Feishu, DingTalk, and a custom back office: what actually differs. WeCom approvals fit flows with few nodes, few fields, and one master-data set. Once you hit “over 50,000 goes to finance,” “project contracts need countersign,” or “subsidiaries cannot see each other,” chat approvals get bypassed—or configured into a maze nobody can change.
Audit does not want a chat log. It wants who approved which ticket, when, under which rule. The role: see What role OA plays in audit and compliance. Contracts scattered in chats and mail attachments: see The risk when contracts and policies live in email.
The right structure is two layers: WeCom for identity and reminders; the management back office for tickets and permissions. People tap a to-do on the phone and still open your own ticket—company assets do not lock into a chat bubble.
When you can wait on building your own back office
If headcount is small, flows are only leave and expenses, there is no contract ledger, and HQ does not need rollups, you can exhaust WeCom approvals first. From twenty toward eighty people, verbal permissions fail first; see From 20 to 80 people, why management has to be systematized. Adding a back office then usually costs less than forcing complex rules into a chat app.
Another misread: a heavily configured WeCom “approval app” is treated as OA. More apps, and admins stop changing them; a condition changes, and you wait on an implementer. Chat cannot find a contract renewal or export a full audit trail. Reminders can stay in WeCom; rules and ledgers should live in a back office you can change. Feishu and DingTalk are the same—the difference is still whether exceptions can move.
When DaXi builds a management system, we usually connect WeCom login and to-dos—we do not rebuild chat. To plan it together, go to the Management systems service page and describe how you use WeCom today. The path difference with versus without a back office: see With vs. without a management back office: how decisions actually move.