ROI, Cost, and Measurement | Blane Canada

Question 1

Where will AI actually pay off in our business?

Accepted Answer

Wherever repetitive, predictable, structured work is consuming time that a person should be spending on judgment. The way to find those places is not to ask where AI could be used. It is to ask where AI, or a simpler fix, would deliver the most return.

We call this value hunting, and the distinction it rests on is small in wording and enormous in consequence.

"Where can we use AI?" produces a list of possibilities, most of which are technically feasible and economically pointless. "Where will AI or a simpler solution deliver the most return?" produces a ranked list of business problems, some of which turn out not to need AI at all.

The places worth examining first are usually the least glamorous. Repetitive, predictable tasks. Work that requires a person to move information from one system to another. Processes where someone manually fixes numbers before every meeting. Functions where the same question gets answered by a person forty times a week.

Automation is not really about cutting costs. It is about redirecting human capacity. AI handles the predictable so people can handle the exceptional. That reframing matters, because a company that hunts for savings finds a smaller number than a company that hunts for capacity.

The practical way to find those places is to quantify the problem before evaluating any solution. How many hours does this consume, and what does that capacity cost? Are errors producing rework? Are slow decisions costing you opportunities? Is executive attention going to work that could be handled another way? Those numbers become your baseline, and without a baseline you will not be able to tell later whether anything actually improved.

Stop chasing tools. Start creating value.

Question 2

How do we measure whether our AI investment is paying off?

Accepted Answer

Define success before you start. The single biggest reason AI initiatives quietly die is that success was never defined upfront, so there was nothing to measure, nothing to defend, and nothing to build on. Set a baseline first: current task time, error rate, and cost.

If you cannot measure it, you cannot manage it. AI adoption should feel like an investment rather than a guessing game.

Start by setting baseline performance metrics before anything is deployed. How long does the task take today? What is the current error rate? What does it cost? Without those three numbers, any claim of improvement later is an opinion.

Then define what success looks like in specific terms. Time saved, cost reduced, errors eliminated, revenue affected. Build a feedback loop so the people using the tool can report whether it is actually useful, and schedule review checkpoints where you decide to scale up, pivot, or stop.

There is one category of return that will not show up in standard measurement, and it is often the largest. A route planning problem we worked on was consuming more than half of an executive's working hours, which is a serious cost on its own. The bigger cost was that the problem never left their head. The worry about what was being missed ran all day. That is not a time problem. It is a bandwidth problem, and it never appears on a profit and loss statement.

Most executives can tell you where their time goes. Very few can tell you where their mental energy goes. That is worth measuring too.

Question 3

Is "how can AI save us money" the right question?

Accepted Answer

It is the wrong question, and we hear it constantly. Cost cutting is not the same as differentiation. The executives focused only on savings are optimizing for expenses rather than for what makes customers prefer them. That is a defensive posture in a period that rewards offense.

Geoffrey Moore's distinction between core and context is the most useful frame I have found for this decision.

Core is whatever differentiates you from your competition and causes customers to prefer doing business with you. Context is everything else, where the goal is to meet expectations as efficiently as possible and not disappoint.

Context divides again. Enabling context is low-value routine work that should be automated or outsourced as much as possible: facilities, payroll, food service. Mission-critical context directly affects a key constituency, where there is no prize for doing it exceptionally well but severe penalties for falling short. Companies tend to over-resource mission-critical context to reduce risk, which ties up capacity that should be going to core. The result is a weakened core.

That is the real AI decision. Automate and outsource enabling context aggressively. Right-size mission-critical context so it stops consuming resources it does not need. Then put the freed capacity into what actually differentiates you.

Executives focused on savings are not thinking long-term. They are trying to shave expenses and sometimes people. That is not innovation. What matters is not cutting costs. It is creating differentiation customers can feel.

Question 4

Why is AI ROI hard to calculate, and what counts besides cost savings?

Accepted Answer

Because both sides of the equation spread out. Costs scale with usage rather than sitting in the build. Benefits show up as recovered capacity, better decisions, and reusable infrastructure rather than as a line item. The fix is not abandoning ROI. It is measuring the categories separately instead of forcing them into one number.

Traditional return calculations work best when both sides are obvious. AI is messier in a specific way.

Consider a project that removes three hours of work per week without eliminating a position. Is that a benefit? It is, but only if those hours go somewhere that matters. If they are absorbed by more meetings, you have bought nothing. So the measurement has to include where the recovered time actually went, which most companies never track.

Then there is the value that arrives later. An integration built for one workflow often turns into infrastructure that makes the next three projects cheaper. Cleaning a data source for one department frequently makes it usable for five. Those are real returns and they cannot be forecast precisely at approval time.

The discipline that works is separation. Track direct financial impact, recovered capacity, revenue effect, risk reduction, adoption, and strategic capability as distinct categories. Do not roll them into a single inflated figure, because a number built that way cannot survive its first serious challenge in a budget review.

There is one more category that never appears on a profit and loss statement, and it is the one executives feel most and measure least. Some problems do not only consume hours. They occupy the back of someone's mind all day, and the person carrying them cannot fully put them down between meetings. When a system takes that over, the hours saved understate the gain considerably. It is difficult to put on a spreadsheet and it is usually the first thing the executive mentions afterward.

Question 5

How do I calculate the true cost of an AI project?

Accepted Answer

