How many alerts is too many?

A big challenge in building software for work is how to handle alerts. Of course, the pilot needs to urgently know when another plane is in the flight path.

But the allure of automating warnings quickly becomes a trap. If it’s trivial to add an alert, why not have an alert for this common issue, that one that happens once a month, and while we’re at it those once a year edge cases too. When a mistake happens, everyone says hey we should add an alert, that would save us next time. But now there are 200 alerts and no one checks them out because most are false anyway and it would take all day. This is worse than when there was only 1 alarm.

The solution to noise is prioritization. Categorize alerts into critical, important, and merely interesting. This covers more ground than the critical-only system and helps the user triage. 

This is naive about the reality of most work: we are all using several if not dozens of pieces of software. A neat hierarchy of color warning icons doesn’t help much if the user doesn’t see it. Once again the prioritization problem has been shifted back to the user. 

It’s an easy mistake as a product manager to think only about what the user is trying to do in your application. The reality is your app is just one part of an ecosystem of activities they’re managing. “Meet with VP” is far higher on their actual to-do list than review “card on file expires soon” alerts. 

Designing an effective alert system requires understanding the entire workflow and where your software fits in. Some teams live in email; others largely use Slack and never check email.

Principles for alerts:

• Meet the user where they are. If users actual to-do lists are in Airtable, build an integration for critical-only alerts to automatically create an Airtable task. Make it as easy as possible to go from alert to action.

• Find the right delivery method for each alert level. For important but non-critical events, a Slack message to a shared channel might be the most effective method.

• Treat critical alerts as actually critical. If the building is on fire, don’t just put up a bell in the app. Send a text and a Slack and an email to the whole team.

• Give users tools to triage, act, and dismiss.

• Learn from their triage. Let users snooze or mark alerts as never relevant. Use this as inputs to improve the alert system. Consider removing or adjusting alerts that are always snoozed.  

Simple prioritization combined with flexible, calibrated delivery is the ideal state. It allows for wide coverage of issues while making it easy for the user to figure out what they actually need to pay attention to.