Proof & ROI

Most businesses that hesitate over AI are not short of pilots. They are short of pilots that settle anything. A pilot that ends in a demo, a slide deck or a vague sense that the technology has promise leaves the investment decision exactly where it started. The buyer is then asked either to fund something larger on faith or to begin another round of exploration. The providers who take proof seriously share a narrower view of the problem. The trouble is rarely whether AI can work in principle. It is whether this particular use, on this business's data, moves a number someone cares about, and whether the exercise was designed so that a no would be as legible as a yes.

Decide what counts before anything is built

The most consistent discipline among these providers is refusing to start until success has been defined. Appfront's practice is to set the success criterion before building the pilot. The reasoning is that a pilot measured against a target chosen afterwards will always find something to celebrate. Dextra Labs goes further and will refuse vague success criteria before pilot work begins. That is a useful signal to a buyer, because a provider willing to turn down loosely framed work is protecting the credibility of the result rather than the size of the engagement.

Devoteam applies the same logic to time. Their position is to refuse open-ended retainers, so every engagement opens with a defined outcome and a date. This matters because open-ended discovery is where AI initiatives most often stall. Work without an end point has no moment at which someone must decide whether to stop, scale or change course.

Pulse Business AI addresses a quieter failure: the assumptions sitting underneath an ROI figure. Their approach is to assign a named owner to every ROI assumption before any measurement happens. It sounds procedural, but it changes the character of the number that comes out. A return figure built on unowned assumptions about hours saved, adoption rates or error reduction can be argued either way once the results arrive. When each assumption has someone accountable for it, the baseline becomes something the business has agreed to in advance, not a narrative constructed after the fact.

Proof has to be real, and small

A second theme is that proof only counts when it is produced on the business's own data, in a form someone could use. Geeks' distinction is that they ship a usable proof of concept, not a demo or a slide deck. The gap between those two things is the whole question. A demo shows that the technology exists. A working artefact on real data shows whether it survives contact with the business.

Several providers pair this with a deliberate smallness of scope. Whitehat argues that small early pilots deliver higher ROI than full rollouts. Impacter reverses the conventional order and will prove value with one built automation before writing any roadmap. AS Consulting offers a blunt diagnostic for small businesses: if nothing measurable has moved within four weeks, the conclusion is that the wrong task was automated, not that more time is needed. For a buyer, this reframes a disappointing pilot as information about task selection rather than a verdict on AI as a whole.

A common objection to starting small and real is that the data is not ready. Two providers push back on this. Centric Consulting starts from raw operational data, with no data warehouse required before work begins. Kuldeep Deshpande, working with mid-sized manufacturers, recommends that businesses run data inventory and use-case discovery in parallel rather than finishing one before starting the other. Both positions challenge the assumption that proof must wait for infrastructure. In practice, that assumption is often how a proof exercise quietly turns into a multi-year programme.

Where the approaches diverge: assess first, or build first

The real disagreement among these providers is about what the first move should be. One camp builds something working immediately and treats the result as the evidence. Impacter and Geeks sit here. The other camp begins with an assessment designed to find where value exists before anything is built.

The assessment camp's strongest argument is that it can say no. Deep Purple's assessment deliberately hunts for reasons not to build, not only reasons to proceed. That is a meaningful distinction, because an assessment run by a firm that profits from the build that follows has an obvious incentive to find opportunities. A few providers attach money to this question directly. Automaly's fee is refunded if fewer than five positive-ROI opportunities are found. Cork AI Consulting charges no fee unless five hours a week of savings are identified. These guarantees do not prove the opportunities will be realised. What they do is show that the provider is willing to bear some of the risk that the answer is disappointing.

The build-first camp's reply, implicit in its approach, is that assessments can still end in documents, and documents are exactly what stalled buyers already have too many of. A buyer choosing between the two is really choosing which risk to tolerate. Build-first risks proving value in the wrong place. Assess-first risks a well-reasoned roadmap that never becomes a working system. The providers who guard against their own camp's weakness are the ones worth attention: assessors who are prepared to recommend against building, and builders who fix the success criterion before they start.

What the proof should actually measure

Evolution Analytics makes a point that should shape any success criterion. In their view, AI success depends more on how it's used than how it's built. A proof of concept that shows technical accuracy but never tests whether people change how they work has proved the easier half of the question. For a buyer, the criterion worth agreeing up front is usually a business outcome under realistic use, not a model metric.

Honesty about cost belongs in the proof as well, because a return figure is only as good as the price it is set against. Layer3 Labs states plainly that only regulated data or integration complexity justify a premium on price. That gives buyers a way to test any quote that comes in above expectations. Kuldeep Deshpande makes a related argument about infrastructure: skip on-premise language models for pilots and reserve them for the proprietary processes that truly warrant them. Over-engineering the pilot inflates the cost side of the case and can sink a use case that would have paid off on simpler foundations.

What to look for

A buyer trying to de-risk an AI decision should expect these things from a provider:

• a success criterion agreed before work starts
• a fixed end date
• a baseline whose assumptions have owners
• something working on the business's own data, not a presentation of what might be possible

It is also worth asking what a negative result would look like and whether the provider has a stake in reaching an honest one. The providers here differ on whether to assess or build first. The better versions of both approaches share one premise: the purpose of a pilot is to reach a decision, and a pilot that cannot end in no cannot credibly end in yes.