Designing a scalable notification system for a conversation intelligence platform
Designing a scalable notification system for a conversation intelligence platform
When every module generates events, the real design challenge isn't building notifications - it's deciding what shouldn't be one.
When every module generates events, the real design challenge isn't building notifications - it's deciding what shouldn't be one.
my role
Product Designer
channels
In-app, Email, Reports
users
Agents, Managers, Admins
platform
B2B SaaS Web App
TL;DR
Context
Convin's 4 modules (Coaching, LMS, Audit, Reports) each generated events with no unified notification logic. Users were either missing critical alerts or drowning in noise.
Approach
Built a routing framework first - classifying every event by urgency and persona before touching UI. The framework answers: who, how urgent, which channel for every event type.
Key decision
The same event routes differently per persona. A coaching assignment is an urgent toast for an agent, but an inbox digest item for a manager reviewing team workload.
Output
A 5-surface notification system (Inbox, Email, Toast + Snackbar, Banner, Inline alerts) with role-based defaults, escalation logic, and user preference controls - serving 3 distinct personas.
THE CHALLENGE
Too many events, no structure
Too many events, no structure
Too many events, no structure
Convin's platform spans four modules — Coaching, LMS, Audit, and Reports. Each module generates system events constantly: sessions assigned, scores updated, SLA breaches, report completions. But there was no unified logic deciding which events became notifications, who received them, or how.
The result was a split failure: some critical events were missed entirely, while others created noise that users learned to ignore. Both outcomes break trust in the product.
Convin's platform spans four modules — Coaching, LMS, Audit, and Reports. Each module generates system events constantly: sessions assigned, scores updated, SLA breaches, report completions. But there was no unified logic deciding which events became notifications, who received them, or how.
The result was a split failure: some critical events were missed entirely, while others created noise that users learned to ignore. Both outcomes break trust in the product.
How do we design a notification system that is relevant, timely, and non-
intrusive - across three very different user personas?
How do we design a notification system that is relevant, timely, and non-
intrusive - across three very different user personas?
How do we design a notification system that is relevant, timely, and non-
intrusive - across three very different user personas?
Old notification UI
INSIGHT
Notifications are interruptions, not features
Notifications are interruptions, not features
Notifications are interruptions, not features
The first framing shift was recognizing that every notification is a cost to the user's attention. Sending one is a claim that the information is worth interrupting what they're doing. Most systems skip this question entirely.
This led to a principle that drove every downstream decision: not all events should become notifications. Some belong in dashboards. Some in digests. And a few - the genuinely time-sensitive ones deserve real-time delivery.
The first framing shift was recognizing that every notification is a cost to the user's attention. Sending one is a claim that the information is worth interrupting what they're doing. Most systems skip this question entirely.
This led to a principle that drove every downstream decision: not all events should become notifications. Some belong in dashboards. Some in digests. And a few - the genuinely time-sensitive ones deserve real-time delivery.
FRAMEWORK
A decision framework before any UI
A decision framework before any UI
A decision framework before any UI
Before designing any screen, I built a routing framework to answer three questions for every event: who needs to know, how urgently, and through which channel. This framework became the foundation the UI was built on top of.
Before designing any screen, I built a routing framework to answer three questions for every event: who needs to know, how urgently, and through which channel. This framework became the foundation the UI was built on top of.
How do we design a notification system that is relevant, timely, and non-
intrusive - across three very different user personas?
How do we design a notification system that is relevant, timely, and non-
intrusive - across three very different user personas?
How do we design a notification system that is relevant, timely, and non-
intrusive - across three very different user personas?
Urgency → Channel logic
Persona thinking same event, different intent
The same coaching assignment event means different things to an agent (act on it) vs a manager (monitor it). Routing was designed per persona, not per event type.
Persona thinking same event, different intent
The same coaching assignment event means different things to an agent (act on it) vs a manager (monitor it). Routing was designed per persona, not per event type.
Persona thinking same event, different intent
The same coaching assignment event means different things to an agent (act on it) vs a manager (monitor it). Routing was designed per persona, not per event type.
AGENT
(task driven)
Needs clear CTAs. Time-sensitive. Toast and snackbars for urgent actions; inbox for trackable tasks.
AGENT (task driven)
Needs clear CTAs. Time-sensitive. Toast and snackbars for urgent actions; inbox for trackable tasks.
AGENT
(task driven)
Needs clear CTAs. Time-sensitive. Toast and snackbars for urgent actions; inbox for trackable tasks.
MANAGER (oversight-driven)
Needs clear CTAs. Time-sensitive. Toast and snackbars for urgent actions; inbox for trackable tasks.
AGENT (task driven)
Needs clear CTAs. Time-sensitive. Toast and snackbars for urgent actions; inbox for trackable tasks.
MANAGER (oversight-driven)
Needs clear CTAs. Time-sensitive. Toast and snackbars for urgent actions; inbox for trackable tasks.
ADMIN (system-driven)
Needs visibility and control. Low urgency, high volume. Email-first with preference controls
AGENT (task driven)
Needs clear CTAs. Time-sensitive. Toast and snackbars for urgent actions; inbox for trackable tasks.
ADMIN (system-driven)
Needs visibility and control. Low urgency, high volume. Email-first with preference controls
Event × Persona × Channel mapping table
REDUCING FATIGUE
The harder problem: what not to notify
The harder problem: what not to notify
The harder problem: what not to notify
Notification fatigue is a design failure, not a user problem. If users are muting or ignoring alerts, the system is sending the wrong things. The design decision here was structural - every event had to earn its right to interrupt.
Notification fatigue is a design failure, not a user problem. If users are muting or ignoring alerts, the system is sending the wrong things. The design decision here was structural - every event had to earn its right to interrupt.
Not everything becomes a notification - some become dashboards.
SYSTEM DESIGN
Routing logic and delivery architecture
Routing logic and delivery architecture
Routing logic and delivery architecture
The system design translates the framework into a decision flow. Every event enters the same pipeline, gets evaluated for persona and urgency, and exits through the right channel. Failures are handled with retries, and unresolved high-priority events escalate rather than repeat.
The system design translates the framework into a decision flow. Every event enters the same pipeline, gets evaluated for persona and urgency, and exits through the right channel. Failures are handled with retries, and unresolved high-priority events escalate rather than repeat.
Not everything becomes a notification - some become dashboards.
Three principles drove the architecture:
Three principles drove the architecture:
01
01
01
Persona first, channel second
Persona first, channel second
Persona first, channel second
The same event routes differently based on who receives it. Channel is a consequence of identity + urgency, not a property of the event itself.
The same event routes differently based on who receives it. Channel is a consequence of identity + urgency, not a property of the event itself.
02
02
02
Urgency determines real-time vs async
Urgency determines real-time vs async
Urgency determines real-time vs async
Only two scenarios earned real-time delivery: time-sensitive actions an agent must take before their next session, and SLA breaches a manager must see immediately.
Only two scenarios earned real-time delivery: time-sensitive actions an agent must take before their next session, and SLA breaches a manager must see immediately.
03
03
03
Failures escalate, not repeat
Failures escalate, not repeat
Failures escalate, not repeat
If a high-priority notification isn't acted on, the system escalates to the manager rather than re-pinging the agent. Repetition trains users to ignore - escalation creates accountability.
If a high-priority notification isn't acted on, the system escalates to the manager rather than re-pinging the agent. Repetition trains users to ignore - escalation creates accountability.
UI SURFACES
Where notifications appear in the interface
Where notifications appear in the interface
Where notifications appear in the interface
Each surface was chosen for a specific behavioral contract with the user. The goal was for placement alone to communicate urgency - before the user reads a word.
Each surface was chosen for a specific behavioral contract with the user. The goal was for placement alone to communicate urgency - before the user reads a word.
In-app Inbox
Trackable, persistent. Catches all medium-priority notifications via the bell icon. User-initiated read - no interruption to current task.
Async, outside the session. Reports and performance summaries are delivered as daily or weekly digests. Appropriate for informational content that doesn't need immediate action.
Toast
Immediate, temporary. Fires for high-urgency actions. Disappears in 5s — designed to interrupt, not persist. Used when the user must act now.
Snackbar
Lightweight, confirmatory. Appears after a user action (e.g., session submitted, score saved). Non-blocking doesn't interrupt the workflow, just acknowledges it.
Banner
Page-level, persistent. Used for system-wide alerts or feature updates. Stays visible across the session until the user dismisses it.
Inline Alert
Contextual, embedded within list rows or content. Non-intrusive CTA within the content itself - no context switch needed. Used for coaching assignments and audit flags.
Email templates examples for weekly reports and violation analysis
IMPACT
What the system achieved
What the system achieved
What the system achieved
Impact was evaluated across three dimensions: relevance (right person gets the right alert), timeliness (critical events reach users before they expire), and noise reduction (users stop ignoring the system).
Impact was evaluated across three dimensions: relevance (right person gets the right alert), timeliness (critical events reach users before they expire), and noise reduction (users stop ignoring the system).
project type
B2B SaaS | AI powered Coaching & Assessments
my role
Product Designer
Company
Convin
Other Projects
Convin Design System
Component Library, Style Guide & Tokens
Voice AI Widget
Interactive Web Widget
Interactive Web Widget