Don't start with AI. Start with the problem.

There is a question that gets asked in boardrooms, and it is the wrong one:

"Where can we use AI in our business?"

It sounds like diligence. It is actually a trap, and the trap is subtle: the question guarantees an answer. Ask where a technology could be applied and you will always find somewhere. Enthusiasm supplies the rest. What the question never establishes is whether applying it there is worth anything.

What starting from the technology produces

It produces a pilot. The pilot goes reasonably well, because pilots are chosen to go reasonably well. There is a demonstration, and people are impressed.

Then the tool sits beside the real process rather than inside it. It requires someone to open a different application, in a different tab, to do a job they can already do in the spreadsheet they have open. So they use the spreadsheet. Six months later the conclusion is that "AI didn't really work for us."

AI worked fine. It was applied to a step that nobody needed help with, in a place nobody was working.

The order that works

Start from the other end.

What is the problem? Not the technology gap — the business problem. What is late, expensive, inconsistent, or quietly capping what you can take on. If it cannot be described without mentioning a technology, it is not yet a problem statement.

How does the work actually get done? Not the documented process. The real one, with the workarounds, the person everybody asks, and the spreadsheet that is secretly the system of record. The cost is almost never where the org chart suggests.

Where is the loss? Time, money, effort, quality, or opportunities that quietly do not happen. Quantify it as far as you honestly can. This number is what everything afterwards gets measured against, and it is also what tells you when to stop.

Only now: can intelligence help here? Sometimes the answer is document understanding or continuous monitoring. Sometimes it is a formula, a template, or a conversation between two departments. Sometimes it is nothing, and the correct move is to leave the process alone.

Why we ask so many questions before proposing anything

If you tell us that preparing quotations is painful, we cannot yet tell you whether AI will help. Painful is not enough information.

Painful because the pricing rules are genuinely complicated? That may be a data structuring problem. Painful because the information is scattered across five places? That is a different problem. Painful because one person is the only one who knows the products, and they are on leave? That is an organisational problem wearing a technology costume, and no model will fix it.

Same symptom. Three different answers. Two of them are not AI.

The uncomfortable version

The honest consequence of working this way is that some conversations end with us saying a project is not worth doing. The volume is too low for the effort to pay back. The rules change too often to be worth encoding. The process is annoying but not actually expensive.

We would rather say that in the first conversation than discover it in month four. It costs you nothing at the start and a great deal later, and a business that trusts us to say no is a business that can trust us when we say yes.

Our objective is business improvement, not AI implementation. Those are not the same goal, and confusing them is how the money gets spent.

Start with the problem. The technology question will still be there, and by then you will know what to ask of it.