AI consulting is three different purchases wearing one name. Advice tells a business what to do. Implementation builds the thing. Software licenses a capability. Buyers usually describe a need in one of those categories and receive a quote from another, which is why so many engagements end with both sides feeling misled.
Three Purchases That Sound Like One
Advice is the purchase of judgment. The deliverable is a decision, a priority order, or a recommendation not to proceed. Nothing is built and the value lies in the choices that get avoided.
Implementation is the purchase of construction. Something specific gets configured, connected, tested, and handed over. The deliverable is a working system and the specification has to exist before the work starts.
Software is the purchase of capability. A vendor provides a tool with defined functions and the buyer supplies everything else, including the decision about what the tool is for.
These three are sold by different organisations with different economics. They are also frequently sold by the same organisation, which is where the confusion becomes profitable rather than merely unfortunate.
A buyer who needs advice and purchases implementation ends up with a well-built system solving a problem that was never the constraint. A buyer who needs implementation and purchases advice ends up with a document and no change. Both outcomes are common and neither is caused by incompetence.
Why the Mismatch Happens So Reliably
Buyers describe symptoms rather than categories. The opening statement is usually some version of wanting to use AI to become more efficient. That sentence does not indicate which of the three purchases is required.
Sellers interpret ambiguous requirements through the lens of what they sell. This is not cynicism. A firm that builds systems genuinely sees a building problem, and a firm that advises genuinely sees a decision problem.
The result is that the same enquiry produces three different diagnoses depending on who receives it. Each diagnosis is internally coherent and each is partly right, which makes comparison across quotes almost meaningless.
Buyers then compare on price, because price is the only dimension that appears comparable. Comparing the price of advice against the price of construction is a category error that produces predictably poor decisions.
Understanding how consultants, agencies and vendors differ in what they are actually selling resolves most of this before any conversation begins. The distinction is structural rather than a matter of quality.
The mismatch also survives because both parties want the meeting to go well. A buyer who cannot articulate the need adopts the framing offered by the seller, since that framing at least sounds definite. Agreement is reached on a description neither side wrote.
That agreement holds until delivery, at which point the buyer discovers the scope does not cover the part they cared about. The scope covered exactly what was written, and what was written came from a conversation where nobody named the category.
What Each Seller Is Positioned to Recommend
Incentives shape recommendations even among honest sellers, and pretending otherwise leads to bad buying.
A software vendor is compensated for seats and renewals. Its natural recommendation is that the tool be deployed widely and quickly, because usage drives retention. It has no economic reason to advise that a process be redesigned first, and often no capability to do so.
An implementation agency is compensated for built work. Its natural recommendation is a project with defined scope, because that is what can be priced and delivered. It has little incentive to conclude that the correct answer is a change of policy costing nothing.
An advisory firm is compensated for judgment, which creates its own distortion. Advice is easier to sell repeatedly than to make consequential, and the failure mode is a stream of recommendations that never quite reach implementation.
None of these incentives make a seller untrustworthy. They do mean that a buyer should know which one they are speaking to and should discount the recommendation in the direction set by the economics of that seller.
The practical protection is to obtain the diagnosis from a party with no stake in the remedy. That separation costs something and it costs far less than building the wrong thing well.
Diagnosing Which One the Business Actually Needs
Three questions usually settle the category, and they can be answered before any seller is contacted.
The first asks whether the business knows which specific process it wants changed. If the answer is no, the need is advice, and any implementation quote received at this stage is premature regardless of how attractive it looks.
The second asks whether the process is documented well enough that a stranger could describe the desired end state. If the process is known but undefined, the need is process work, which sits between advice and implementation and is rarely what anyone quotes for.
The third asks whether the specification exists and only the building remains. If so, the need is implementation, and the buyer should be comparing builders on capability and price rather than on strategic insight.
Most businesses that believe they need implementation are actually at the second question. The process is understood by the people who run it and has never been written down in a form anyone could build from.
Discovering that early saves the most money. A build against an undefined process produces something that works exactly as specified and does not fit how the work happens. That is the most expensive form of technically successful project.
A fourth question is worth asking privately. What would change in the business if the project succeeded completely? If the honest answer is a modest saving on a task nobody minds doing, the spending belongs elsewhere.
That question filters more proposals than any technical review. Projects survive scrutiny on feasibility and fail on relevance, and relevance is the cheaper of the two to test.
Buying in the Right Sequence
The sequence that works runs from diagnosis to definition to construction to licensing. Most buying runs in the reverse order, starting with a tool that impressed someone and working backwards to justify it.
Reverse-order buying is not irrational. The tool is the most visible element, it demonstrates easily, and it comes with a price that can be approved without a business case. Everything upstream of it is abstract by comparison.
The cost of that order appears later. The tool is in place, the process it should support has not been defined, and the definition work now has to happen with a sunk commitment shaping the answers.
Running the sequence properly means accepting a slower start. The first phase produces no visible technology and its output is a specification, a priority order, and a list of things not to do. That deliverable is unsatisfying and it determines whether everything after it works.
A serious view of what an implementation roadmap should contain before any building starts gives a buyer a way to judge proposals. The test is whether the thinking was done or skipped. The presence of a sequence, rather than a list of features, is the signal.
Slowing the start also gives the business time to notice its own capacity. Every one of these engagements consumes internal attention, and a company running three at once will deliver none of them properly.
What a Good Proposal Looks Like
A proposal worth accepting states which of the three purchases it is. That sounds elementary and very few proposals do it.
It defines the deliverable in terms the buyer could verify without technical help. A written recommendation, a documented process, a configured system passing stated tests. Anything described only as support or partnership is unbounded and should be rewritten before signature.
It names what is excluded. Exclusions are more informative than inclusions, because they reveal whether the seller has understood where the work ends and who picks it up afterwards.
It states who owns the result and what happens when the engagement ends. Ownership of configurations, instructions, and accounts should transfer to the buyer as a matter of course, and a proposal silent on this point is telling the buyer something.
It also states what the seller will need from the business. Engagements fail as often through unavailable internal time as through poor delivery, and a proposal that asks for nothing has not thought about how the work actually happens.
Any proposal that answers all five points can be compared fairly against another that does the same. Comparison between a proposal that answers them and one that does not is not a comparison at all, and price is the least useful place to start.
The market for this work is young enough that the categories are still blurred, and the blurring benefits sellers more than buyers. Clarity is available at no cost to anyone willing to decide, before the first conversation, which of the three things they are buying. The businesses that get value from this spending are usually not the ones that found the best supplier. They are the ones that knew what they were shopping for.
Frequently Asked Questions
What is the difference between an AI consultant and an AI agency?
A consultant sells judgment and the deliverable is a decision or a recommendation. An agency sells built work and the deliverable is a configured, working system. The two require different inputs, because an agency needs a specification that a consultant is often hired to produce. Firms offering both should be asked which capability is leading the engagement.
How can a buyer tell which category they need?
Ask whether the specific process to be changed is known, and whether it is documented well enough to build from. An unknown process indicates a need for advice. A known but undocumented process indicates process work. A documented process with an agreed end state indicates implementation.
Is it a problem if one firm offers all three?
Not necessarily, provided the phases are separately scoped and separately priced. The risk is that the diagnosis phase is conducted by a party whose revenue depends on the build that follows. Splitting the diagnosis from the delivery removes that pressure. Where splitting is impractical, the diagnosis deliverable should be usable by another supplier.
What should a diagnosis phase cost relative to the build?
It is normally a small fraction of the total and it determines whether the remainder is spent well. Buyers frequently resist paying for a phase that produces no visible technology. That resistance is the single most reliable predictor of an implementation that solves the wrong problem.
Who should own the tools and configurations after an engagement?
The buyer, without exception. Accounts, instructions, prompts, integrations, and documentation should sit in the name of the business rather than the supplier. Arrangements where the supplier retains ownership create a dependency that is expensive to unwind later. This should be settled in writing before work begins.
What is the most common wasted spend in this category?
Building a well-specified system for a process that was never the constraint. The work is delivered competently, the tool functions as promised, and nothing measurable improves because the bottleneck was elsewhere. That outcome is a diagnosis failure rather than a delivery failure. It is also almost entirely preventable by asking what would change if the project succeeded perfectly.
No comments:
Post a Comment