How should a B2B SaaS product design its notifications?

Illustrative situation: a project-tracking platform for construction firms sends each site manager about 40 emails a day. Most say a teammate commented, moved a due date or joined a project. One Tuesday, an email reports that the nightly sync with the customer’s accounting system failed. Nobody opens it. Three days later finance finds invoices missing, and the customer’s admin asks support how to switch the emails off. Support suggests an inbox filter. The scene is invented, but the pattern is common: each feature added its own alerts, and nobody owned the whole set.

Humbleteam, a digital product design agency, publishes this guide. It treats notifications as one system with four decisions for every event: whether to send it, where, when, and who can switch it off. Those decisions come from an inventory, not from a settings page.

Why do defaults matter more than the settings page?

Most people keep the defaults. Nielsen Norman Group (NN/g) notes that most users don’t customize their systems even when it would help them, so a preferences screen does not excuse sending too much to everyone who keeps the defaults. People who feel spammed switch notifications off, and then the important alert goes nowhere. NN/g’s smart home research calls this a cry-wolf effect: a stream of minor alerts teaches people to ignore all of them.

What goes into the event inventory?

List every event that can produce a message today, from every team. For each one, record five facts:

• Trigger. What happened, in the user’s words: “sync failed,” not an internal status code.
• Recipient rule. Why this person gets it. GitHub separates participating from watching: a comment or an @mention subscribes you to one conversation, while watching subscribes you to a whole repository. Linear subscribes you to an issue when you create it, are assigned to it or are mentioned in it. Role-based rules, such as billing contact or workspace admin, depend on your role model; our guide to roles and permissions in B2B SaaS covers it.
• Volume. How often it fires per user per week, from your logs.
• Action. What the recipient should do, if anything.
• Deadline. How soon that action loses its value.

The last two facts decide most of what follows. An event with no action and no deadline is information, and information rarely earns an interruption.

How urgent is each event?

Sort every event into one of four tiers.

1. Interrupt. The recipient must act soon, and waiting costs something. Apple reserves its Time Sensitive level for events happening now or within an hour, such as an account security issue. The one-hour test works for B2B products too.
2. Inbox. The recipient must act, but not this minute: an assignment, a review request, a mention.
3. Digest. Worth knowing, no action needed: a status change on something the user follows, a weekly usage summary.
4. No message. Show it in context instead. NN/g separates indicators from notifications: an indicator is a passive cue on the item that changed, like bold text for unread items. A badge on a project card often does the work of an email.

Assign tiers honestly. Apple asks apps to represent urgency accurately, because people who get interrupted with low-priority information can turn off all notifications. It also rules out Time Sensitive for marketing. Android raises the stakes of a wrong first choice: each notification channel gets its importance level when the app creates it, and from then on only the user can change its behavior.

Which channel suits which tier?

Make the in-app inbox the record. Linear’s documentation says notifications always appear in its inbox, and the other channels carry real-time alerts. GitHub’s inbox lets people mark items done, save them, unsubscribe from a thread and see a label with the reason they were notified. A reason label answers the question people ask when a message feels like noise: why am I getting this?

Treat email and push as fallbacks that respect what the user has already seen. Linear sends email digests only if the inbox notification is still unread. Slack sends mobile notifications when you’re not active on desktop. The principle to copy: move to the next channel only when the first one went unseen.

Push needs consent. On Android 13 and later, an app’s notifications are off by default until the user grants permission, and Google advises asking in context, for example when the user taps a bell icon. Apple’s guidelines also require permission first and an in-app screen where people can change their choice.

Slack or Teams suits events that belong to a team, such as a failed integration any admin can fix. Our suggestion: post those to a channel the admin picks, not to each admin’s direct messages.

How should batching and digests work?

Batch everything below the interrupt tier. Jira Cloud groups updates for the same recipient and issue, waits 3 minutes after a change, restarts the wait if another change arrives, and sends after 10 minutes at most. Mentions and assignments skip the queue. Atlassian reports about 30% fewer emails on average.

That gives three speeds: immediate delivery for interrupts only, a window of a few minutes for bursts on one object, and a daily or weekly digest for the digest tier. NN/g suggests combining more than five notifications into one message instead of sending a burst.

