How to evaluate an AI consultant before signing
You are about to sign a contract with an AI consultant. You have read the proposal. It sounds good. It uses the right words. It has slides with arrows and a timeline that looks organized.
You still do not know if this person can do what they say.
Most consulting proposals are written to make that uncertainty feel like confidence. They describe outcomes without describing the work. They show methodology without showing evidence. They list credentials without showing what happened when things went wrong.
You can figure out whether someone will deliver or just present in three conversations. The trick is asking the right questions before the ink dries.
Ask these questions.
Can I see a sample deliverable from a previous engagement? Not a case study. The actual thing.
A case study is marketing. A sample deliverable is evidence. You want to see the War Map itself. The process documentation. The diagnostic report with real findings. The architecture diagram with real decisions.
If a consultant says everything is confidential, ask for a redacted version. If they still cannot produce anything, ask yourself why. People who do real work have artifacts. People who sell methodology have slides about methodology.
A sample does not prove they will do the same quality for you. But the absence of a sample proves they either cannot show you anything, or they have never built anything worth showing.
What is your go/no-go gate?
Any real engagement has a decision point where the work either continues or stops. Not at the end. In the middle. After enough discovery to know whether the problem is worth solving.
If a consultant describes a linear process from week one through week sixteen, with every step guaranteed to produce value, they are describing a script rather than a diagnostic. Real transformation starts with uncertainty. You learn which workflows matter by looking. You find what is broken by mapping it. A good consultant builds a gate into the process and has the discipline to use it.
Solve IT sets the go/no-go gate for the actual case before work begins. A diffuse problem may need a War Map. A defined workflow may go directly to a bounded Feasibility Sprint. The company sees the evidence, the exceptions, and the proposed next step before deciding whether to implement.
Who is doing the work?
This is the question that reveals the most. The person who sells you the engagement is not always the person who executes it. Sometimes it is a junior analyst with a checklist. Sometimes it is a partner who shows up for the kickoff and the closeout and disappears in between.
Ask for the name and background of the person who will do the diagnostic work. Ask how many hours they will spend on your engagement versus on other clients. Ask whether they work from a template or build from the situation.
The answer matters more than the methodology. A senior operator with real industrial or systems experience will see things a generalist misses. They will know the difference between a process that looks broken on paper and a process that is actually protecting the company from a risk nobody documented. They will know which handoffs are waste and which handoffs are institutional memory wearing an ugly suit.
What happens when the diagnosis is uncomfortable?
Every company has processes that exist for reasons nobody remembers but everyone protects. The approval chain that started because of one bad vendor decision in 2019. The spreadsheet that replaced a system that replaced a person who left. The meeting that exists because someone needs to feel involved.
A consultant who only recommends what the leadership wants to hear is not diagnosing. They are performing reassurance.
Ask the consultant what they do when the findings contradict the internal narrative. When the CEO believes the problem is adoption and the data shows the problem is design. When the operations director believes the process is documented and the reality is three people keep it alive through WhatsApp.
The right answer is not dramatic. It is structural: show the evidence, name the gap, and let the leadership decide. A good War Map does not prescribe. It makes the invisible visible. The decision is always the company's.
Do you guarantee anything?
Risk controls work when the scope is specific enough to measure. The agreement should state what will be tested, what evidence counts, where human approval is required, and what happens if the gate fails.
A public promise cannot replace a case-specific boundary. The useful protection is a written acceptance criterion tied to the workflow, the data, and the decision the company needs to make.
Clear scope creates clear accountability.
What is the full engagement look like?
A War Map is the diagnostic. Implementation is the build. When a company continues, the next phase covers real workflow design, architecture, process redesign, and knowledge systems. The result must run after the consultant leaves.
But the diagnostic comes first. You cannot build what you have not mapped. And you should not map what you will not use.
Three red flags
If a consultant cannot show a sample deliverable, walk away. If they do not have a go/no-go gate, walk away. If the person selling is not the person working, ask for a meeting with the person working before you sign.
These are not dealbreakers because consultants are bad people. They are dealbreakers because you are about to spend real money on something that affects how your company operates. You do not need certainty. You need enough evidence to make a decision.
The companies that get AI transformation right are not the ones that pick the most impressive proposal. They are the ones that asked the right questions before the contract was signed.