Blog
Set sales alert thresholds around the action they deserve
An alert earns attention when the receiving person has a useful action to take.
RevOps lowers the inactivity threshold from fourteen days to seven. The manager’s queue triples. More deals are visible, but the manager starts dismissing the alerts without opening the evidence. The rule is more sensitive and the operating process may be less useful.
Set an alert threshold around the action it should trigger and the consequences of being early, late or wrong. Then test whether the receiving team can review the resulting workload. A threshold is a business choice about attention. It should not be selected merely because a field can be filtered or another company uses the same number.
Begin with the intervention
Write what the recipient should do when the condition appears. “Review this opportunity” is broad. “Confirm whether the buyer’s agreed evaluation milestone still holds before the specialist reservation expires” gives the manager a decision and a reason for its timing.
Now ask whether the available evidence can identify that situation. An inactivity field may be a useful proxy, but it can miss work outside the connected record or flag an agreed waiting period. If the proxy is weak, improve the context or narrow the population before increasing notification volume.
Separate conditions that need a person immediately from those that belong in a periodic review. A missed customer commitment can merit a different route from a mildly incomplete field. Sending everything through the same channel makes the recipient perform the prioritization the workflow was supposed to help with.
Test the trade-off on a labeled set
Take a bounded set of historical cases from the intended motion. Ask a knowledgeable reviewer which ones would have justified the proposed intervention at the time. Preserve disagreements; hindsight and incomplete records can make these labels uncertain.
In a fictional set of 100 opportunities, reviewers identify 20 cases where a manager should have investigated an aging commitment. A seven-day rule flags 40, including 16 of those 20. It therefore surfaces 24 cases that the reviewers did not consider actionable and misses four that they did. A fourteen-day rule flags 18, including 12 actionable cases; it surfaces six nonactionable cases and misses eight.
The narrower rule produces a more concentrated queue but misses more useful interventions. The wider rule catches more while consuming more review time. Neither is automatically better. These figures illustrate the decision; they are not RevTech performance results or a recommended threshold.
If review takes an assumed five minutes per flag, the queues require about 200 and 90 minutes respectively. That estimate excludes deeper follow-through and should be checked against actual work. If the manager has only an hour available, neither design fits without changing the scope, cadence or receiving capacity.
| Rule | Flags | Actionable flagged | Nonactionable flagged | Actionable missed | Initial review at 5 min/flag |
|---|---|---|---|---|---|
| 7 days | 40 | 16 | 24 | 4 | 200 min |
| 14 days | 18 | 12 | 6 | 8 | 90 min |
Do not optimize the queue by hiding expensive cases
A false alarm on a low-consequence record is not equivalent to missing a time-sensitive customer commitment. Review the severity and available response time of missed cases, not just the proportion of flags judged useful.
Sometimes the answer is a second condition: distinguish an agreed pause from unexplained silence, or route a high-consequence commitment separately. Keep the logic understandable. A complicated scoring formula that nobody can challenge may make the queue feel more authoritative without making it more reliable.
Avoid tuning solely to historical examples until every case looks correct. Keep some representative cases for a later check and inspect new live exceptions under controlled scope. A rule that fits the past perfectly can depend on incidental details that do not persist.
Preserve the human reasons for resolving an alert
When an owner waives a flag, capture why. The customer may have confirmed a future date; the activity source may be incomplete; the rule may apply to the wrong motion. Those reasons support different changes.
Do not treat every waiver as a defect or every acceptance as proof of value. An owner can resolve a valid exception by confirming that no further action is appropriate. The useful measure is whether the alert supported the intended decision with proportionate effort.
Check the unflagged population periodically too. Reviewing only what the rule surfaced cannot reveal the cases it missed. Use a manageable sample and focus on the consequences the rule was designed to prevent.
Make the operating choice explicit
RevTech’s Sales Agent applies authored process and service-level rules to in-scope deals and routes exceptions with the rule and evidence attached. People resolve, waive or escalate those findings. The rule design and review capacity remain part of the customer’s operating responsibility.
For one noisy alert, document the intended intervention, eligible population, candidate thresholds, missed-case consequences and weekly review load. Choose the smallest design that supports the business decision, then revisit it when the motion or evidence changes. The objective is a queue managers can use thoughtfully, not the largest possible inventory of things that might be wrong.
Put the framework to work
See how the work gets done.
Explore how agents prepare work across your revenue teams, and how people review it, guide it and decide what happens next. Fictional data. Real product.
Explore the demo