AI has made it easier for consulting firms to look prepared before they understand a client’s business. A proposal can be clear, specific, and visually complete before the team has learned much about the company it was written for. A credible demo also takes less time and technical work than it once did.
A polished proposal is not necessarily fake. Capable teams use the same tools, often very well. But polish tells a buyer less than it used to.
That matters because companies still rely on familiar signals when choosing an AI partner. They look at the quality of the presentation, the confidence of the recommendation, and whether the demo works. All of that is worth considering. None of it shows whether the partner has understood the business well enough to recommend the right work.
Watch what the partner asks before recommending anything. Then listen for the conditions they attach to the answer and how they deal with facts that are missing or disputed. Those parts are harder to manufacture because they depend on the client’s actual situation.
With polished output everywhere, the useful signal is the reasoning behind the recommendation.
A demo proves what happened in the demo
A demo is worth seeing. It tells you whether the team can turn an idea into something concrete, and it gives everyone a shared object to discuss. That is already better than an hour of vague promises.
The trouble starts when the demo is asked to prove more than it can.
Most demos use selected inputs and a clean route through the workflow. That is normal. Nobody wants to begin a sales meeting by watching a prototype fail on a corrupted spreadsheet. But the conditions that make the demonstration legible are often the same conditions that disappear in production.
Ask where the source data came from. Ask which permissions were simplified. Ask what the team left outside the prototype because it was too awkward for the first version. If two documents disagree, which one wins? If the system makes a poor recommendation, who notices? If a case reaches a person, what context travels with it?
The answers tell you what the demo covered. They also reveal whether the partner has thought seriously about the distance between a working screen and working software.
Research on AI-assisted pitches makes this distinction unusually concrete. In a Columbia Business School experiment, AI assistance made it harder for experienced evaluators to distinguish experts from non-experts by presentation alone. The study also found that genuine experts could communicate more effectively across language barriers. Polish can help good work travel. It just tells the buyer less about who did the thinking. Columbia Business School
So enjoy the demo. Then ask what it has not shown you.
Pay attention to what the partner asks
Suppose the brief says, “We want to automate customer support.”
One partner hears a request for a support assistant. Another asks to see the reasons customers contact the company, how those contacts are resolved, and which cases take the longest. The second conversation may discover that agents already answer quickly. The delay comes later, when a refund needs approval from someone in another department.
In that company, better language generation will not fix the bottleneck. The original brief pointed at the visible part of the process, not the part causing the delay.
Those questions show how the partner forms a view of the business before the solution hardens around the brief. Asking what happens after the AI produces an answer keeps the conversation tied to an outcome. Asking who can override it exposes the question of authority. Actual exceptions are worth inspecting too, because the average case is rarely where a project becomes expensive.
There is an opposite failure mode too: discovery theatre. A team can ask dozens of questions, fill a whiteboard with arrows, and still learn nothing that changes the recommendation. Thoroughness is not the same as judgment.
The useful partner filters. They notice which detail would alter the approach and which can wait until later. You should be able to hear that filtering in the conversation: “If your policies disagree, we need to solve that first. If the issue is only formatting, we can handle it inside the workflow.”
That is much more revealing than how many workshops appear in the proposal.
Ask what has to be true here
“Have you done this before?” is a fair question. Unfortunately, it often produces a case study rather than an answer.
Previous work can show that a partner has seen similar methods and failure modes. It cannot tell you whether the conditions transfer. The same support assistant may work well in a business with stable policies and fail in one where relationship managers make exceptions every day. An invoice workflow can perform beautifully until it meets the small set of documents where a classification error triggers a contractual dispute.
A better question is: “What has to be true for this approach to work here?”
The answer should sound specific. Perhaps the project needs one authoritative policy source. Perhaps the integration depends on permissions that the security team has not agreed to grant. Perhaps the business needs somebody with enough authority to own the exceptions. These are not caveats added to protect the consultancy. They are part of the recommendation.
The same applies to a pilot. “We can build it in four weeks” says something about speed. It says nothing about what the company will know at the end of those four weeks. Ask which decision the pilot is meant to change. If there is no answer, the pilot may produce an impressive object and leave the original uncertainty untouched.
What does that claim mean for your project?
Pick something you have heard from a potential AI partner. It may be true. The follow-up question helps you find out what it means here.
Choose a claim to find the next question worth asking.
None of the claims in the tool is automatically a red flag. The point of the follow-up question is to pull the claim out of sales language and put it inside the client’s actual situation.
Turn a broad ambition into a decision
“Use our data better” is not a bad starting point. Neither is “find a useful AI project.” Companies often seek outside help precisely because the problem is not clear yet.
Still, the engagement has to get beyond the ambition.
Imagine that a sales team wants AI to prioritize accounts. The first question might be whether the historical data can distinguish a promising account from one that simply received more attention from salespeople. If it cannot, choosing a model is premature. The immediate decision is whether the company should repair how it records sales activity, run a smaller test with cleaner evidence, or drop the idea.
That may sound less exciting than an account-scoring demo. It is also a decision the company can act on.
We think this is one of the clearest signs that an external partner understands the assignment. They can take a broad request and return something more precise without pretending the uncertainty has vanished. The client knows what choice sits in front of them, what evidence would help, and what work can safely wait.
The partner has done more than translate business language into technical requirements. They have improved the question.
Expertise shows up when the information runs out
Every serious project has a point where the available evidence stops. A data set is incomplete. Two teams disagree about the desired outcome. Nobody knows whether users will trust the recommendation enough to act on it.
This is the part that polished proposals tend to smooth over. It is also where the client most needs judgment.
A capable partner does not respond to every gap in the same way. Some unknowns can be resolved with a short test. Some need a business owner to make a choice. Others are unlikely to affect the recommendation and can remain open for now. The work is deciding which is which.
We are wary of a proposal that quietly converts every unknown into an assumption. A partner who refuses to recommend anything until the client supplies perfect information is not much help either. They should be able to say, “We do not know this yet, but this is the cheapest honest way to learn it,” then explain what they would do if the result goes the other way.
A Harvard Business School field experiment involving more than 2,000 innovation proposals found that narrative AI recommendations could persuade evaluators even when the recommendation was wrong. Objective screening criteria led to better alignment between human and AI judgments. The problem was not the existence of a fluent rationale. Evaluators gave the rationale more weight than the underlying evidence warranted. Harvard Business School
The same caution belongs in a consulting decision. You should be able to follow the route from evidence to recommendation. Which facts came from the client? Which parts are assumptions? What alternatives did the partner reject, and why? A recommendation becomes much easier to trust when you can also see how it could change.
What to take into the next conversation
AI has not made every consultancy the same. It has made prepared-looking work cheaper. Strong teams benefit from that too, which is why polish alone cannot tell you much in either direction.
Take the demo seriously, but keep its claim narrow. Notice whether the partner’s questions uncover something that was missing from the brief. Ask what must be true in your company. Somebody else’s case study cannot answer that. When information is missing, listen for a reasoned next step instead of automatic confidence or endless caution.
By the end of a good early conversation, you may know less about the final system than the most confident vendor promised to tell you. You should know considerably more about the decision in front of you.
For us, that is the test. A partner understands your business when they leave you with a better account of the problem, including the parts that make the solution harder to sell.