Your Costs Went Down. Do You Know Why?

A sales team's routes became measurably more efficient within weeks of a new system going live. The system changed two things at once. It introduced AI-assisted route planning. And, for the first time, managers could compare reported customer visits with ERP and vehicle GPS data.

Efficiency improved.

But there was a problem: nobody could say how much of that improvement came from better route suggestions and how much came from greater visibility into what was actually happening in the field.

That distinction matters. Because when a project delivers measurable results, the next decision is usually about what to expand, what to keep, and what deserves the next round of investment. If you know the result but not what caused it, that decision is partly an assumption.

Why Does the Most Visible Change Get the Credit?

When several things change at once, the most visible one often becomes the explanation. A new AI capability is easy to point to. It has a launch date, a feature name, and a clear story: We introduced route optimization. Costs went down.

But another change may have happened at exactly the same time. Managers gained visibility into whether planned visits actually happened. Reported activity could be compared with ERP and GPS data. Discrepancies that had previously remained hidden became visible. That may change behavior even before an algorithm improves anything. If people know that reported activity can now be compared with what actually happened, the process itself can become more consistent.

Neither explanation has to be wrong. The problem is that a before-and-after result alone cannot tell you which one mattered more.

Where Does the Real Signal Show Up?

Not simply in whether the number improved after implementation. The more useful question is when it started improving and which mechanism was active at that point.

In this case, several capabilities were introduced as part of the same broader change: current ERP data, GPS-verified visit records, automatic visibility into discrepancies, and AI-assisted route planning.

From a management perspective, the outcome appears simple: Routes became more efficient. But that single metric may contain several effects:

• Perhaps the algorithm genuinely found shorter routes.
• Perhaps better visibility changed how consistently planned visits were completed.
• Perhaps managers responded faster when actual activity differed from reported activity.
• Or perhaps all three contributed.

If they were introduced too close together to separate their effects, the final metric cannot tell you which explanation is correct.

What Happens When Several Changes Improve the Same Metric?

This is where attribution becomes a business problem rather than an analytics problem.

Imagine that operating costs fall by 12% after a new automation project. The project contains three changes: better data, greater process visibility, and an optimization algorithm.

The business knows the project worked. What it doesn't necessarily know is which part of the project created which part of the result.

That matters when the next investment decision arrives. If the algorithm receives all the credit, the company may spend more on optimization when better data or visibility produced much of the improvement. The opposite can happen too. A genuinely valuable algorithm may be underestimated because its effect is hidden inside a broader process change.

Either way, the problem is the same: Outcome measurement tells you whether something changed. Attribution tells you why. And those are not the same question.

How Can You Tell What Actually Caused the Improvement?

The cleanest answer is to separate changes whenever possible. Introduce visibility first and establish a baseline. Then add optimization and measure what changes again.

If that isn't practical, look for differences inside the rollout:

• Did some teams receive the capability earlier?
• Did efficiency begin improving before AI recommendations were introduced?
• Did the improvement appear only in routes where recommendations were actually used?
• Did behavior change as soon as activity became measurable?

The goal isn't to prove that AI did or didn't create the result. It's to identify which mechanism changed the outcome before deciding what to scale next.

This is especially important with AI projects because several changes are often introduced together: better data integration, new monitoring, workflow redesign, automation, and the AI capability itself. Calling the combined result an "AI ROI" may therefore hide more than it explains.

So, Your Costs Went Down. Do You Know Why?

You know that the project worked when the number improves. You know why it worked only when you can connect that improvement to the mechanism that caused it. That difference matters when deciding what to fund next.

In the sales example, route efficiency improved after visibility and optimization were introduced as part of the same broader change. Without separating their effects, there was no reliable way to know how much credit belonged to either one.

The lesson isn't that the algorithm didn't work. It's that the result alone couldn't prove that it did.

Before expanding the part of a project that gets the most credit, ask one more question:

If we removed that one component and kept everything else, would the result stay the same?