Where to start with AI, if you actually run something
Nearly every company we talk to has already tried something with AI. Somebody used a chatbot to write job descriptions. Somebody else bought a licence for a tool that promised to read invoices. Six months later there is a subscription nobody remembers approving and no change anyone can point to.
That is not a technology failure. It is a starting-point failure.
Start with a process, not a product
The usual order is: hear about a tool, buy the tool, look for somewhere to use it. That order almost guarantees a poor fit, because the tool was designed for a generic version of a problem you have a specific version of.
Turn it around. Pick the process first. The one worth picking usually has four things going for it:
- It happens often. Twice a day beats twice a quarter, every time. Frequency is what turns a small saving into a real one.
- It follows rules, even unwritten ones. If an experienced person could write down how they decide, it is a candidate. If the answer is “you just know”, it is not — yet.
- It has a clear input and a clear output. Something arrives, something leaves. Vague boundaries make results impossible to measure.
- It annoys everybody. The work people already resent is the work they will actually let you change.
Then measure it before you touch it
This is the step almost everyone skips, and skipping it is why so many AI projects end in an argument.
Pick one honest number for the process as it runs today. Hours per week. Days from request to quote. Percentage of jobs that get reworked. It does not have to be sophisticated — it has to be repeatable, and you have to believe it.
Write down how you measured it, in enough detail that somebody who was not there could do it again and get the same answer. That is the difference between a baseline and a guess.
Two things happen when you do this. First, you will find the real cost is not where you assumed. Second, when the change is made, you will be able to prove what it did instead of arguing about whether it feels faster.
Expect the answer to be small at first
The first deployment worth doing is rarely dramatic. It is usually one step in one process that stops requiring a person. Something like: the details from an incoming request stop being re-typed into the system by hand.
That is not exciting to write about. It is, however, an hour a day back, it works on the first try more often than the ambitious version does, and it teaches your team that this can be normal rather than a special project.
Ambition is fine later, once there is something on the board.
The honest test for whether it worked
Six weeks after it goes live, ask two questions.
Is the number better than the baseline, measured the same way? And are people still using it when nobody is watching?
If the answer to both is yes, do the next one. If the answer to the second is no, the problem is almost never the technology — it is that the new way costs somebody more effort than the old way, and they quietly went back. That is fixable, but only if you go and look.