A national sales team will keep its own spreadsheet next to an official report for exactly one reason: the official report doesn't answer the question they're actually being asked. Fix that, and the shadow spreadsheet disappears on its own. Nobody has to be told to stop using it.
That's the pattern behind a reporting suite I built and supported for roughly four years with an agribusiness client, working across production, finance, sales, research, inventory and supply forecasting. The part that ended up mattering most wasn't the reporting itself. It was what happened once the sales team, eventually around 20 to 30 people using it actively across the country, started trusting the numbers enough to correct them.
Trust was earned in ordinary moments. A representative could check a number before speaking with a customer, see where it came from and raise a problem when it did not match what they knew. The reporting improved because the people closest to the work had a reason to participate in it.
The problem before the reporting existed
Like a lot of businesses that have grown through separate systems and separate teams, this one had significant manual reporting effort, limited visibility across departments, and information fragmented across systems that didn't talk to each other. Production knew what it produced. Finance knew what had been invoiced. Sales knew what they'd sold, or thought they had. Nobody had one number everyone agreed on.
That's an expensive problem, but it's a familiar one. Most growing agribusinesses and production businesses hit it at some point. The interesting part isn't the diagnosis. It's what changes once you fix it properly.
Shadow spreadsheets usually contain a requirement
It is easy to treat a local spreadsheet as resistance to change. Often it contains something the official report never supplied: a customer grouping, a forward view, a note about an exception or a comparison aligned to the way the team is measured. Removing the file without understanding that job removes the user's answer, not the need for it.
Sit with the user and follow the spreadsheet from input to decision. Which columns do they add? Which filters do they use before a call? What do they compare, and what action follows? Some local steps should be retired because they correct preventable data problems. Others belong in the shared reporting because they express a real business question.
Building the reporting was the easy part
Over the course of the engagement, the work covered ETL processes bringing data together from across the business, Power BI reporting across finance (general ledger, profit and loss, balance sheet), production and inventory visibility, and supply and demand forecasting. Power Apps and workflow automation supported some of the operational processes underneath the reporting.
None of that is unusual work for a BI engagement. Most competent reporting builds can get the numbers into a dashboard. The harder problem, and the one that determines whether the work was worth doing, is whether anyone changes their behaviour because of it.
Definitions need to survive contact with the work
Shared reporting requires shared definitions, but those definitions cannot be imposed from a data model alone. Sales, finance, production and inventory may each use the same word for a different stage of the process. An order, a sale, a forecast and available stock can all look obvious until one customer changes timing or one product moves through an unusual path.
Work through those cases before asking users to trust the total. Record what the measure includes, when it updates and who resolves exceptions. When a number changes after a correction, explain why. Consistency over time builds more confidence than a dashboard that looks finished on launch day.
What made the sales reporting suite different
The sales reporting suite became the standout piece of the engagement, not because it was the most technically complex, but because it got used. The national sales team adopted it, with roughly 20 to 30 active users engaging with it regularly. That is a sustained pattern of people choosing to open a report because it helped them.
Three things drove that, in this order:
It answered the question the user actually had. Sales reporting that shows revenue by region is not the same as reporting that shows a rep what they need to know before a call with a grower. The reporting suite included a hybrid comparison analysis format that let users see performance in the terms they actually thought in, not the terms finance thought in.
It was fast enough to check before a decision, not after one. A report that arrives after the decision has already been made is a historical record, not a tool. Once the reporting could be checked quickly enough to inform what a rep said in a conversation that day, it stopped being optional.
There was a visible reason to keep the data clean. This is the part most reporting projects miss entirely. Once users could see that the quality of their own inputs directly improved the usefulness of what came back to them, they started correcting and contributing data without being asked to. Voluntary correction was a clearer sign of adoption than a count of report opens.
Feedback needs a visible route
Users lose trust quickly when they report an error and hear nothing back. Give them a clear way to challenge a number, then show whether the issue came from source data, a definition or the report itself. The answer does not always need to agree with the user, but it needs to be traceable and timely.
Keep a short record of recurring questions. If several people apply the same filter or ask for the same comparison, the report may be hiding a common decision behind too many clicks. If the same data problem returns, fix the capture process rather than teaching every user how to work around it.
Why this matters beyond one sales team
The insights generated by the reporting didn't stay internal, either. They supported stronger customer engagement, with commercial teams able to return meaningful information to growers based on what the data showed. That's a second-order benefit that only exists because the first-order adoption happened. A report nobody trusts never gets to that stage.
If your business has fragmented reporting across sales, production, finance and forecasting, the fix is rarely "build a better dashboard." It's finding which of the three conditions above is missing, and closing that gap before building anything new. That joining-up work is our data engineering, Fabric and AI readiness work.
What to check this week
Before commissioning new reporting, or before assuming an existing report has failed because "people won't use it," check honestly:
| Question | If the answer is no |
|---|---|
| Does the report answer the specific question this user is asked, in their terms? | Redesign around the actual decision, not the available data |
| Can the user check it before they need to act, not just afterwards? | Fix the timing before adding more detail |
| Is there a visible benefit to the user for keeping their own data accurate? | Find or create that link before expecting adoption |
Where to go next
This week's tool, the Reporting Visibility Assessment, walks through these three questions against your own reporting in about ten minutes and gives you a plain-language read on where the gap sits. If you want to talk through what a fragmented-reporting problem looks like in your business specifically, get in touch.