ServiceNow Notifications and Email Handling KPIs and Metrics That Matter

This page sets out the KPIs and metrics that matter for ServiceNow notifications and email handling, and the decision each one should inform. It covers email delivery, read rates, alert fatigue, preference compliance, content, escalation and how to build a baseline before setting targets.

Notification measures earn their place when each one informs a decision: whether a rule is too broad, whether mail is reaching inboxes, whether people act on what they receive. This page covers email delivery and reliability, reach and read rates, alert fatigue and overload, preference compliance, content and actionability, channel and escalation, how to build a baseline before setting targets, and what to do when the numbers disagree with the people using the system.

Email Delivery and Reliability

Measure email delivery success rate: percentage of emails generated by ServiceNow that successfully arrive in user inboxes. Most organizations aim for reliable email delivery. Rates below expected suggest either email configuration problems (incorrect SMTP settings, authentication issues) or email being marked as spam. Monitor bounces: percentage of emails returned as undeliverable (bad email address). Low bounce rates are healthy; high bounce rates suggest stale email addresses in the system or email validation isn’t working. Also track spam filtering: what percentage of ServiceNow notifications land in user spam folders instead of inboxes? Organizations often don’t monitor this until users complain, but implementing feedback loops (users report ServiceNow emails in spam) helps track the problem. Most organizations implement DMARC/SPF/DKIM email authentication to reduce spam folder placement.

Notification Reach and Read Rates

Measure notification read rate: percentage of sent notifications that users actually open and read. This is harder to track than delivery (opens require tracking pixels in HTML emails or user action logging in ServiceNow) but valuable. Most organizations see moderate read rates on well-targeted notifications. Low read rates suggest either notifications aren’t reaching inboxes (spam folder), recipients aren’t interested (over-notification), or notification content isn’t compelling (unclear subject lines, missing action guidance). Analyze read rates by notification type: alerts about work assignments should read higher than informational broadcasts, which should be expected to read lower.

Alert Fatigue and Notification Overload

Measure notification volume per user weekly: how many notifications does an average user receive? Most users tolerate just a few important notifications per day; beyond that, fatigue sets in and users stop reading. Users receiving 10+ notifications daily are at risk of tuning out entirely. Track distribution: are notifications concentrated on a few users (on-call support, managers) or broad (everyone gets alerts)? Broad notification distribution suggests alert thresholds are too low. To reduce alert fatigue, implement notification rules that suppress redundant or low-importance alerts: if an incident is already assigned to a user, don’t send repeated notifications about the same incident; if there are multiple low-priority incidents, aggregate them into one daily digest instead of separate notifications.

Notification Preference Compliance

Measure preference compliance: what percentage of users have opted into notifications versus opted out? Most organizations aim for the strong majority of users having notifications enabled. Users opting out suggests either notifications are overly aggressive or users don’t find them useful. Track preference changes: do users frequently change notification settings? Frequent changes suggest users are trying to find the right balance and haven’t found it. Analyze opt-outs: do certain user roles opt out more than others? For example, if managers opt out more often than support staff do, something about manager notifications is different (too many, not relevant, or wrong timing).

Notification Content and Actionability

Measure notification actionability: what percentage of notifications include actionable guidance (what does the user need to do)? Notifications like “Incident INC0123 assigned to you” are actionable; notifications like “System alert” are not. Actionable notifications drive action (users respond faster), while vague notifications confuse users. Review notification templates: do they include incident status, priority, summary of the problem, and who to contact? Notifications should include just enough detail to decide whether action is needed, without overwhelming users with information. A/B test notification content: send two versions of a notification to different user groups and measure which version drives faster response. Actionable, concise notifications typically drive significantly faster response times than generic notifications.

Notification Channel and Escalation

Measure notification delivery channel effectiveness: email is often the default channel, but some users prefer SMS (text messages), in-app alerts, or chat (Slack, Teams). Support multiple channels and respect user preferences: if a user opts for SMS for urgent alerts and email for routine updates, honor that. Track channel usage: what percentage of users use each channel? Measure the actual split rather than assuming it. Also measure escalation: if a user doesn’t respond to a notification within a time window (assignment not acknowledged within an agreed window), does an escalation notify the manager? Escalation patterns help identify patterns: are certain users frequently escalated (capacity problem) or certain incident types (maybe training needed)? Track escalation rates weekly to spot problems.

A metrics pack for notifications is only useful if it changes a decision. The notification concept page covers what each event produces, which is the starting point for any measure. Many packs fail that test. They list delivery counts, open rates and opt-out figures in the same table, with no note on which number should trigger a change and which one is simply context. The sections below look at the measures from the point of view of the person who has to explain them in a monthly review, and at the places where the numbers mislead.

Matching each measure to the decision it informs

Before adding a metric, name the decision it would change. A count of messages sent per rule informs whether a rule should be split, merged or retired. A rate of messages that reach a bounce state informs whether the address data needs cleaning. A measure of how long a recipient takes to act after an assignment informs whether the assignment reached a person who could act on it. If a measure does not map to a decision, it belongs in the appendix at most.

Building a baseline before anyone sets a target

A target set before a baseline exists is often a guess dressed as a commitment. Collect at least one full cycle of the normal process, including the quieter weeks, before discussing any threshold. Record the baseline with the conditions that produced it, such as a major incident in that period or a holiday that thinned the approver pool. Without that context, the next month’s figures will look like a change in performance when they are really a change in circumstances.

1. Choose the three measures that map to the decisions the review must make, borrowing the demand framing from capacity planning signals where volume is the question.
2. Extract them for the same window across at least one full business cycle.
3. Note any unusual event in that window beside the figures, not in a footnote.
4. Agree with the service owner which movement would trigger a conversation, and state the reason for that choice.
5. Review the thresholds once the first quarter of comparable data exists.

When the numbers disagree with the people using the system

A pack will sometimes show healthy delivery while the people who receive messages say they miss them. Treat that disagreement as information. Delivery logs confirm that a message left the platform, not that it was seen, understood or acted on. Check the subject lines and first lines of the affected template, and ask a sample of recipients what they expected the message to ask of them. A pack that shows delivery as the only measure will keep reporting success while the process quietly degrades.

Keeping the pack small enough to be read

A monthly review rarely has time for more than a handful of measures. Keep one page of headline measures, one page of exceptions, and a link to the raw data for anyone who wants to dig further. Reporting teams that have already worked through a reporting redesign often find the same layout works here. Each exception should name the rule, the change that was made, and the decision taken. Packs that grow each month without losing items tend to end in a meeting where nobody reads the table at all.

Which measure should a new owner look at first?

Start with the bounce and delivery-failure picture for the recipients the owner is responsible for. Address problems are the cheapest to fix, and they distort every other figure, so a clean delivery base makes the later measures easier to trust.

Can read rates be trusted for internal notifications?

Only partly. Opens depend on the mail client, and in-platform views depend on whether the recipient follows the link. Treat both as indicators of attention rather than proof of reading, and keep the definition fixed so that the trend means something.

How should a metric be retired?

Stop reporting it once the decision it served has been made or no longer applies. Record the date and the reason in the pack itself, so a future reader does not assume the measure was dropped by accident.

Who should own the pack?

The platform administrator should build and maintain it, and the service owner should be the person who reads it and decides. Where an organization has formalized its value realization operating model, the pack should feed that review directly. Splitting those roles keeps the numbers honest and the decisions accountable.