Notifying the team about a customer: Web Push, email or Zalo?

The task sounds simple: a customer leaves an inquiry on the website; notify the person responsible for handling it. But successful submission to a notification service does not mean an employee has seen the message.

Three channels, three roles

Do not call Zalo the worst option based on an indirectly quoted price or sending window. Distinguish OA chat from template messaging services: they are not one API with one set of rules.

What to confirm before choosing Zalo

The earlier draft included prices, sending hours, conversation windows and token lifetimes without sufficient primary policy evidence. This edition removes those figures rather than using them to reject a channel.

Before designing the integration, consult Zalo Developers and confirm with the provider whether employee notifications are supported, what recipient consent is required, whether templates need approval, and what sending limits, charges and reauthorization procedures apply. Do not build around circumventing an API's intended use.

Store tokens securely, handle expiry and revoked permissions, prevent concurrent refreshes if that token mechanism requires it, and alert on broken connections. Follow the documentation for the specific API product in use.

Web Push suits teams that work in a browser

Web Push can receive messages when a page is not in the foreground or is not currently loaded. It needs an active service worker and user permission. Visible delivery also depends on the browser, operating system, network, battery settings and do-not-disturb mode. Test on actual devices; do not promise instant delivery.

A commercial messaging intermediary is not mandatory, but delivery still depends on the browser ecosystem's push service. VAPID keys are only part of the implementation: manage subscriptions, encrypt payloads and handle expired endpoints too.

Four design decisions

1. Keep the payload small and fetch details after authentication

A notification can appear on a lock screen. Send an event type and an opaque identifier rather than the customer's message or personal information. On click, check the session and authorization before fetching details. An identifier does not replace access control; do not put access tokens or secret keys in the notification link.

2. Group related events

Five lines from one customer do not necessarily need five alerts. Notify on the first message or group events within a short window. Repeated newsletter subscriptions should not count as new customers simply because the endpoint returns success again.

3. Route to an owner and provide a backup

Route according to responsibility and permission to view the record. Do not alert people who cannot open the destination screen. Escalate to the backup person if nobody accepts responsibility within the agreed time.

Track “event stored,” “submitted to service” and “accepted for handling” separately. Do not collapse them into a misleading single “delivered” state.

4. Respect working hours

Use persistent notifications only when supported and appropriate. Define on-call coverage, quiet hours and priority. An inquiry at 11 p.m. is not automatically a reason to wake the entire team.

An old service worker can discard new notifications

The draft describes an older worker ignoring new message types:

if (data.kind && data.kind !== "visitor_waiting") return;

A CDN can retain an old file; the worker installation and activation lifecycle can also delay deployment. Inspect both instead of only clearing browser cache.

For a stable worker URL, use a suitable revalidation policy such as Cache-Control: no-cache. Check CDN overrides and whether a new worker is waiting to activate. no-cache does not prohibit storage. Add a version identifier so you can tell which worker a device is running, then test the complete flow on real devices.

A starting choice for a small team

Start with Web Push for alerts and email for a record if the team already uses the admin interface regularly. Design a queue, bounded retries, deduplication and failure alerts. Keep an in-application list of unresolved inquiries so work does not depend entirely on a notification sound.

If the team mainly uses Zalo, evaluate its official integration after confirming the supported workflow and current policy. The final criterion is whether someone takes responsibility within the agreed time, not which channel feels most familiar.

The worker incident is retained from the October 2026 Zukatek draft; its original logs are unavailable for independent verification. This article does not certify Zalo pricing or policy.

References: MDN Push API, MDN Cache-Control.