How to Set Up Sales Dashboard Alerts That People Act On

Why Do Dashboards Need Alerts at All?

Because a dashboard only works on people who open it, and the problems worth catching happen between visits. A weekly forecast meeting reviews the state of the business every seven days. A commit deal pushing its close date on a Wednesday sits unnoticed for six of those days if nothing pushes it forward.

Alerts convert a pull system into a push system for a narrow set of events. That narrowness is the design constraint. A dashboard can hold thirty metrics because viewers choose what to read. An alert stream cannot, because it consumes attention the recipient did not volunteer.

The value is entirely about time. Catching a slipping quarter in week two leaves room to build pipeline, redirect SDR capacity, or pull forward a deal. Catching it in week eleven leaves room for an apology. Getting the forecast right at the end of the quarter helps nobody, since by then the quarter has already happened.

Which Events Deserve an Alert?

Five, and each one has to map to an action a specific person can take that week. If a notification fires and the recipient's honest response is that there is nothing to do, the rule is noise regardless of how interesting the event was. Close date movement leads the list because it is the strongest slippage signal available in a CRM. When a rep pushes a close date, that deal becomes less likely to close at all, and the effect holds even for deals sitting in commit. A slip from one quarter into the next is a materially different deal than it was the week before.

The quiet-opportunity alert covers the opposite failure. The earliest warning on a deal is often the absence of a signal rather than a bad one. Meaningful activity means a change in stage, close date, or amount, and a deal producing none of those is unattended rather than steady.

How Do You Set the Thresholds?

From your own historical distributions, not from a rule of thumb. A threshold copied from an article will fire constantly at one company and never at another, and both outcomes teach people to ignore the system.

For aging, look at how long deals actually take to close in your business. ORM applies a twelve-month rule for most customers, and groups each opportunity with a machine learning model that predicts a close curve for that group. Those curves span one to eighty weeks, with most of the expected closing happening before week twelve and very few groups showing meaningful expectation past week fifty-two. Your own distribution should set the aging alert, and it will differ by segment.

For coverage, use the band your segments actually operate in. Standard coverage sits between 3x and 5x, and across ORM's customer base the typical company lands near 3.5x, with real companies ranging from 1.4x to 5x. Setting one floor across every segment guarantees false alarms in the segment that converts well and silence in the one that does not. See pipeline coverage for how to calculate the ratio by segment.

Tune by iteration. Set an initial threshold, run it silently for two weeks, count how many alerts it would have produced, and adjust until the volume fits the recipient's capacity.

How Many Alerts Can a Person Absorb?

Set a weekly cap per recipient before you write the rules, and tune thresholds until volume fits inside it. A sales manager absorbs more than an executive does, and past whatever cap you set, recipients stop reading. An unread alert stream is worse than no alerts because it creates a false sense that problems are being caught.

The cap is what disciplines the thresholds. If your slippage rule generates 40 alerts a week for one manager, the rule is too loose or the pipeline has a structural problem that alerting cannot solve. Both conclusions are useful, and both are hidden if you ship the rule and hope people cope.

Rank when volume exceeds the cap rather than truncating arbitrarily. Sort by dollars at risk and send as many as the cap allows, with a line noting how many fell below the cut and a link to the full list. Recipients then know the stream is a priority queue instead of a random sample.

Where Should Alerts Be Delivered?

In the tool the recipient already has open, which is usually Slack or email. An alert that lives inside the dashboard has failed at the only job alerts do, which is reaching someone who was not looking.

Match the channel to the urgency. Deal-level alerts to a rep or manager belong in Slack, where a short message with a CRM link fits the workflow. Coverage and forecast alerts to leadership belong in email, where they can sit alongside the weekly summary and get read during a planned review rather than mid-call.

Include enough context to act without opening anything. Deal name, amount, owner, what changed, the previous value, and a direct link. An alert reading "3 deals changed close date" forces a click before the recipient knows whether it matters, and that click is where most alert systems lose their audience.

Should Alerts Be Real Time or Batched?

Batched, for nearly every revenue use case. Real-time alerting fits systems where a minute of delay carries cost. A deal that slipped at 2pm does not need to be known at 2:01pm, and pretending otherwise trains people to mute the channel.

A daily digest at a fixed hour works best. Deal-level changes accumulate through the day, get grouped by owner, and arrive as one message each morning. Managers can then work the list as a queue instead of context-switching eleven times.

Coverage and forecast alerts fit a weekly cadence tied to the operating rhythm, delivered the evening before the forecast call. That timing gives the recipient a night to prepare rather than surfacing a surprise in the meeting.

Seasonality argues for batching too. B2B SaaS quarters have a shape, with Q2 and Q4 typically stronger than Q1 and Q3, and the third month of a quarter typically stronger than the first two. Real-time alerts on a normal slow first month generate alarm about a pattern that repeats every year.

How Do You Know the Alerts Are Working?

Measure the share of alerts that produce a logged action within five business days. Volume and open rates say nothing about behavior. Action rate is the only number that distinguishes a working rule from a decorated one.

Set your own floor for action rate when you launch the rule, then retune or retire anything that falls under it. Retuning usually means tightening the threshold so fewer, larger cases fire. Retiring is a legitimate outcome, and a system with three high-action rules beats one with twelve that everyone filters into a folder.

Review the rule set quarterly alongside the dashboards themselves. Business changes shift which events matter, and an alert built for last year's problem keeps firing on a question nobody is asking. For the wider diagnostic frame these alerts feed into, see deal slippage and sales forecasting best practices.