Budget for the run, not the build. Unlike traditional technology projects, AI costs to build are usually smaller than the ongoing costs to operate, and those operating costs scale with usage. The capital expense model most companies apply will understate what they are actually committing to.

In the software business, ongoing costs were generally lower than the build and rarely changed based on how much a customer used the product. AI flips that script, and you need to plan for it.

The pattern shows up early and predictably. The barrier to entry is almost nonexistent at the start. Nearly anyone can spin up a project with a credit card and an API key. As one industry leader put it, day zero is very easy. Day two is when the bill comes due.

There is a second cost that hides in the same place. If your entire setup is built inside one provider's toolset, you are effectively renting a cage. The speed of the early pilot conceals technical debt that becomes obvious the moment you try to move the work somewhere else.

This is why pilots that looked inexpensive become expensive later, and it catches executives who have managed technology budgets for decades. Traditional enterprise software front-loaded the cost: license, implementation, integration, then a predictable maintenance line. AI front-loads almost nothing, so the pilot budget was never the real budget. What arrives afterward is usage-based pricing that grows with adoption, which means success itself increases your bill, plus data preparation work nobody scoped because the demonstration ran on clean sample data.

Two practical moves that most companies skip. Estimate realistic usage rather than pilot usage before you commit, because one person experimenting occasionally and two hundred people running workflows all day are different businesses. And test whether a less expensive model or a simpler architecture handles part of the work, because a great deal of what gets routed to the most capable option does not require it. Scaling should be a business decision rather than a technical milestone.

When you project return, make sure the denominator includes ongoing operating cost at realistic volume, the cost of making your data usable, the training investment that determines whether anyone actually adopts the tool, and the cost of leaving if the vendor relationship does not work out. None of this argues against pilots. It argues for scoping the run cost alongside the build cost, and for asking the exit question before you sign rather than after.

Question 6

Why is our AI work producing no measurable return?

Accepted Answer

Because there is a gap between the AI projects and the business goals, and nobody has connected them. Teams are building automations, testing copilots, and launching pilots. Ask how any of it ties to revenue, margin, or growth and you get silence or a vague answer. That gap is where return disappears.

AI without alignment to business goals is not strategy. It is experimentation, and experimentation is fine as long as everyone knows that is what it is.

The way to close the gap is not more governance meetings. It is a simple structure applied before the work starts. Define the outcomes that actually matter. Identify where AI, or a simple process change, produces the biggest gain in your operation. Make sure someone owns adoption rather than just deployment. Create guardrails that produce consistency.

Then bring all of it into one place. That is what a Blueprint is for. Full context, aligned use cases, and a clear prioritization of what will drive the most value. No random list of initiatives. No disconnected pilots. AI tied directly to business outcomes.

One variable explains more of these gaps than any other, and it is adoption. A technically excellent system that people avoid produces nothing at all. So adoption belongs in the business case before launch rather than in a report afterward. Who will use this, and why would they prefer it to what they do now? What training is required? What new work does it create for them? If usage stays low during a pilot, treat that as information rather than as a compliance problem. It usually points at weak output, poor workflow fit, or a product that does not solve the problem as well as everyone hoped.

The real question worth asking your team this quarter is not what tools they are testing. It is whether you are thinking about AI strategically or responding to market pressure and hoping for the best.

Question 7

What does successful AI adoption actually look like?

Accepted Answer

Not a tool count. It looks like employees who know where AI helps and where it does not, leadership that can explain why each investment was made, solutions that fit the way work actually happens, and something in the business that measurably improved. Usage is an input. Business improvement is the result.

A company can hold dozens of AI subscriptions and have almost no AI capability. I have seen exactly that, and from the outside it looks like progress.

Real adoption shows up in behavior first. Employees can tell you where the tool earns its place and where they still do the work themselves, which means they have developed judgment rather than enthusiasm. Managers can describe how a workflow changed. Leadership can explain which investments matter and why, in language that does not come from a vendor. Successful experiments get captured and shared rather than living inside one person's private workflow, which is where most of them quietly die.

Then it shows up in outcomes. Work takes less time. Decisions get made earlier because the information arrives sooner. Capacity increases without headcount. Customers notice something. Risk goes down.

The better question a year in is not whether you implemented AI. Almost everyone will have. It is what you can now do that you could not have done without it. That is a much higher standard and a much more useful one, because it separates the companies that added tools from the companies that changed what they are capable of.

Question 8

How do we do more with less staff?

Accepted Answer

Look at productivity per person before you look at headcount. As an illustration of the logic rather than a measured result: a ten-person organization with $750,000 in combined salary that gains 20 percent in effective capacity has gained roughly $150,000 of output it did not have to raise. The gain comes from removing repetitive work, not from working people harder.

This is one of the most common questions I hear from executives of small organizations, and it usually arrives with real pressure behind it.

The framing that helps is to think in terms of capacity you already fund rather than money you need to find. Every organization is paying for a certain amount of human attention. The question is how much of that attention is currently consumed by work that produces nothing distinctive: rekeying data, hunting for the right version of a file, answering the same routine question, assembling a report by hand every week.

That is where the recoverable capacity sits, and it is recoverable without asking anyone to work longer.

Two cautions. First, the gain is real only if the freed time gets redirected to something that matters. Capacity that is recovered and then absorbed by more meetings is not a gain. Second, the productivity math above is an illustration of the logic, not a measured result. Your actual number depends entirely on how much repetitive work your operation carries, which is exactly what an operational audit is designed to find.