What results should you expect from AI?

Expectations in this field are set by marketing, which describes the best case as the normal case. Here is a more useful version, phase by phase.

From the diagnosis: clarity, and usually a surprise

What you should get is a ranked list you can act on, with rough values, an explicit set of things not to bother with, and a sequence.

What most companies also get is a surprise: the biggest opportunity is not where they assumed. Usually it is something unglamorous and high-frequency, or something nobody is doing at all rather than something being done inefficiently.

What you should not expect is a number you can take to the bank. Estimates before a build are ranges with assumptions attached, and anybody offering precision has not looked properly.

From the first build: one thing working, and a lot of learning

A single process handled reliably, and knowledge you could not have bought any other way: how your team reacts, whether your data was as clean as you believed, how long your own approval cycles take, whether anybody looks at the reporting.

That learning changes the second project substantially, and it is the actual return on a small first build.

Do not expect transformation. A first project that promises transformation is scoped wrong.

The month-two dip, which is normal

Almost every project has a stretch where it feels worse than before, and knowing this in advance prevents cancelling something that is working.

Three reasons. The novelty is gone. The exceptions have started arriving, and the exceptions are where the design gets tested. And somebody has to make decisions about cases nobody anticipated, which feels like the system failing when it is actually the system doing its job by escalating.

Meanwhile the benefit is diffuse and the friction is concentrated. Nobody notices twenty things handled quietly; everybody notices the one that had to be corrected.

Hold to the numbers you baselined rather than the mood in the room. Which is why the baseline has to exist.

By three months: the honest realistic outcomes

Speed changes first and most visibly. Response and turnaround times improve immediately and dramatically, because software does not have a queue.

Consistency improves. The thing happens every time rather than when somebody remembers, and the value of that is larger than it sounds because the failures it removes were invisible.

Something previously not happening now happens. Follow-up, reactivation, reminders. Frequently the largest single gain and the one nobody predicted, because the comparison is against nothing.

Volume capacity increases without headcount. Not because anybody works faster, but because the ceiling on simultaneous work is gone.

What does not happen

Staff reductions, mostly. In small and mid-sized companies the realistic outcome is the same people handling more, or handling better work, not fewer people. Anybody selling headcount savings to a business of thirty people is selling a spreadsheet.

Quality improvements in judgment work. These systems are consistent, not wise.

Anything resembling a revolution in your business model. The gains are operational.

Immediate revenue that you can cleanly attribute. Revenue has many causes, and a supplier presenting a revenue increase next to their invoice is inviting a conclusion the data will not support.

The two ways good projects still fail

Worth knowing because both are avoidable and neither is technical.

Nobody owns it. No named person, no metric anybody looks at. It runs, degrades quietly as your business drifts, and twelve months later somebody notices it has been giving out last year's information.

It was the wrong thing. Built well, ranked badly. The frequency was too low, or the exception rate too high, or the process was broken and should have been fixed on paper first. The build worked and the business did not change, and the conclusion drawn internally is that AI does not work here, which is very hard to reopen.

The second is why the diagnosis matters more than the construction.

The expectation I would set if I could only set one

The first project should pay for itself and teach you what the second one should be. That is the whole target.

Companies that treat project one as the transformation are disappointed. Companies that treat it as the cheapest way to buy information about their own operation get both the return and a much better second decision.

Our roadmap carries an estimate per recommendation precisely so there is something to check the result against, and it says what not to do as well as what to do. How the engagement runs, and what a first automation should look like.