Alert fatigue is a design problem, not a discipline problem

Every sales leader has lived this scene. You wire up lead alerts, buying-signal notifications, a Slack channel that pings the moment something looks hot. For a week the team is electric. Then the pings keep coming, and six weeks later nobody reads the alerts anymore. A real opportunity landed on Tuesday and sat untouched until Friday.

The usual diagnosis is a people problem. The reps lack discipline. They should check the channel. They should treat every ping like it matters.

There is a whole field of research that disagrees, and it does not come from sales. It comes from hospitals and security operations centres, where the most disciplined professionals on earth started ignoring alerts anyway. The cause was not laziness. It was the alerting system. Alert fatigue is what happens when a notification system trains its own users to tune out, and the fix is not better behaviour. It is better design.

Where the term comes from: hospitals that learned their alerts were the problem

"Alert fatigue" entered the vocabulary through clinical decision support: the medication warnings and notifications inside electronic health records. The U.S. Agency for Healthcare Research and Quality defines it as busy clinicians becoming "desensitized to safety alerts, and as a result ignore or fail to respond appropriately to such warnings," typically because the sheer volume of alerts is compounded by the fact that the vast majority are clinically inconsequential.

The numbers are stark. A 2009 study in the Archives of Internal Medicine examined 233,537 medication alerts shown to 2,872 clinicians and found they overrode more than 90% of drug-interaction alerts and 77% of drug-allergy alerts. The authors concluded the alerts had become "more of a nuisance than an asset," and their recommendations were not about training doctors to click more carefully. They recommended design fixes: reclassify severity levels, suppress repeat alerts, customise by specialty.

The best evidence that this is a design problem rather than a discipline problem comes from a 2017 study by Ancker and colleagues across 112 primary-care physicians. Reminder acceptance fell by 30% for each additional reminder shown per patient encounter, and by 10% for every 5-point increase in repeated reminders. The striking part: fatigue was driven by the proportion of uninformative alerts, not by total workload. Busy doctors did not ignore more alerts than less busy ones. Change the mix of alerts, not the people.

Security teams caught the same disease

If you want a closer cousin to a sales team drowning in signals, look at a security operations centre. The pattern is identical, only the stakes are higher and the numbers are louder.

A 2023 Sapio Research survey commissioned by Vectra AI found the average SOC team faced 4,484 alerts per day. 67% of those daily alerts went undealt with. 83% of analysts said the alerts were false positives not worth their time, and 97% worried about missing a genuine event buried in the flood. Treat these numbers with caution: a vendor-commissioned survey, self-reported. Cisco's 2020 CISO Benchmark, surveying 2,800 security leaders, found 42% suffered from what it called "cybersecurity fatigue," described as virtually giving up on proactively investigating alerts.

These were professionals whose job is literally to investigate alerts, and the system defeated them anyway. Volume without triage produces surrender.

The fix that worked was never more discipline. It was tiering.

Nobody fixed alert fatigue by telling clinicians to pay more attention. They redesigned the alerts: interrupt rarely, and only for what is critical.

The strongest example comes from a deployment across 31 Boston-area ambulatory practices. The team tiered drug alerts so that only critical, high-severity interactions fired as interruptive popups. Only 29% of alerts remained interruptive, and clinicians accepted 67% of those. Compare that with the untiered baseline: over 90% overridden. Same clinicians, same kind of alerts. The only thing that changed was the design, and the interruptive tier went from being ignored almost entirely to being accepted two times out of three.

Converting an older system to tiered alerts raised top-tier acceptance from 34% to 100%. And a national quality-improvement programme at the U.S. Veterans Health Administration restricted the list of mandatory notification types from 15 down to 10, cutting mean daily notifications per primary-care physician from 128 to 116 and saving roughly an hour and a half per physician per week.

The canonical design checklist behind these results is the "Five Rights" framework from clinical decision support: the right information, to the right person, in the right format, through the right channel, at the right time in the workflow. Every alerting rule has to answer the format and channel questions explicitly: only a genuinely dangerous interaction earns an interruptive hard stop.

Software teams converged on the same pattern. Amazon's architecture guidance separates critical events, which go out immediately and unbatched, from informational events, which are collected into grouped summaries. Practitioners running reply notifications for sales teams describe the same shape: an immediate ping only for replies containing buying signals, digests for everything else. One put the rationale in a single line: forty pings a day will train the team to ignore the channel within two weeks.

Sales teams have the same disease, minus the published numbers

Here is the honest gap: there is no published study quantifying how often sales reps ignore CRM or buying-signal notifications. The sales evidence base measures something adjacent instead. The classic XANT lead-response research, vendor-authored but widely replicated in spirit, found that contacting a lead within five minutes versus thirty minutes multiplied the odds of making contact by 100x and the odds of qualifying the lead by 21x. Speed matters enormously, which means a hot signal sitting unread in a muted channel is the most expensive kind of miss.

