Back to Field Notes

DESIGN · BLOG

Designing alerts people actually want

Most product alerts feel like smoke alarms during dinner loud, late, and impossible to ignore. We spent six months rebuilding ours from scratch. Open rates went up. Complaints disappeared.

Donna Wilson

6 Min Read

For a long time, our alert system operated on a very sophisticated philosophy: if something happens, notify everyone immediately. CPU spike? Alert. Usage dip? Alert. Somebody renamed a dashboard? Somehow also an alert. By early 2025, half the company had trained themselves to ignore notifications entirely, which is impressive considering the notifications were theoretically important.

The problem with “real-time”

The original logic sounded reasonable. Teams wanted visibility. Customers wanted transparency. Engineers wanted fewer surprises. The result was a firehose.

The average enterprise customer received forty-three alerts per week. Most of them required no action whatsoever.

Eventually we realized we’d confused activity with urgency.

A billing export finishing successfully does not need to interrupt someone’s lunch.

Neither does a dashboard refresh.

The irony was that the truly important alerts — outages, failed syncs, suspicious API spikes — got buried under a pile of informational noise. Users weren’t ignoring alerts because they didn’t care. They were ignoring them because we’d taught them nothing mattered.

What we changed

We rebuilt alerts around one question:

“What action should happen because of this notification?”

If the answer was “nothing,” the alert probably didn’t deserve to exist.

We split notifications into three categories:

  • Awareness

  • Action required

  • Critical interruption

Only the last category can bypass notification batching.

Everything else gets grouped into scheduled summaries delivered twice daily. Customers can still opt into real-time delivery, but surprisingly few do.

We also added something painfully obvious in hindsight: alert previews written by humans instead of systems.

“Usage anomaly detected in Segment 4A” became:

“Traffic dropped 18% compared to your normal Tuesday baseline.”

People started understanding alerts instantly.

The metric we cared about

We didn’t optimize for click-through rate.

We optimized for trust.

If users believe every alert matters, they read them.

If they believe half are useless, eventually they stop reading all of them.

Three months after the rollout:

One unexpected outcome

Support tickets dropped.

Not because customers were getting fewer notifications, but because they finally understood the ones they received.

Turns out clarity scales better than volume.

What we’d still improve

We still haven’t solved personalization properly.

Different teams define “urgent” differently. Finance teams want precision. Ops teams want speed. Founders want existential dread delivered immediately.

We’re working on adaptive alert profiles now — systems that learn which alerts people actually engage with instead of forcing everyone into the same settings panel nobody opens.

The goal isn’t fewer notifications.

It’s fewer useless ones.


Donna Wilson

Head of Sales, Metrify

Covers analytics workflows, dashboard design and decision-making at scale. Former data lead at a fast-growing fintech company.

Read More

Get Started Today

Own the customer.
Own the growth.

Turn every signal into a decision and every decision into revenue.

Create a free website with Framer, the website builder loved by startups, designers and agencies.