Customer Notification Channels in China: SMS, Push, WeChat, and Enterprise Apps
Compare notification channels in China and learn how Wavesteam plans, builds, and delivers unified notification systems.
No notification channel is simultaneously cheap, permissionless, universal, attention-grabbing, and proof of reading. For many Mainland China applications, keep the complete record in an in-app inbox, use in-app prompts or app push for active users, and reserve SMS for important cross-app fallback. Use calls only for a small number of high-loss events requiring confirmation. Use WeChat, WeCom, DingTalk, or Feishu only where the customer or employee already has the required relationship.
This guide concerns service, order, verification, task, and alert messages to existing users—not cold acquisition.
1. Define what “delivered” means
Track five separate states:
- Eligible to send: the application has a lawful recipient identifier and purpose.
- Accepted by provider: the channel API accepted the request.
- Delivered or displayed: the endpoint reports delivery or display where supported.
- Viewed: the user opened the message or destination.
- Action completed: payment, approval, rescheduling, or incident response occurred.
An API success is not proof that a person saw or understood the message. Wavesteam designs the event model and dashboard around the business action rather than one inflated “reach rate.”
2. Compare common channels
| Channel | Can alert outside the app? | Strong use | Main condition or limitation |
|---|---|---|---|
| SMS | Yes | Verification, payment/order exception, appointment change, critical fallback | Verified sender and template, consent where required, length-based billing; receipt is not read proof |
| App push | Yes | Transaction and engagement for active app users | Installation, valid token, notification permission, OS/vendor delivery and quotas |
| Human call | Yes | High-loss exception and complex confirmation | Expensive, intrusive, limited scale, number reputation and recording/privacy governance |
| Automated voice/contact center | Yes | Bulk urgent reminder and keypad confirmation | Qualified provider/line, blocking and complaint risk, human handoff |
| Mini-program subscription message | In WeChat | Appointment, queue, logistics, result linked to a user action | Scenario-specific subscription and template/category rules |
| Official-account message | In WeChat | Service progress and richer ongoing content | Follow/eligibility, message type, frequency and service-window limits |
| Yes | B2B notice, invoice, contract, report, long explanation | Deliverability, domain reputation, consent and unsubscribe; weaker urgency for many consumers | |
| In-app inbox | No | Durable source of truth and audit history | Cannot bring back a user who does not open the product |
| In-app modal/banner | No | Immediate interruption during an active session | Frequency and accessibility; closing is not agreement or understanding |
| WeCom | Relationship-dependent | Customer service, CRM follow-up, employee tasks | Internal app, group bot, and external-customer capabilities differ |
| DingTalk / Feishu | Mainly organization users | Approvals, alerts, projects, stores, supply chain | App identity, organization scope, group/resource permission, quotas |
“Low cost” still includes account certification, development, identifier mapping, review, retries, support, compliance, and upgrades.
3. Calculate cost per completed outcome
Use:
monthly channel cost = fixed account/platform + billable sends + engineering amortization + monitoring/operations + content/review labor + retry and failure handling
For SMS, calculate billable segments, not messages in a spreadsheet. For push, include multiple Android vendor channels, iOS/HarmonyOS behavior, privacy SDK work, version updates, and analysis. For calls, include attempts, answer rate, handling time, first-contact resolution, transfers, and quality assurance. A lower per-send price can produce a higher cost per completed task.
4. Use each channel for what it does best
SMS should carry the event, trusted sender, critical status, and safe next action, with details behind authenticated access. Do not expose full health, order, or financial information.
App push supports deep links and segmentation, but distinguish transactional from marketing messages and respect user and OS settings. Measure provider acceptance, device delivery where available, display, click, uninstall/invalid token, and task completion separately by platform.
Request mini-program subscription at the relevant service action and explain what and when will be sent. Do not turn one service authorization into unlimited marketing. Maintain the source, template version, recipient mapping, send result, and revocation.
Configure SPF, DKIM, and DMARC for email, separate transactional and marketing streams, and process bounces, complaints, and unsubscribe. Keep urgent information in the product and use another alert channel where loss is high.
The in-app inbox is the durable message record. A modal only draws attention during the session and must not delete that record when dismissed. Give promotional pop-ups clear identity and an easy close path.
Enterprise collaboration channels are strong inside existing relationships and weak outside them. Select the platform where the intended people already work; do not choose from API breadth alone.
5. Wavesteam's default design
Wavesteam classifies events by urgency, expected loss, privacy, required confirmation, recipient relationship, and fallback. We design a channel matrix, consent and identifier model, message templates, provider adapters, retries and deduplication, quiet hours and frequency, status events, audit, and an escalation path.
Acceptance uses representative users and devices to verify eligibility, provider receipt, display where measurable, deep link, task completion, failure/retry, duplicate prevention, opt-out, and unauthorized disclosure. The client owns message purpose and business content; Wavesteam owns the technical recommendation and evidence. Provider pricing, review, delivery, and policy remain provider responsibilities.
Pricing, APIs, platform policies, and regulations change over time. This article is for product and technical planning only and is not legal advice.