How do you get numbers in front of people who will never open a dashboard?

Push beats pull for anyone who is not an analyst

Analysts pull. They open tools, explore, and enjoy it. Almost nobody else in a service business works that way. A dispatcher, a technician, a CSR supervisor and an owner are all interrupt-driven, and none of them will build a habit around a browser tab.

The practical consequence is that the delivery mechanism is part of the product, not an afterthought. A mediocre metric that arrives in front of the right person beats an excellent one behind a login.

It also changes what you build. If the delivery target is a text message, the metric has to be reducible to one sentence with one name and one action attached. That constraint improves the metric, because anything that cannot survive it was probably not decision-grade to begin with.

Match the format to the role

• Field manager. A short mobile message with one exception and one name. Anything longer is read while driving, which means not read.
• Call center supervisor. A live number in the tool they already watch, plus a queue of specific calls to review.
• Owner. A morning brief in email, a handful of lines, written prose rather than a chart pack.
• Marketing. A weekly summary with drill links, because this is the one audience that will actually click through into the detail.

Send changes and exceptions, hold the levels

Levels belong on a dashboard people consult when they have a question. Pushed messages should contain only what is different from expected, because push spends attention and attention is finite. A daily message repeating yesterday's revenue trains people to stop reading; a daily message that only appears when something moved keeps its power.

This is the same discipline as alert design, applied to routine communication. The brief is the exception report with a narrative around it.

Keep a path back to the detail in every pushed message. Exceptions without a way to see the underlying records force a second request to someone else, and that round trip is where the response usually stops.

The engineering is routing, not reporting

None of this requires a second reporting stack. It is one metric layer with several delivery channels attached: email, SMS, a task written back into the CRM or field service system, a panel embedded where work happens. The metric is defined once, and the routing decides who sees what.

Writing back into operational systems is where most of the effort goes, and it is the part that makes the difference. That work is standard API integration, and it is why we treat delivery as an integration problem rather than a dashboard problem.