At Meraki, a children's language school we build software for, the people who act on data are not analysts. They are parents checking whether their child practiced this week, teachers deciding who needs help, and administrators deciding which groups to open next term. Each of them needs a different number, at a different time, in a different place.
That is the problem most data projects skip. Companies collect plenty of data. What they lack is a short list of numbers tied to decisions, each one shown to the person who makes that decision.
This post covers how to choose those numbers, where they should come from, and how to deliver them. If you are deciding between a dashboard and a report, our post on dashboards vs. reports covers that part.
Start from the decision, not the data
The usual first step is "let's see what we have". It produces charts nobody opens after the second week. Start the other way round:
List the decisions your team makes every week or month: which leads to call, which customers to chase for payment, which product line to push, when to hire.
For each decision, name the person who makes it and when.
Ask what number would change their mind. If no number would, that decision does not need data.
Only then find the data that produces that number.
Most companies end up with 5 to 10 numbers that matter. If your list has 40, most of them are there because they were easy to collect.
Leading and lagging numbers
Revenue, churn and profit are lagging numbers: by the time they move, the cause happened weeks ago. They tell you whether you are winning. They do not tell you what to do on Monday.
Leading numbers move first and point to an action. A few examples:
| Lagging number | Leading number to watch | Action it triggers |
|---|---|---|
| Monthly churn | Customers who stopped logging in for 14 days | Account manager calls them |
| Revenue | Quotes sent and not answered after 7 days | Follow-up |
| Late payments | Invoices due in the next 10 days, by customer history | Reminder before the due date |
| Student results | Exercises not practiced this week | Teacher or parent nudge |
Pair each lagging number with at least one leading number. The leading one goes in front of the person who can act. The lagging one goes in the monthly review.
Where the numbers come from
A number is only useful if people trust it. Trust breaks in predictable places:
Two systems, two answers. Billing says 412 active customers, the CRM says 437. Pick one source of truth per number and say which in the dashboard.
Manual exports. A spreadsheet rebuilt by hand every Friday is stale by Monday and wrong after the first copy-paste error.
Definitions nobody wrote down. Is an "active customer" one who paid this month or one who logged in? Write the definition next to the number.
Data entered for the report, not the work. If staff fill in a field only so a chart works, the field will be empty or guessed.
The fix is usually not a data warehouse. It is making sure the system where the work happens records the event once, with a timestamp, and that every number is calculated from those records. If that system is a patchwork of tools, the cost of fixing it is part of the decision; our post on when custom software pays back covers that.
What this looks like at Meraki
Meraki runs lessons, voice exercises with AI pronunciation scoring, subscriptions and a front desk in one platform we built on Laravel, React and Electron, with a team of 3. Since September 2025 it has recorded 150,000+ sessions and 46,000+ hours of learning for 2,600+ students.
Because every lesson, exercise and payment is recorded where it happens, each audience gets its own numbers without a separate reporting project:
Parents see their child's progress and practice.
Teachers follow progress across their groups.
Administrators track subscriptions, dues and discounts, and can ask questions in plain language. We built an MCP server, available only to super-admins over OAuth, so they can query and run the school from Claude instead of waiting for a new report.
The full project is in the Meraki case study. The lesson we took from it: when the data is recorded cleanly at the source, the dashboards are the cheap part.
Getting the numbers in front of people
A number nobody sees changes nothing. Match the delivery to the decision:
Inside the tool where the work happens. The overdue-invoice count belongs on the finance screen, not in a separate BI tool.
As an alert, when there is one action. "3 quotes unanswered for 7 days" works better as a message than as a chart.
As a weekly or monthly summary for lagging numbers and trends.
As a question you can ask. For managers who need ad-hoc answers, a plain-language interface over your own data often beats one more dashboard. We cover what is realistic in adding AI to an existing platform.
We run our own marketing this way. Search, analytics and site-speed numbers are collected into our internal system daily, and a weekly check flags only what changed by more than 30%. Nobody has to open four dashboards on Monday.
What it costs, and when not to build
If your data already sits in one or two well-run systems, you may not need custom work at all. Most SaaS tools have reports, and a BI tool connected to them can be enough.
Custom work pays when the numbers you need span systems that do not talk to each other, when the events are not recorded at all today, or when the people who need the numbers work inside a platform you already run. In that case the cost depends on how many sources you connect and how clean they are, not on the number of charts. We check both in a short discovery before quoting.
Next step
Write down the 5 decisions your team makes most often and who makes them. Bring that list to an intro call and we will tell you which numbers matter, where they should come from, and whether you need us at all. Book an intro call.