Field note
Questions to ask before hiring an AI consultant
Before hiring anyone to bring AI into your operation, ask which specific workflow they will fix, how they will prove your crew uses the result, what you will own when they leave, where your data goes, and what they refuse to do. A consultant who cannot answer those plainly is selling the idea of AI, not a working tool.
The pitch that could have been for anyone
An owner sits through a presentation from an AI consultant. There are slides about agents, automation and the future of work. There is a demo that writes an email and summarizes a document. There is a proposal for a discovery phase, then a roadmap, then a pilot. At the end, the owner still cannot say which part of the business will run differently, or when.
That pitch could have been given to a law firm, a hospital or a bakery. Nothing in it was about the owner's crews, trucks, jobs or invoices. That is the first warning sign, and the questions below are designed to surface it early.
We sell this kind of work, so read this with that in mind. These are the questions we would want a client to ask us, and we think any honest firm should be able to answer them.
A practical tip before the questions. Ask them in writing, and ask every firm you are considering the same ones. Spoken answers in a meeting drift toward what the room wants to hear. Written answers can be compared side by side, and they tend to be more careful. A firm that will not put its answers in writing before you sign will not be easier to pin down after.
Which workflow, who uses it, and what if they do not
Ask: which specific workflow are you going to fix? A good answer names it. Job tickets reaching the office. Quotes going out. Parts reaching the invoice. A weak answer talks about finding opportunities across the business.
Then ask: who will use the result, and in what conditions? A good answer names a group of people, a place and a moment. The technicians, at the end of each job, in the truck. A weak answer says "your team."
Then ask the hardest one: how will we know they use it? A good answer names a behavior and says where the count comes from. The share of eligible jobs completed in the tool before the end of the shift, counted from your own job records. A weak answer talks about logins, satisfaction surveys or a dashboard the consultant will build. If the only evidence of success comes from the consultant's own tool, you are grading their work with their pencil.
Ask: what happens to your fee if the crew does not use what you build? Most consultants will say that adoption depends on the client, and they are partly right. A vendor cannot make a crew show up for training.
But there is a difference between "adoption is your problem" and "adoption depends on these specific things from you, and if you provide them, part of our fee depends on the result." The second answer means the consultant has thought about what makes adoption fail and is willing to be accountable for their part. We put the final 20 percent of a Build fee behind a signed usage threshold for exactly this reason.
Also ask: what will you need from us? A good consultant can list it. A sponsor with authority. Access to systems. Clean enough data. Time for training. People who take part in the rollout. If they cannot list what they need, they have not done this enough times to know.
What you will own, and where your data goes
Ask: when you leave, what do we own? The answer should include your data, the production accounts the tool runs on, and the code built for you, with the copyright assignment in writing. Ask what they keep. Reusable methods and general components are a fair thing for a firm to keep. Your customer list running inside their account is not.
Ask: if you disappeared tomorrow, could someone else run this? The answer should be a handover pack you can see before signing: architecture, a runbook, a credentials inventory, a data map, and a list of the AI models and providers used.
Then ask about data, and get the answers in the contract. Which AI providers will see our information? Is any of it used to train models? Where is it stored, and who can reach it? How is it deleted when the engagement ends, and on what schedule? Be wary of sweeping promises here. A plain, specific answer that names providers and terms is worth more than a reassuring sentence.
What they will not do
Ask: what do you decline? This question reveals more than any other, because a firm that takes every job has no judgment about which ones will work.
Good firms decline things. We decline a request to use AI everywhere without a specific workflow, work with no executive owner, tools that would act outside the company on their own, and a data source that does not exist yet. We also decline, at the Spec stage, anything that controls safety-critical equipment, moves money without a person approving it, makes employment decisions or makes binding commitments to customers without a human approval step. You may draw the lines differently. The point is that the consultant should have lines, and should be able to tell you where they are.
Ask too: can your first phase end in a recommendation not to build? If every path in their process leads to a build, the discovery phase is a sales step.
And ask them to describe a project that did not go well. Every firm that has done real work has one. Listen for whether they can say plainly what went wrong, what part of it was theirs, and what they changed afterward. A firm with no failures to describe has either not done much, or has not learned from what it did. When you check references, ask to speak with someone who used the tool every day, not only the person who signed the contract.
Who does the work, and does it need AI at all
Ask: who will actually be on site, and who will write the code? Some firms sell with senior people and deliver with junior ones they have never met. You want to know who walks your floor, who builds the tool, and whether they are the same person or at least in the same room.
Ask what happens after launch. Who do we call when the tool stops working at six in the morning with a crew waiting? How fast will they respond, and during which hours? Who fixes it if the person who built it has moved on to another client? A good answer names a person or a role and a written support arrangement. A weak answer is a general support email.
Ask whether they have run operations work themselves. Someone who has dispatched a crew or closed a job ticket at the end of a long day will notice things in a site walk that a pure technologist will not.
Finally, ask: does this workflow need AI? A good consultant will sometimes say no. Many of the most useful workflow tools are a clean form, a good handoff and a notification at the right moment. AI earns its place when it reads messy input, drafts something a person approves, or sorts work by judgment. It does not earn its place because it is in the proposal title.
What to do next
Take these questions into your next vendor conversation, including one with us. If you are weighing an outside firm against a full-time hire, read our honest comparison of a workflow firm and an AI director. For what our own website records and what our portal does not, see our privacy page.
Questions people ask
What is the most important question to ask an AI consultant?
Which workflow are you going to fix, and how will we know our people use it? If the answer is broad, such as AI across the business, the engagement has no finish line.
Should an AI project always use AI?
No. AI is a way of delivering a tool, not the product. Many useful workflow tools need little or none of it, and a good consultant will say so.
What should I ask about my data?
Which AI models and providers will see it, under what terms, whether it is used to train anything, and how it is deleted when the work ends. Get the answers in the contract, not the pitch.
Is a free assessment a good sign?
Be careful with it. A free assessment is paid for by the sale that follows, so it tends to find a reason to buy. A paid specification can afford to recommend against building.