Resources · June 2, 2026
Questions to Ask Before Hiring an AI Consultant
Eight questions that separate consultants who ship from ones who slide. Use these before signing anything — including with us.
By Tom Faries
The most important thing to check before hiring an AI consultant is whether they can show you specific, named, verifiable outcomes — not “a mid-size company in the professional services space” but a real client, a real workflow, and real before-and-after numbers.
Everything else follows from there.
Vague case studies are a tell. They usually mean one of two things: the results weren’t strong enough to quote, or the consultant doesn’t have permission to name the client because the work was done by a larger firm they were staffed through. Both matter. If a consultant can’t hand you a reference, you’re buying a promise, not a track record.
The questions below are designed to help you test that — and to surface the other things that separate consultants who ship from ones who accumulate monthly retainer invoices.
Use them in your next evaluation conversation. Some of the good answers will sound like us. Some of the good answers will sound like other firms. That’s fine. These are questions worth asking regardless.
1. Can you show me a named case study with specific numbers?
Why it matters: Results without specifics are unfalsifiable. “Reduced manual work” could mean two hours a week or two minutes. Without a client name and a number, you have no way to verify the claim or call the reference.
Good answer: “Yes — we worked with [company name] on their [specific workflow]. They were spending X hours a week on Y. After the build, that dropped to Z. Here’s the contact if you want to call them.” See our case studies for examples of what this looks like in practice.
Bad answer: “We’ve worked with a number of clients in your space and seen significant efficiency gains across the board.” Follow up: “Can you name one?” If they can’t, that’s your answer.
2. Who actually does the work?
Why it matters: Many consultancies sell with a senior person and staff with a junior one. The person on the sales call presents the strategy; someone else writes the code, builds the workflow, and talks to your team every week. That’s not inherently wrong — unless you thought you were buying the senior person’s time.
Good answer: “I do. On a project this size, here’s how my time breaks down by phase.” Or, for a larger firm: “Here’s the team — here are their backgrounds — and here’s how the senior consultant stays involved through delivery, not just kickoff.”
Bad answer: “Our team handles implementation.” Ask who specifically. Ask for their backgrounds. If the answer gets vague or defensive, that tells you something.
3. What does success look like, in writing, before we start?
Why it matters: Projects without written success criteria almost always drift. The scope expands, the timeline slips, and at the end nobody can agree on whether the thing worked. A consultant who won’t commit to written criteria before the engagement starts isn’t confident in the outcome — or isn’t planning to be held to one.
Good answer: “Before we build anything, we write down what the current process costs in hours, who it affects, and what success looks like in those same units. We don’t start the build until both sides have signed off on that document.”
Bad answer: “We’ll define success metrics as we go based on what we learn.” Learning as you go is fine. Not committing to success criteria is not. These are different things.
4. What happens when it breaks?
Why it matters: Every automated system breaks eventually. A model changes pricing, an API endpoint shifts, an edge case nobody thought of hits production. What breaks a workflow isn’t usually the original build — it’s the first thing that changes after the build. You need to know who’s responsible for that before you sign anything.
Good answer: “For the first 90 days, we own it — bugs are fixed at no charge. After that, here’s the support model, here’s the documentation we hand off, and here’s how your team can maintain it without us if they want to.” A consultant who hands off clean documentation is one who built something maintainable.
Bad answer: “We include some post-launch support.” How much? Who do you contact? What’s not included? If they can’t answer those specifically, the support exists on paper and not in practice.
5. Will you tell me not to automate something?
Why it matters: A consultant with platform relationships or a bias toward billable hours has an incentive to find automation projects whether or not automation is the right answer. The right answer is sometimes “don’t build this yet” — because the process isn’t stable enough, the volume doesn’t justify it, or the cost of maintaining it will exceed the time it saves.
Good answer: “Yes, and we do it regularly. Here’s an example of a project we scoped and then recommended against — here’s why.” If they can give you a specific example, that’s a consultant who isn’t just chasing scope.
Bad answer: Any hesitation, deflection, or “we always find ways to add value.” You want a consultant who will save you from a bad project, not one who’ll build it anyway.
6. Are you selling a platform, or solving a problem?
Why it matters: Some consultants are resellers or certified partners for specific tools — Zapier, Make, Monday.com, a particular AI vendor. That’s not automatically bad, but it creates a bias. Every problem starts to look like a nail when you only carry one hammer. A platform-agnostic consultant picks the tool that fits the job. A reseller picks the one they get margin on.
Good answer: “We’re not tied to any specific platform. Here’s a project where we used [Tool A], and here’s one where [Tool A] would have been the obvious choice but we used [Tool B] instead — here’s why.” Concrete trade-off reasoning is the tell.
Bad answer: “We’re a preferred partner with [vendor]” as the lead answer when you asked about fit. Or: every proposal they show you involves the same set of tools regardless of the problem.
7. What does your scoping process look like, and is it fixed or open-ended?
Why it matters: An open-ended retainer gives a consultant an incentive to expand scope. A fixed-scope project gives you a deliverable and an exit point — you can evaluate the outcome and decide whether to continue before committing more money. Not every engagement needs to be fixed-scope, but you should understand what you’re buying and why.
Good answer: “We start with a scoped discovery phase — here’s what it produces and what it costs. After that, implementation is fixed-price against a defined deliverable. If scope changes, we scope the change separately before we build it.” See our pricing guide for how we structure this.
Bad answer: “We typically work on monthly retainer and adjust as priorities shift.” That’s fine if you understand what you’re getting and why. It’s a problem if the scope was never defined to begin with. Ask: “What does the retainer produce, and how would we know if it wasn’t working?“
8. Can my team maintain this without you?
Why it matters: A system your team can’t maintain is a system you’ll be paying for indefinitely. Good consultants build for handoff — clean documentation, maintainable code or workflow logic, and a knowledge transfer that leaves your team capable of small fixes on their own. Consultants who build in dependency aren’t building for you, they’re building for recurring revenue.
Good answer: “Yes. Here’s what the handoff package looks like — [spec doc, runbook, training session, whatever they do]. Here’s a past client who took over maintenance after we finished. Call them.” In our legal staffing and CRE work, the handoff documentation is part of the deliverable, not an add-on.
Bad answer: “The system is complex — you’d probably want to keep us on retainer to manage it.” That’s sometimes true for genuinely complex infrastructure. It should never be the default answer for a workflow automation.
How to use these questions
Run them in sequence in a single 30-minute call. You’re not looking for perfect answers — you’re looking for specificity and consistency. A consultant who hedges on named case studies, gets vague about who does the work, and can’t describe a handoff process is telling you exactly what an engagement with them will look like.
The consultants worth hiring will answer these questions without flinching. Some will even have better answers than what we’ve described here. That’s the goal — find one of those, whoever it is.
If you want to run these against us, that’s what the free blueprint call is for. Thirty minutes. You ask the questions, we answer them specifically, and you walk away knowing whether we’re the right fit — or whether you should look elsewhere. Book the call.
Not sure which questions apply to your situation? Run your workflow through the 3-question vendor test first — it’ll clarify what you actually need before you talk to anyone.
More writing in resources, or get in touch.