Reporting your team actually trusts
Most businesses cannot answer basic questions about their own operation without asking three people and waiting a day. The problem is rarely the tool. It is that nobody ever agreed what the numbers mean.
In short
A number nobody trusts is worse than no number, because it moves the argument from the business to the spreadsheet. This defines each metric once in writing with a named owner, decides which system is authoritative for it, then automates the pull so the figure arrives without anybody assembling it. Reporting is a habit before it is a tool.
What we take on
Metric definitions
Every number written down once: what it counts, what it excludes, who owns it and how often it should move. Most reporting disputes turn out to be definition disputes wearing a data costume.
One source per number
Deciding which system is authoritative for each figure so two reports of the same thing stop disagreeing. Everything downstream reads from that one place rather than from whoever exported last.
Automated pulls
The figure arrives without anybody assembling it. Where a pull genuinely cannot be automated, the manual step is named and timed rather than quietly absorbed by whoever is closest to it.
Operating dashboards
A small number of screens answering the questions actually asked in the weekly meeting, rather than everything the tool is capable of plotting. Fewer charts, each of which changes a decision.
Reconciliation
Two records of the same thing compared and every difference explained. Standard practice in finance and almost absent everywhere else, which is why operational numbers get defended rather than trusted.
Reporting rhythm
Who looks at what, when, and what happens when a number moves. A report nobody opens on a schedule is a file, not a control.
Why most reporting projects end in a screen nobody opens
The usual sequence is backwards. Somebody buys a tool, connects it to whatever it will connect to, and builds the charts the data happens to allow rather than the ones the business needs. It looks impressive in the demo and gets opened twice.
Start from the questions instead. There are usually five or six that get asked out loud every week in the same meeting. How much is in flight. What is stuck and for how long. What did we finish. What is at risk. What did it cost. Everything beyond those is optional until those six are answered without anyone assembling anything.
Then define the terms, which is the unglamorous part and the part that carries the value. Two people saying active customer will mean different things, and neither discovers it until somebody senior asks why the number moved. A written definition with a named owner ends that permanently.
Only then does automation make sense. Automating the pull for a metric nobody agrees on distributes the disagreement faster and further. Once the definition holds, the pull is usually the easy part.
Watch for the figure that is technically correct and operationally useless. Average handling time across every ticket type tells you nothing. Split by type it tells you exactly where to look. Granularity is a judgment call worth making deliberately rather than accepting whatever the tool defaults to.
The measure of success is not how many dashboards exist at the end. It is whether the weekly meeting now starts from a shared picture instead of an argument about whose export is right.
Can you answer these six without asking anyone?
These are the questions that get asked out loud most weeks. Answer for how it really works on a Tuesday, not for what the system could theoretically produce if somebody built the report.
How to use it, about two minutes
- Answer for how it works on a TuesdayNot for what the system could theoretically produce if somebody built the report. The gap between those two is the finding.
- Check whether more than one person can produce the numbersIf the honest answer is one person, that is a dependency problem wearing a reporting costume, and buying a dashboard will not touch it.
- Fix definitions before buying anythingIf two systems disagree about the same figure and no one wins, a new tool makes the disagreement faster rather than smaller.
1. How much work is in flight right now?
2. What is stuck, and for how long has it been stuck?
3. What did we actually finish last week?
4. What is at risk of missing a date?
5. What did last month cost to deliver?
6. Where did the last ten customers come from?
Answerable without asking anyone
0 of 6
Answer the six to see where you stand.
What that means
A second opinion
Want to know which one to fix first?
Send this over and you get back which of the six is usually cheapest to close, what the definition behind it has to say, and where the number should come from. Your answers travel with it, so there is nothing to explain twice.
Goes to one inbox.
What this usually leads to
A reporting problem is usually a process problem wearing a costume. If numbers are hard to produce because the work is hard to follow, process automation fixes the cause rather than the symptom, and fractional operations is the version where somebody owns the numbers week to week instead of at quarter end.
Questions we get
We already have dashboards. Why would this be different?
Because the problem is usually upstream of the dashboard. If two people define the same metric differently, no amount of charting fixes it, and the screen becomes something people argue with rather than act on.
The first pass here is definitional, not visual. Once each number has one meaning, one owner and one authoritative source, the dashboard is comparatively trivial and people stop checking it against their own spreadsheet.
Which tools do you use?
Whatever you already have, wherever that is honest. Sheets and Looker Studio go a long way and cost nothing. Airtable, Metabase, Power BI and the reporting already built into your CRM or finance system are all fine.
The recommendation to move tools only comes when the current one genuinely cannot do the job, and it comes with the reason. Replacing a tool is a good way to spend a quarter without changing what anybody knows on a Monday.
How long before we see something?
The definitions and the question list come out of the first week, and they are usually the first time anyone has seen the business described that way.
A working first report follows within a few weeks depending on how many systems have to be reached and how cleanly they hand over data. Deliberately narrow at the start: one or two numbers that are right beat twenty that are approximately right.
Our data is messy. Is that a problem?
It is the normal starting condition and it is not a reason to wait. Messy usually means duplicates, missing fields and three conventions for the same thing, all of which are visible once you look.
What matters is deciding which mess to clean. Cleaning everything is a project with no end. Cleaning the fields that feed the six questions is a week.
Can you connect systems that do not have an API?
Often, through scheduled exports, email parsing or a browser level integration, and the reliability varies by how the system behaves.
Where a reliable automated route does not exist, that is said plainly and the step stays manual with an owner and a time attached to it. A manual step that everyone can see is safer than an automation that fails quietly.
Who maintains this after the engagement?
You do, and it is built to be maintainable by whoever is already there rather than by a specialist.
That means written definitions, named owners, plain configurations over clever ones, and a note on how to tell when a pull has broken. A reporting setup only one person understands has the same failure mode as the process it replaced.
Do you do machine learning or forecasting?
Not model building, and it is worth being direct about that. Training and deploying a model is a different discipline from the operations and AI adoption work here, and most businesses asking for it need reliable counting first.
What does happen: scoping whether a model is actually the right answer, running the arithmetic on whether it would pay back, and managing a specialist or your own data team through delivery. Simple forecasting from your own history, the kind that answers how much capacity next quarter needs, is ordinary reporting work and is included.
Can you gather data we do not currently have, through surveys or interviews?
Yes, where the missing information sits with people rather than in a system. Structured interviews with the people running a process, and short surveys with a specific decision attached, are part of how the measurement week works.
What is avoided is the survey sent to everybody that produces a deck of opinions and no decision. If the answer will not change what happens next, the question is not worth asking.
What is the smallest useful version of this?
One number, defined properly, pulled automatically, in front of the right person every week.
That sounds modest and it is usually the thing that changes the meeting, because it is the first figure in the business nobody has to caveat.
How does this fit with the automation and AI work?
It comes first, and that ordering is not arbitrary. Automating a process you cannot measure hides the mess inside a tool, and putting AI on top of it hides the mess twice.
Reporting is also how anything built afterwards gets judged. Without a baseline, an automation is evaluated on whether it feels better, which is not a standard anyone can defend.
More in the guides and every answer in one place.
Shaheer Shaikh, operations lead at LARVOL, a San Francisco AI company working with global pharma on clinical trial data and model benchmarking. Six Sigma on the process side, Anthropic certified on the Model Context Protocol, ten years across eight industries. More about the firm
Read next
The measurement this depends on, the work that usually follows it, and the terms used here.