Notifications
Who gets told what, on which channel, when something happens in a conversation.
Email notifications
Set per chatbot, with multiple recipients supported.
| Notification | Default | Sent when |
|---|---|---|
| Qualified lead | On | A conversation crosses into a higher qualification tier. |
| Handoff requested | On | A visitor asks for a human. |
| Offline message | On | Someone submits the offline form. |
| Visitor confirmation | On | Acknowledges the visitor's offline message to them. |
Set a Reply-To. Notification emails come from an OyeChats sender so they authenticate correctly. Setting a Reply-To address per chatbot means a reply lands in your inbox, not in a no-reply void.
Operator alerts
- In-dashboard toast and sound while the tab is open.
- Browser push when the dashboard is closed. Requires the operator to grant permission once, and is skipped while their dashboard is demonstrably being watched so they are not alerted twice.
- Email as a backstop for conversations nobody picked up, debounced to one message per minute per waiting visitor.
Each operator sets their own preferences in Settings. In-app notifications also collect in a notification centre with unread counts.
Sending them somewhere else
For Slack, Teams, PagerDuty or an internal service, use a webhook rather than email forwarding. It is faster, structured, and gives you a delivery log.
Something here wrong or missing? Tell us and name this page. We will fix it.