System Notifications Best Practices

[Allison DeTitt1]

May anyone please share how they go about system notifications best practices? E.g., when to notify, formatting of notifications - anything you feel is worth noting when thinking about notifications strategically (for both front and back end users)? Thank you!

[AmM01]

The first thing that comes to mind is making sure we don’t overwhelm either agents or customers with a flood of emails. It’s easy for important info to get lost if we overdo it. In some cases, it’s actually better to use portal notifications (like the little bell icon), especially when users are actively working in the system.

In terms of formatting, it honestly depends on the client. Usually, the CX/UX team steps in to handle the look and feel of the notifications so they align with the overall experience.

Reminder notifications are definitely useful too, but the timing (how many days before or after something happens) should be based on what makes sense for the client and their processes.

Also, the tone and language should match the audience, something clear and simple for customers, and maybe more detailed for internal agents.

One last tip: always include a direct link in the message so customers can easily jump to the portal, and agents can get straight into Workspace or the native view to take action.

[swapnali ombale]

@Allison DeTitt1 

In ServiceNow, best practices for system notifications include being selective, personalizing messages, monitoring performance, and avoiding notifying those who initiated the action, while also ensuring proper email address management and utilizing email templates for consistency. 

Here's a more detailed breakdown of ServiceNow system notification best practices:

1. Be Selective and Avoid Over-Notification:

• Only send relevant notifications:

  Focus on notifying users about truly important updates, not every minor change.
• Prevent user overload:

  Too many notifications can lead to users ignoring them, so be strategic about which notifications are sent. 

2. Personalize Notifications:

• Use dynamic fields:

  Make notifications more relevant and actionable by incorporating dynamic fields and user-specific information. 
• Consider the user:

  Tailor notifications to the recipient's role, language, and technical/business experience. 

3. Monitor and Adjust:

• Regularly review settings:

  Periodically review and adjust notification settings based on user feedback and system performance. 
• Gather user feedback:

  Conduct surveys or engage with users to understand their notification preferences. 

4. Notification Trigger Best Practices:

• Don't notify the initiator:

  Avoid notifying the person who initiated the action or made the change in the first place. 
• Use events for notifications:

  Trigger notifications based on events in workflows, rather than embedding them directly within the workflow. 

5. Email Address Management:

• Use your own company address:

  Never expose a <company>@servicenow.com address to users; always use your own company email address that routes to the ServiceNow address. 
• Manage email preferences:

  Allow users to manage their notification preferences and ensure they receive notifications on the desired email address and/or device. 

6. Utilize Email Templates:

• Create reusable content: Use email templates (sysevent\_email\_template) to create reusable content for subject lines and message bodies, ensuring consistency.
• Use mail scripts: Define a mail script to use a standard style for all notifications. 

If my response helped please mark it correct and close the thread so that it benefits future readers.

[jeffreyluto]

I championed the "Mention" or the "@" notification to be setup in our environments. In case others start to use it and assume it's sending notifications on Work notes or other.

Set notification on the Mid Server because one of the apps can query the mid on schedule and email the App or System admin that's it down - in addition to whatever Data center monitoring you have.

I also set up Notifications in Security ctr in addition to external app log analysis.

Of course we have other standards ones related to Change and Incident