Ongoing conditions need different handling from events. NN/g’s smart home study recommends alerting on each discrete event but using thresholds for persistent conditions, letting alerts expire once the issue resolves, and telling users when normal operation resumes. In B2B terms: one alert when a sync starts failing, a reminder if it still fails tomorrow, and a “resolved” message when it recovers, never one email per failed run.

A good digest groups lines by object, leads with whatever needs action, gives counts for the rest and links each line to its item.

Who controls what: users, admins or nobody?

Each event needs an answer at three levels.

Users choose channels and frequency for their own activity. Keep the screen short by grouping. Linear treats “status changes” as one toggle that covers completions, cancellations, urgent-priority changes and blocking changes.

Workspace admins set defaults and guardrails. Slack lets owners and admins set default Do Not Disturb hours for everyone, while members can still change their own. Owners can limit who may use @channel and @here, and by default a warning appears when someone uses them in a channel with at least six members. In Jira, the admin sets the default notifications and users can override some of them.

Nobody switches off a short list of mandatory messages. Our suggestion: account security events, billing failures and changes to terms. Keep those messages free of promotion. The FTC’s CAN-SPAM guide treats security information, transaction confirmations and changes to account terms as “transactional or relationship” messages, but it reads those categories narrowly. If promotional content opens the email, or the subject line reads like an ad, the message counts as commercial. The law makes no exception for business-to-business email, and commercial email needs a working opt-out honored within 10 business days.

Mailbox providers add rules for volume senders. Google requires anyone sending about 5,000 or more messages a day to personal Gmail accounts to support one-click unsubscribe, defined in RFC 8058, for marketing and subscribed messages and to keep reported spam below 0.3%. Its FAQ excludes transactional messages and recommends honoring unsubscribes within 48 hours. Yahoo requires them honored within 2 days. This is general information, not legal advice, so ask counsel which of your messages count as commercial.

For product emails that are neither marketing nor mandatory, our suggestion is to include an “unsubscribe from this type” link anyway, as GitHub’s notification emails do. A one-click exit from a single event type costs less than a spam report against your sending domain.

What should each notification say?

NN/g points out that notifications need more context than validation messages, because they arrive while the user is busy with something else. Each one should say who did what, to which object, why this person is receiving it and what to do next, with one link to the exact place.

Compare “Sync error” with “The nightly sync with your accounting system failed at 02:10. 38 invoices were not imported. Reconnect the integration to retry.” The second names the object, the impact and the action. Put the object’s name in the email subject so people can scan their inbox, and keep urgency words out of the sender name. Google lists display names such as “URGENT REQUEST” as misleading.

How do you know it’s too noisy?

Measure each event type, not each channel. Our suggested set:

• Sends per active user per week.
• Click-through to the object, and the share acted on before the deadline.
• Mute, unsubscribe and opt-out rates, plus push permission revocations.
• Spam complaint rate in Google Postmaster Tools.
• Support tickets about missed alerts.

An event type with high volume, little action and rising mutes drops a tier. An interrupt that people rarely act on in time is either in the wrong tier or badly written. Review the inventory every quarter, because new features add events quietly.

The notification inventory worksheet

One row per event. These rows are an illustrative starting set for a collaborative B2B product, not a standard.

Illustrative worked example: back to the construction platform

This continuation is invented. The team behind the platform from the opening runs the inventory and finds 23 event types, 17 of which email every project member by default. Four decisions change the site manager’s day.

The sync failure now goes to the people who can fix it, in a channel that carries little else. Whether site managers want push on their phones while on site needs a short test with a few of them, and the noise metrics above will show whether the new defaults hold.

What can you produce now?

Four working documents, before anyone draws a settings screen.

1. The inventory, one row per event, with trigger, recipient rule, volume, action and deadline.
2. A tier and channel decision for each row, using the worksheet columns.
3. A preferences specification: event groups as rows, channels as columns, mandatory rows locked with a one-line reason such as “Required for account security,” and a separate admin defaults page.
4. A noise dashboard per event type with the metrics above.

If you plan to bring in outside designers for the inbox, preference and admin screens, our comparison of UX/UI agencies that design complex B2B SaaS platforms shows which studios publish work on screens like these.