# Notifications and escalation

What happens after your team posts an update: push first, then an email with a fresh link, then a staff follow-up if it is still unread.

## The problem this solves

An update the customer never sees is the same as an update you never sent. Customer Rooms therefore does not stop at "message delivered" — it escalates until either the customer has seen it or a named person on your team knows they have not.

## The ladder

When your team posts a customer-visible update:

| Step | What happens | When |
|---|---|---|
| 0 | Stop everything if the customer has already viewed the update | Immediately, and re-checked at every later step |
| 1 | Send a push notification to the customer's room app | Immediately, if they enabled notifications |
| 2 | Send an email carrying a fresh link back to the room | After the configured wait, if still unread and an email is on file |
| 3 | Create a follow-up for your team, synchronized to Boni Tasks | After the second configured wait, if still unread |

The default waits are around half an hour before the email step and around four hours before the staff follow-up. Your configuration may differ.

If there is no email on file, no owner, or an external step is uncertain, the ladder deliberately ends in a staff follow-up rather than retrying silently. Somebody is always left holding the outcome.

## Delivery and read state

Because there is no external messaging provider behind a room, Bow Chat can be precise about what the ticks mean:

| State | Means |
|---|---|
| Sent | Stored and available in the room |
| Delivered | Rendered by the customer's authenticated room app |
| Read | Seen while the customer had the chat open |

Opening the room's details alone never marks a message read. Only the messages actually rendered on screen are marked.

## Getting push notifications working

Push is the fastest step, and it is the one most often left off. Three things must all be true:

1. The customer opened the room in a supported browser or installed app.
2. The customer tapped **Enable notifications** in the room.
3. The browser permission prompt was granted.

Installing the app alone does not create a subscription. The room shows a visible notifications-off state with an action to turn them on, and says plainly when the browser itself has blocked notifications so the customer knows to change it in browser settings.

When a customer enables notifications, the latest unread update is retried immediately. Anything already read is not re-sent.

## Practical guidance for teams

- Ask the customer to enable notifications during the first interaction, while they are already in the room. Retrofitting it later is much harder.
- Keep the customer's email accurate. It is the only fallback between push and a human chasing them.
- Treat a step-3 follow-up as a real signal. Repeated follow-ups on the same customer usually mean notifications were never enabled, not that the customer is ignoring you.
- Do not repost the same update into WhatsApp as a habit. That trains customers to stop opening the room, which removes the reason to have one.

## What does not happen

- The same email is not sent twice because a job retried. Each step claims its event before doing anything external.
- A message the customer already read is never escalated.
- An escalation failure cannot break the customer's room. Receipt and notification problems are handled separately from the message timeline.

Canonical: https://docs.boni.one/bow-chat/customer-rooms/notifications-and-escalation
Version: 1
Updated: 2026-08-26T17:58:45.787Z