Practitioners have named the mechanism directly. A 2026 buying-signals guide from Tapistro puts it bluntly: treating every signal as a buying signal is "the single fastest way to teach a sales development team to ignore alerts." The disease is the same one hospitals and SOCs documented. The treatment should be the same too: tier ruthlessly, interrupt only for what is critical and actionable, and batch the rest.

How we designed Open Pulse's alerts so people actually read them

Open Pulse exists to surface buying signals from public conversations, and every signal we surface is a candidate for interrupting someone's day. If we ping for everything, we become the noise. So the alerting design makes three commitments.

Commitment one: urgency alerts are a narrow tier, not the default. They are off until a workspace turns them on, and when it does, the default rule fires an alert only for a signal scoring 85 or above out of 100 whose urgency is immediate or high. That bar sits well above the score of 55 a listener uses by default to decide what to keep at all, so the interruptive tier is a small fraction of everything the system finds. The threshold is a setting rather than a constant, but it is one number and two checkboxes rather than a rule builder, because a rule builder is what people configure once and never open again.

Commitment two: a hard daily cap. The default is five urgency alerts per day, workspace-wide rather than per listener, counted against the UTC day. If more than five qualify, the highest-scoring ones go out and the rest are dropped with a line in the run log saying how many. We could not find a documented example of a hard daily cap on alerts anywhere in the research behind this article, so we could not cite the practice and built it anyway. A cap is the one design choice that makes the tiering promise enforceable: even on a day when the market is loud, your team will never wake up to a flooded channel.

Commitment three: every alert that misfires is treated as a bug. Rating a signal with a thumbs up or down calibrates future classification for that listener. Rejected candidates are kept with the reason they were rejected for 14 days, which is what makes a quiet week diagnosable rather than a guess, and a query that produces candidates but never a kept signal in three consecutive runs is automatically disabled and reported, instead of pinging forever about nothing. Incident-response culture has a rule worth stealing: every alert that fires and turns out not to require action is a defect in the alerting configuration. We run the product that way.

The urgency alert tier is included from the Go plan upward, and custom alert rules on top of it are a Pro and Enterprise feature. But the pricing detail is less important than the design principle, which applies to any alerting system: count how many alerts each person gets per day, decide explicitly which tier earns an interruption, cap the top tier, and treat everything people ignore as a defect in your configuration rather than a defect in your people.

What to do this week

If your team has stopped reading its alerts, resist the stern message about discipline. Run this audit instead.

1. Count. How many alerts does each rep receive per day, across every tool and channel? If you cannot answer that, you are flying blind on the single variable the research says matters most.
2. Tier. Decide which signals are genuinely time-critical and actionable within the hour, and restrict interruptions to those. Everything else becomes a digest.
3. Cap. Pick a number of interruptions per day that a human can act on, and enforce it. When more signals qualify than the cap allows, send only the best.
4. Close the loop. Every alert your team ignored is data about your alerting configuration, not a performance review. Ask why it did not earn a response, and change the rule.

Alert fatigue was named by hospitals and measured in security operations centres. Everywhere it was studied, the cure was the same: fewer, better alerts, delivered through the right channel at the right time. Your team was never the problem. The pings were.

Run the free Open Pulse report to see which buying signals deserved a ping this week, and which never did.

References

• Isaac et al., "Overrides of Medication Alerts in Ambulatory Care", Archives of Internal Medicine, February 2009.
• Ancker et al., "Effects of workload, work complexity, and repeated alerts on alert fatigue in a clinical decision support system", BMC Medical Informatics and Decision Making, April 2017.
• Shah et al., "Impact of a national QI programme on reducing electronic health record notifications to clinicians", BMJ Quality and Safety, 2019 (AHRQ PSNet summary).
• "Improving Override Rates for Computerized Prescribing Alerts in Ambulatory Care", the tiered alerting deployment across 31 Boston practices.
• EHR alert tiering conversion study, Tier 1 acceptance 34% to 100%.
• Osheroff et al., the CDS "Five Rights" framework.
• Vectra AI / Sapio Research, "State of Threat Detection and Response" (vendor-commissioned survey), reported by Help Net Security, 20 July 2023.
• Cisco 6th Annual CISO Benchmark Report (n=2,800), 2020, reported by TechMonitor.
• AWS Architecture Blog, "Prioritize your AWS Health alerts using AWS User Notifications", 2026.
• XANT / InsideSales.com, "Lead Response Management Study" (vendor-authored), 2012.
• Tapistro, "Buying Signals in Sales: The Complete 2026 Guide" (vendor blog).
• Momentum.io, "What Tools Provide AI-Driven Sales Alerts and Signals?" (vendor blog), 2025.
• Scratchpad, "RevOps Slack automations" (vendor blog).
• Sunshine et al., "Crying Wolf: An Empirical Study of SSL Warning Effectiveness", USENIX Security 2009.