What is exception reporting, and why is it better than a dashboard?
Exception reporting surfaces only what falls outside an expected range — a bookable call that never booked, a completed job that was never invoiced, a campaign whose cost per booked job doubled. It stays quiet the rest of the time. It beats a dashboard for daily use because it matches how busy operators consume information: by interruption, not by inspection. You still need periodic full review to catch slow drift.
The definition
An exception is a specific record or metric that violates a rule you declared in advance. Not "revenue is down" but "these eleven jobs completed more than four days ago and have no invoice." The output is a list you can work, not a number you have to interpret.
That specificity is what makes it usable. A dashboard tells you the invoicing lag is up. An exception report hands you the eleven jobs.
What earns exception status
Not everything unusual deserves to interrupt someone. Four conditions have to hold together.
- Someone owns it. An exception with no named owner is a notification, and notifications get muted.
- There is an action. If the only available response is to feel bad about it, it belongs in a weekly review, not an alert.
- The threshold is defensible. Derived from the metric's own normal variation, not a round number someone liked.
- It is rare. If a rule fires most days, it is not describing an exception — it is describing your baseline, and the baseline is the thing to fix.
Where it pays in home services
The highest-yield exceptions are almost always about work that already exists and is quietly leaking: unbooked calls that were genuinely bookable, estimates aging past the point where they close, jobs sitting completed-but-uninvoiced, memberships expiring without a renewal touch. These are recoverable within days. Marketing exceptions matter too, but the recovery window is longer.
Call analysis is what makes the first one possible — you cannot flag an unbooked bookable call unless something listened to the call and judged whether it was bookable.
The blind spot you have to design around
Exception reporting is bad at slow decay. A metric that erodes a little each week never trips a day-over-day threshold, and you can go a full quarter without a single alert while the business quietly gets worse.
The standard mitigation is a second, slower loop: keep the exception feed for daily work, and hold a monthly review of trend lines and channel economics where nothing is filtered. Analysis over a longer window catches what thresholds cannot.
Start with three rules, not thirty
The common implementation mistake is launching with a full catalog of exception rules on day one. Half of them fire constantly, people mute the channel, and the whole effort is discredited in a fortnight.
Pick the three leaks with the largest recoverable value — usually unbooked bookable calls, aging unsold estimates, and completed-but-uninvoiced work. Run only those for a month, tune the thresholds against what actually got acted on, and add the fourth rule only once the first three are consistently worked. Slow rollout is not caution here; it is how the thresholds get calibrated at all.
Topics: exception reporting · alerts · reporting design · operations
Have a version of this question about your own business?
The useful answer usually depends on which systems you run and how they're connected. That's a conversation, not a blog post.