AI consulting for mid-market companies: what it costs and what you actually get

Compare an AI engagement as a complete operating commitment. Diagnosis, implementation, adoption and support may appear on different lines or in different contracts.

Independent consultants, large firms and specialist teams can offer different combinations of analysis, implementation and support. A supplier category does not establish capability or cost; inspect the actual team and scope.

All three exist. None of them are the same product. The industry calls them all AI consulting and expects you to figure out the difference between a diagnostic, a deployment, and a training workshop based on marketing language.

Ask for a scope table that names the work, accountable people, acceptance evidence and ongoing costs.

The first thing that separates real consulting from theater is what the person has built.

Look for work that was built, deployed, and run on real company data under real process constraints. Then ask what broke and how they fixed it.

There is a difference between a consultant who knows what AI can do and a consultant who has made it work inside a company with legacy systems, undocumented processes, and people who have been doing things a certain way for eleven years. The first can write a report. The second can tell you which spreadsheet three people maintain in three different formats, which senior analyst runs a critical process entirely in her head, and which approval chain is actually fear wearing a responsible suit.

Ask for a concrete process, design and result the provider is authorized to show. Redaction is legitimate; a sample demonstrates the format but should not masquerade as completed client work.

If direct client evidence is unavailable, use references or a bounded paid test to evaluate capability before increasing exposure.

The second thing that matters is scope clarity.

Most AI consulting engagements fail at the boundary between diagnosis and execution. The consultant comes in, maps the situation, delivers a report, and leaves. The report is good. The recommendations are clear. The execution is not.

The structure creates the gap. Diagnosis and execution require different skills, timelines, and risk profiles. A team designed to assess may lack the ability to build. Its maturity scores, roadmaps, and priority matrices only help when someone already knows how to execute them.

The engagements that work connect the two. The person who maps the processes stays to design the systems. The person who identifies the bottlenecks stays to remove them. The report is not the end product. It is the starting point for the build phase.

Agree who remains accountable through adoption and transfer. A change of team is workable if responsibility, evidence and handover are explicit.

Build a total-cost view from the quote

Before production: discovery or feasibility, data preparation, connectors, implementation, tests and the client time required for access and validation. Name exclusions and the change-control process.

During operation: model usage, hosting, licenses, monitoring, support, incident response and maintenance of connectors and permissions. Use expected volumes plus a stress scenario and spending limits.

Adoption and exit: training, supervised operation, documentation, recovery exercises, data export and transfer to the client or another partner. Optional managed support should not remove the client’s access or portability.

These are scope categories, not a public Solve IT tariff or a verified market price range. Compare quotations on the same volume, risk and ownership assumptions.

Solve IT routes each qualified case before prescribing an engagement. A diffuse cross-functional problem may need a War Map. An already-defined workflow may go directly to a bounded Feasibility Sprint.

Scope, timing, price, evidence requirements, and risk controls are agreed for the actual case.

The point of transparent scoping is not to publish a number before understanding the operation. It is to make the boundary between diagnosis, feasibility, implementation, and ongoing support explicit before work begins.

The question you should ask before signing any AI consulting engagement is not what does it cost. It is what happens on day one after the deliverable lands.

Does the person who wrote the plan stay to build the first thing? Do they know where the data actually lives, not where the IT diagram says it lives? Have they deployed something similar in a company your size, with your mix of legacy systems and informal processes? Can they show you a specific example of a process they mapped, a system they designed, and a result they held themselves accountable for?

If the answer to any of these is no, you are not buying execution capability. You are buying analysis. There is nothing wrong with that, as long as you know what you are buying.

If you are buying diagnosis only, use the assessment guide. Before appointing the delivery partner, use the consultant-evaluation questions.