Before learning how configuration and options work with Smart Alerts, it is important to consider a successful strategy as it relates to email alerts in general. Using a bad strategy will cause a negative user impact and may lead users to ignore emails and otherwise not use the system as expected.
As you plan your email alerts, consider the best approach and how your users will best be able to leverage these emails.
The Twelve Commandments of Email Alerts:
- Do not bombard your users with emails. Very quickly all of the tool's emails will be ignored. Less is more!
- Do not dump all of the record information in the email. Your users do not want to read long emails. This is another way to bombard the users with information. The result is ignored emails - see #1.
- Do not copy many people all together on email alerts. This leads to the same effect as #1. Be sure the alert goes only to the critical relevant users.
- Do provide the key message in the subject line. If possible, the user should understand why they received an email from the subject line only.
- Do provide a link to the SharePoint list record as the first or last line of the email alert. Email alerts usually are intended to prompt the user to take a look at the current information in SharePoint and interact with the live data in the tool.
- Do include the name of the tool in parenthesis at the beginning of the subject line. Users can make a rule to automatically store these emails in a specific folder. For example "Project Tracking Tool" could have a subject line that begins "(PTT)".
- Do include the unique identifier (such as Project ID) for the record in the subject line.
- Do include critical measurements in the email such as days late, spending, project status etc.
- Do include the name of the person in the alert who triggered the alert through their action. i.e. "John Smith changed Project Status to Hold."
- Do use font colors and highlighting to call out important information, especially in critical messages. Most emails don't include this formatting. This is a a great way to make important information stand out.
- Do provide a link for users to contact you in regard to email alerts. They may want changes to the alert rules to better match their needs.
- Do provide instructions in the email such as WHO should next take action WHY the email alert was triggered, WHAT should next take place, and WHEN the action should take place.
Email Alerts Strategy
What should your email alert accomplish?
Your strategy should change according to the goals of the system.
Stalled Action
It is common for a user to be unresponsive in a workflow or approval process. This is especially problematic in a situation that requires sequential approval or in a situation where the process cannot proceed without a single user's action.
It is easy enough to set up an email "nag alert" to prompt the user for action, but this likely will not work.
One effective approach is what can be playfully called "public shaming".
Instead of sending the nag alert to only the person who is late in taking action, copy impacted users as well.
- To: User who is holding up the process
- Copy Impacted users and "important people" such as managers.
- Email content: Highlight the late information in red such as "14 days late".
- Highlight the user's name in bold with a call for action: "John Smith should review content and provide signature."
- If possible, describe the consequence for no action: "After 30 days, stalled projects are escalated to the Engineering Director"
The intended effect is to cause some embarrasment to the user who would otherwise continue to ignore their responsibility.
As the saying goes, "The squeeky wheel gets the grease".
It's obvious to users that these are system generated message, but by using the above strategy, the process can no longer be ignored.
Experiment with the message. In one situation changing the strategy triggered a complete turn around from emails that were almost always ignored to emails that triggered an almost immediate response each time!
Status Changed
Users often need to know when the status changes on a project. Keep these emails short and sweet.
[Project Name] status has changed to [Status].
Access your project here.
Approval Given
When an approval is given, be sure to notify the user who requested the approval and the person who next needs to take action.
[Project Name] has been approved by [Approver].
[Requestor] should change the project status to "In Progress".
Access your project here.
Project Closed
Most users are happy to know when a project is complete. Keep the message short and to the point.
[Project Name] has been marked complete!
Access your project here.
Negative Condition
Often managers don't want to be dragged through all the granular information that is tracked in a system, but they DO need to know when certain negative conditions arise. New systems should never allow important information to "fall through the cracks". Email alerts should always be triggered when something negative and unexpected has occurred.
[Project Name] status has changed to HOLD.
Please review the project to provide necessary information.
Access your project here.
There is a surprising amount to consider when it relates to the strategy of email alerts. Too often this area is skipped over leading to a badly implemented email alert system. Weigh your strategy carefully and be sure that you are not merely "dumping information" on users which lead to emails being ignored or even worse to the overall tool being considered an annoyance and also ignored.
