Good AI consultants build things. Great ones can prove it. Here's how to tell the difference before you sign anything.
TL;DR: Most AI consulting engagements that disappoint end at the strategy document stage rather than a working implementation, and the gap between those two outcomes is almost always visible before the contract gets signed. The right questions to ask upfront aren't about certifications or methodology; they're about accountability: who builds what, how success gets measured, and who owns the result when the engagement ends. A consultant who's actually delivered working implementations answers those questions differently than one who hasn't.
There's a version of AI consulting that goes like this: a well-dressed person shows up with a compelling deck, walks you through a proprietary framework with three phases and several workshops, and leaves you with a document that explains, in considerable detail, what you should do next. The document is thorough. The recommendations are reasonable. And six months later, nothing has actually changed because nobody built anything.
This isn't a fringe experience. It's common enough that most business owners who've been through it recognize the pattern immediately, usually right around the moment the final deliverable lands in their inbox and they realize it's a PDF.
The AI consulting market has grown faster than the supply of people who actually know how to implement AI in a small business environment. Which means the burden of separating the builders from the deck-makers falls entirely on the buyer, before the contract gets signed rather than after. The good news is that the right questions cut through the noise quickly. A consultant who has actually delivered working implementations in businesses like yours will answer them very differently from one who hasn't.
Knowing which questions to ask is the whole game. This post covers what those questions are and what the answers should actually sound like.
The pattern is consistent enough to be predictable. A business identifies an AI opportunity, finds a consultant with an impressive website and a few recognizable client logos, signs a contract, and then watches the engagement produce a strategy document instead of a working system. The document is thorough. The recommendations are reasonable. And none of it gets implemented because the consultant's job ended at the recommendation stage and nobody clarified that upfront.
The reason most of these engagements disappoint isn't that the consultant was incompetent. It's that the scope was never defined clearly enough to hold anyone accountable for an actual outcome. The engagement started with tool selection instead of workflow definition, and by the time anyone noticed the deliverable was a document rather than a deployment, the contract was already wrapping up.
The missing piece is almost always accountability. Not in a blame sense, but in a structural one: a clear definition of what the engagement will actually produce, how success gets measured, and who owns the implementation when the consultant's retainer ends. Those three things, established before anyone signs anything, are what separate an engagement that delivers from one that produces a very well-formatted PDF and a firm handshake.
For the broader context on what successful AI implementation actually looks like before you hire anyone to help with it, The Part of AI That Actually Shows Up to Work is worth reading first.
Before any conversation about technology or approach, ask about outcomes in businesses that looked like yours.
The most useful question is also the most direct: can they describe a recent engagement where they built something, what specifically they built, how long it took, and what the measurable result was? Not a client name. Not a methodology overview. A specific workflow, a specific integration, and a number: hours saved, error rate reduced, cost recovered. A consultant who's actually done this work will answer that question without hesitating. One who hasn't will pivot to process.
Ask what percentage of their engagements end with a working implementation versus a strategy document or roadmap. This question makes some consultants uncomfortable, which is useful information. A lot of consulting practices do most of their work at the recommendation stage. That's not inherently wrong, but it matters enormously whether you're hiring someone to tell you what to do or someone to do it.
Industry familiarity is worth pressing on as well, especially for businesses in healthcare, construction, or financial services. A consultant who hasn't worked in your industry will spend part of your budget learning it. One who has will recognize the compliance constraints, the operational realities, and the integration challenges before you have to explain them.
Once you're satisfied with the track record conversation, shift to what the engagement will actually deliver. This is where a lot of buyers get vague answers without realizing it.
Ask specifically what you'll have at the end of the engagement that you didn't have at the beginning. Push for something tangible: a configured workflow, a tested integration, documented processes, trained staff. "A comprehensive AI strategy" is not a deliverable. It's a document. If the consultant can't describe the concrete output clearly and specifically, the engagement probably won't produce one.
Ask what they need from you to make it work. Good consultants know exactly what preconditions their work requires: clean enough data in the right area, access to the relevant systems, an internal champion who can make decisions, and dedicated staff time during the implementation. A consultant who doesn't ask about these things early is either overconfident or underselling the complexity of what they're proposing. Either way, it's worth knowing before you sign.
And ask how they handle situations where the initial plan isn't working. This one reveals more than almost any other question. The right answer describes a specific process for identifying problems early, adjusting scope, and communicating transparently. A vague answer usually means they haven't had to answer it seriously before, which is its own kind of answer.
For any AI implementation that touches customer data, financial records, or regulated information, the security conversation needs to happen before the contract is signed. Not during onboarding. Not after the first workflow goes live. Before.
Ask where your data goes once the tool processes it. Does it leave your environment? Does the vendor use it to train their models? What happens to it if you end the engagement early? These aren't gotcha questions. They're the ones any serious consultant should be able to answer without pausing to check with someone else. If they can't, that's a meaningful data point about how they've been operating with other clients.
For businesses in healthcare, finance, or legal services, push further. Which compliance frameworks have they actually worked within, and how did that shape the implementation? The answer should be specific and grounded in real experience, not a general statement about taking data security seriously. Anyone can say they take security seriously. Fewer can describe exactly how a HIPAA-compliant workflow gets architected differently than a standard one.
The businesses that get burned on this aren't usually the ones that asked these questions and got bad answers. They're the ones who didn't ask because the topic felt awkward to raise. It isn't. A consultant worth hiring will welcome it.
The question that matters most in any consulting engagement is also the one that gets asked least often: Who owns and maintains the implementation once the consultant is gone?
If the answer is "you'll need to call us," that's a support contract, not an implementation. A well-delivered engagement leaves the business with documented processes, a trained internal owner, and a system they can actually support without ongoing consultant dependency. That outcome should be explicit in the contract, not assumed.
Ask specifically about knowledge transfer: what documentation gets produced, who gets trained, and what the handoff process looks like. A consultant who's genuinely trying to solve the problem will have a clear answer. One who's more interested in remaining necessary to it will get vague. That distinction is worth knowing before you've already paid for the work.
A few things worth paying attention to before you sign anything, regardless of how polished the pitch was.
Watch for vague deliverables attached to concrete price tags. If the contract specifies hours and dollars without describing what actually gets built, that's not an oversight. Engagements without clear outputs have a reliable tendency to produce unclear outputs. The scope expands, the deliverable shrinks, and by the time anyone notices, the retainer is already spent.
No references from comparable businesses is another one. A client logo on a website proves very little. A reference from someone in your industry who can describe a specific workflow that got built and what it actually saved is much harder to manufacture. If they can't produce one when you ask, that's worth sitting with.
Be skeptical of anyone who resists a pilot or phased approach. A consultant who genuinely believes in their methodology is usually fine starting small. One who needs you to commit to the full engagement upfront before proving anything is telling you something about where their confidence actually lives.
And the one that's easiest to miss: if the first conversation is about which AI platform to buy before anyone's looked at which workflows actually need fixing, the engagement is already starting in the wrong place. Tools before workflows is almost always a red flag, whether it's a consultant pitching it or a vendor demo that made it look easy.
The AI consulting market isn't short on people who can explain AI compellingly, build a convincing framework, and leave you with a document that feels like progress. What it's shorter on are people who will sit down with your actual workflows, your actual data, and your actual systems, and build something that runs without them when the engagement ends. We've covered what separates those two types of consultants and how to tell them apart before you've already written the check.
The businesses that get burned by bad consulting engagements rarely saw it coming in the pitch. The warning signs were there, in the vague deliverables, the resistance to a pilot, the proposal that led with tools instead of workflows. They just didn't know what to look for yet. Now you do.
Succurri's AI implementation work isn't theoretical. We've built workflows, configured integrations, and handed off documented systems to clients who can actually run them without calling us back. When someone asks us the questions in this post, we don't get uncomfortable. We get specific.
The right AI consulting partner doesn't just have answers. They have receipts. Talk to Succurri today and find out what a real implementation conversation actually looks like.
1. How much should AI consulting cost for a small business?
It varies widely based on scope and whether the engagement includes implementation or just strategy. Project-based implementations for small businesses typically range from a few thousand dollars for a single workflow automation to significantly more for multi-system integrations. The more important question than cost is what you'll actually have at the end: a working system or a document.
2. Is it better to hire a standalone AI consultant or work with an MSP for AI implementation?
For most small businesses, an MSP with AI implementation experience tends to make more sense. The MSP already knows your infrastructure, your compliance environment, and your systems. A standalone consultant who doesn't know your stack will spend part of your budget getting familiar with it, which is time you're paying for without getting much back.
3. How long should a typical AI consulting engagement take?
A well-scoped single-workflow automation typically takes four to eight weeks from assessment to working implementation. Be skeptical of timelines that are either unrealistically short or open-ended with no defined milestones. Both are signs that the scope hasn't been thought through carefully enough, which usually means the deliverable hasn't either.