Executive Summary
You've spent a good six months and a fair bit of money moving to Looker, but people are still just exporting CSVs and working in Excel.
You're paying for licences that aren't being used, while important business decisions are being made in spreadsheets that nobody can track or check. This isn't just a waste of money; it's a risk to the business.
More training sessions aren't the answer. The problem isn't the user or the tool, it's a lack of trust in the data itself. The solution is to fix the data: build a reliable, governed reporting engine that people can depend on.
Why a new BI tool often doesn't solve the problem
Let's be direct. Buying a new BI platform like Looker is a very common way to try and solve a data problem, but it often doesn't work. I see this quite a lot with scale-ups. You've invested in a modern data stack, you have Snowflake and dbt, and you've hired good engineers. But after a long migration project, you find that not many people are using the new platform. The business has quietly gone back to its old ways: spreadsheets.
The usual reaction is to think it's a people problem. "They're resistant to change," or, "We just need to run more workshops."
In my experience, that's rarely the case. The team's reliance on Excel isn't a training issue; it's a trust issue. They don't use Looker because they believe, rightly or wrongly, that their spreadsheet is faster, more flexible, or more accurate. You haven't found a new solution, just a more expensive way of running into the same old problems. What you have is the same chaos, just in a new system.
The problem is usually in the data architecture
When someone exports a CSV, they're sending a clear signal: "I don't trust this system to give me what I need." This isn't their fault. It's a problem with the system. I've looked at Looker setups worth a great deal of money where 60% of the reports hadn't been looked at in over six months, yet the data team was snowed under with requests for yet more dashboards.
The root cause, I find, is usually one of a few architectural issues:
If the underlying process is broken, a new tool just helps you produce untrustworthy numbers more quickly. The tool itself is never the answer. The answer is fixing how the numbers are produced in the first place.
How to start fixing the problem
The way to fix low BI Adoption can feel a bit backwards. It's not about adding more features or dashboards. It's about disciplined subtraction and curation.
Our first step is never to build. It's to audit. We find these unused reports and remove them. We take the 15 different versions of the 'Sales Performance' dashboard and consolidate them into one key report for the leadership team that everyone, from the sales director to the finance director, agrees on. This work is often more about navigating company politics than it is about data architecture.
Fixing this means establishing a genuine Single Source of Truth. This isn't a buzzword. It's the difficult but necessary process of getting agreement. It means getting teams in a room to discuss, debate, and finally commit to a single, written-down metric definition that lives in the semantic layer, not in a dozen different SQL scripts.
This is a change in how teams work, not just in tooling
Be prepared for some resistance. Taking away a department head's favourite vanity metric can be a political conversation. Asking the operations team to abandon the master spreadsheet they've relied on for years will feel like a threat. You will have to slow down for a bit to speed up later.
The goal is to change the data team's job. Instead of just building dashboards on request, they become the curators of core, trusted information. They build and look after the essential, high-trust reports. Then, they can give specialists in each department focused, practical training to build their own views on top of that trusted foundation.
This is how you build a healthy Data Culture. It's not about forcing people to use a tool. It's about making the tool the most reliable, fastest, and most trusted place for them to get their job done. When the data is right, adoption tends to follow.