What an AI consultant should ask you

Most advice on hiring consultants gives you questions to ask them. Useful, but backwards: a pitch can be rehearsed, and the better a firm is at sales the smoother their answers will be.

Their questions are much harder to fake. Someone who has diagnosed real operations asks about things a newcomer would never think to raise, and you can hear it inside ten minutes.

Here is what should come at you in a first conversation.

About how work actually moves

Where does a piece of work enter your company, and what happens to it? Who touches it, in what order, and where does it wait?

A good consultant is trying to find the queues. Almost every automation opportunity in a normal business is a place where something sits waiting for a person to notice it, and you cannot find those from an org chart.

Expect them to ask what happens when somebody is on vacation. That question sounds like small talk and it is not: the answer usually reveals the one person who is holding an undocumented process together.

About the same thing being done twice

What gets typed into more than one system? Where does a spreadsheet sit between two pieces of software?

Duplicate entry is the most common finding in this kind of work and the one clients least often volunteer, because it has been happening for years and stopped registering as a problem. Someone who asks about it directly has looked at operations before.

About volume and frequency, not importance

How many of these do you handle a week? Is it ten or four hundred?

This is the question that separates real prioritization from theater. A painful process that happens twice a month is usually not worth automating, and a boring one that happens two hundred times a week often is. If nobody asks you for counts, nothing in their recommendation can be ranked. Prioritization is the whole game.

About what happens when things go wrong

What does your team do with an exception? How often does that happen, and who decides?

Automation handles the standard case. The economics of every project live in the exception rate, because a process that is ninety percent predictable and ten percent judgment needs a very different design from one that is uniform. A consultant who does not ask about exceptions will build something that works in the demo.

About your data, unprompted

Where does customer information live? How many places, and do they agree with each other? Is there one identifier that links them?

This should come from them without you raising it, and it should come early, because it is the largest cost driver in the entire project. Someone who asks about your systems but not about whether those systems agree has not done an integration.

They should also ask what they are allowed to touch, what is sensitive, and what cannot leave your environment. If that conversation only happens because you started it, take note.

About who decides

Who signs off on a change to this process? Whose job changes if it works?

The second question is the important one and it is the one nobody wants to answer honestly. A project that makes a team's work invisible will be resisted, quietly and effectively, and a consultant who has been through that will ask about it before scoping anything.

About what you already tried

Have you attempted this before, with what, and what happened?

Most companies have a dead pilot somewhere: a tool bought with enthusiasm that nobody logged into after week two. That story contains most of what a consultant needs to know about your organization, and skipping it means repeating it.

About what you would not want automated

A genuinely revealing question, and rare. Some interactions are the relationship, and doing them with a machine damages something that does not show up in a process map.

Anybody who treats every human step as waste to be removed is going to recommend something you will regret.

About the number to beat

What does this cost you today, roughly? What would good look like?

Without a baseline nothing can be measured afterward, and a consultant who does not establish one has made their own work unaccountable. That is convenient for them. Measurement has to be designed at the start, not bolted on at the end.

The tell

Notice that almost none of these questions are about AI.

That is the point, and it is the fastest read available to you. A first conversation dominated by what the technology can do is a sales meeting. A first conversation dominated by how your company works is a diagnosis, and only one of those can produce a recommendation worth acting on.

If you want the mirror image, the questions worth asking them and the red flags cover the other direction.

Our first session is deliberately built around this list: we listen to how the operation runs before anyone mentions a tool, because the alternative is recommending what we already know how to build.