Skip to content
DataHorizon
Book a call
← INSIGHTS

22 SEPTEMBER 2026 · 6 MIN READ

The last mile of BI: writing the decision back into your systems

A dashboard ends at the read. The value is in the portal, approval flow or field app that captures the decision and acts on it — the layer BI-only firms leave out.

A dashboard ends at the read. Someone opens it, sees the number, understands the situation, and then closes the laptop and does the actual work somewhere else: in an email, a spreadsheet, a phone call, or a form in another system. That gap between seeing and doing is the last mile of BI, and it is where most of the value leaks out.

Reporting projects usually stop at the dashboard, because that is where the BI tool stops. Power BI is very good at showing you that credit risk has risen, that a site is low on stock, or that a claim needs review. It cannot capture what you decide to do about any of it. So the decision happens off to the side, ungoverned, in a place the data platform never sees.

Why the gap is expensive

When the action lives outside the system, a few things follow. The decision is not recorded against the data that prompted it, so later you cannot see why a call was made. The process depends on someone remembering to act on what they saw, which fails under load. And the same numbers that were carefully governed in the model get copied into a spreadsheet the moment anyone needs to act on them, which is where the governed version starts to drift again.

What closing the last mile looks like

Closing it means building the thin layer of software where the decision is made and wiring it back into the governed platform. That is usually a focused application rather than a big system: a portal, an approval flow, or a field app. A few concrete shapes:

  • An approval screen where a manager sees the flagged items from the model and approves, rejects, or routes each one, with the outcome written straight back to the warehouse.
  • A field or warehouse app where staff capture what actually happened, including offline, so the record is created at the point of work rather than re-keyed later.
  • A write-back workflow that lets someone adjust a forecast or a status, keeping an audit trail of who changed what and when.

In each case the read and the action happen in the same governed place, and the decision becomes data the next report can use.

The part BI-only firms leave out

Many consultancies deliver the model and the dashboard and stop there, because the application layer is a different skill from semantic modelling. Building the app well means real software engineering: access control, an audit trail, testing, and a release process, on the same governed data rather than a copy of it. Skipping that is why so many BI projects end with a good dashboard that nobody acts on inside the tool.

How we approach it

We tend to pick the single workflow where the gap costs the most and design around that one, rather than trying to build a portal for everything at once. The app runs on the governed platform, with the same security rules as the reports, and an audit trail from the first release. Once the first workflow is closed and people trust it, extending to the next one is a smaller step.

A dashboard tells you what is happening. The last mile is what lets your team do something about it in a place you can still govern and measure. If your reporting is solid and the decisions still happen in email and spreadsheets, that gap is usually the highest-value thing left to build.

Not sure whether it’s your data or your definitions?

A short scoping call is usually enough to tell. We’ll look at where your numbers disagree and say whether a semantic model would fix it, including when it wouldn’t.

Scoping conversations are free · No NDA needed to talk