Analytics7 MIN READ

Why your Power BI rollout stalled at thirty users

The reports work. The refresh runs. Usage flatlined anyway. In our experience the cause is almost always one of four things — and only one of them is technical.

Techlyst Analytics Practice15 April 2026723 words

A familiar shape: eighteen months in, the Power BI estate has forty reports, the gateway is stable, refreshes run overnight. And the same thirty people open it. Everyone else went back to the export.

Adoption plateaus are rarely caused by the thing teams investigate first. Here are the four causes we actually find, in the order of how often we find them.

1. The same metric has more than one answer

Two reports show gross margin. They differ by three points because one includes freight and the other does not, and neither states its treatment. A user notices once. From then on, every number in the platform is provisional in their mind, and provisional numbers do not get used in meetings.

The fix is not technical, though it has a technical component. Build one semantic model with one definition per metric, documented in a metric dictionary that a non-analyst can read, and stop publishing report-level measures that redefine central concepts. Where two departments genuinely need different treatments, name them differently — "gross margin" and "contribution margin after freight" — and show both.

2. Reports are built at the wrong grain for the audience

A single report is asked to serve an executive who needs five numbers and a warehouse supervisor who needs today's picking exceptions. It ends up with twenty-two visuals and nine slicers, and serves neither.

Separate them. An executive page answers a fixed set of questions with no interaction required — if a director has to configure a slicer, the page has failed. Operational pages sit at the grain the team works in, filtered to their scope by row-level security, and open to a default view that is useful without any clicks.

3. It is slower than the spreadsheet it replaced

This is the technical one, and it is unforgiving. Above roughly four to five seconds to render, users stop exploring; above ten, they stop returning. Almost always the cause is one of four things:

  • Queries not folding back to the source, so transformation happens in the model instead of the database.
  • Bidirectional relationships and calculated columns where a measure or a star-schema fix would do.
  • A single flat table of forty million rows with no aggregation layer.
  • Twenty-plus visuals on one page, each firing its own query on load.

Measure before optimising — Performance Analyzer, then DAX Studio — and fix the model rather than the visuals. Model problems cannot be optimised away at the report layer.

4. Nobody was made responsible for anyone using it

The project had a sponsor for delivery and no owner for adoption. Reports were announced by email, training was one session for everybody, and no one was accountable for the usage curve three months later.

Treat adoption as a deliverable with a metric. Publish usage — report opens per team per week, distinct users, and the count of surviving shadow spreadsheets. Give each report an owner who is asked about that number monthly. When a report has no users for sixty days, retire it rather than maintain it; a smaller estate that is trusted beats a large one that is not.

A ninety-day recovery plan

01

Weeks 1–2 — audit

Usage per report, refresh reliability, render time on the real dataset, and a list of every metric that appears in more than one report with more than one definition.

02

Weeks 3–6 — consolidate

One semantic model, one definition per metric, documented. Retire everything with no users in sixty days. Expect the estate to shrink by half; that is a good sign.

03

Weeks 7–10 — rebuild for audience

One executive page, operational pages at working grain with row-level security, and a hard performance budget of two seconds per page on production volumes.

04

Weeks 11–13 — hand over the habit

Train on the model, not the buttons. Name a report owner each. Publish the usage dashboard. Book the monthly review before the project closes, because the review is what keeps the curve up.

A report nobody opens is not a reporting asset. It is a maintenance liability with a nice colour scheme.

Written by the Techlyst Analytics Practice. If any of this describes your situation, a 45-minute consultation will tell you which phase you actually need — book one here.

Next step

Ready to see what one connected architecture would look like?

A 45-minute consultation, no obligation. We will tell you what we would do first — and whether you need us at all.

WhatsApp