The problem with most AI consulting engagements
The market for AI consulting has expanded faster than its quality controls. For every practitioner who starts with a genuine understanding of your business and designs accordingly, there are many more who lead with tools, demos, and implementation timelines without first understanding what problem they are actually solving.
The result is a predictable pattern: an organization hires a consultant, gets a deployment, and six months later finds that adoption is low, the workflow problems it was supposed to solve are still present, and the tool is being used informally by a handful of people rather than embedded in any real process.
This is not a technology failure. It is a scoping and diagnosis failure. The best way to avoid it is to ask the right questions before the engagement begins.
Before the questions: what a good engagement looks like
A useful benchmark before you start interviewing consultants: what should a well-structured AI consulting engagement actually produce?
The answer varies by scope, but at minimum it should include a clear picture of your current workflows (not just a vendor's view of them), a prioritized list of AI opportunities specific to your context (not a generic list of AI use cases), and a roadmap that is specific enough to execute — with sequencing, dependencies, and realistic outcomes.
These deliverables require diagnosis. They cannot come from a demo or from a consultant who has not spent meaningful time understanding your business. If an engagement starts with a deployment timeline before any of this diagnostic work is done, that is a red flag.
Ten questions to ask any AI consultant
1. "What does your discovery process look like before you make any recommendations?"
What you are listening for: A specific process involving your team and your workflows — not a generic questionnaire. Good consultants describe how they learn about your business before they design anything: stakeholder interviews, workflow mapping sessions, observation of how work actually gets done.
Red flag: The consultant glosses over discovery, leads with a standard methodology applied uniformly to every client, or mentions tools in the first breath before asking about your business.
2. "Can you walk me through how you approach workflow mapping?"
What you are listening for: A clear explanation of how they document and analyze existing processes before designing automation. They should be able to describe what they look for: where time is lost, where handoffs break down, what the inputs and outputs of each step are.
Red flag: The consultant does not map workflows at all — they ask what you want to automate and begin designing from that answer. This skips the step that tells you whether automation is the right solution, and if so, where to start.
3. "How do you decide which workflows to automate first?"
What you are listening for: A prioritization framework based on impact, feasibility, and organizational readiness — not on what the consultant's favorite tools are good at. They should be able to articulate how they score opportunities against each other and why sequencing matters.
Red flag: The recommendation is the same tool or approach regardless of the business's actual workflows. If a consultant consistently recommends the same solution to different clients, they are optimizing for their own delivery model, not your outcomes.
4. "What does success look like at the end of this engagement, and how will we measure it?"
What you are listening for: Specific, business-level metrics tied to your actual workflows — not platform usage statistics. A good answer might reference time saved on a specific process, error rate reduction, or cycle time for a particular workflow. The consultant should ask you this question back: what does success look like to you?
Red flag: Success is defined as "deploying the tool" or "getting the team trained." Those are activities, not outcomes. If the consultant cannot connect their work to a measurable business result, neither of you will know whether it worked.
5. "What happens if our team does not adopt the system after deployment?"
What you are listening for: Evidence that the consultant takes adoption seriously as part of the engagement — not as an afterthought. Good answers include change management built into the timeline, involvement of end users in the design process, and a clear transition plan.
Red flag: Adoption is the client's problem. If the consultant treats deployment as the end of the engagement and team behavior as someone else's responsibility, the risk of a shelf-ware outcome is high.
6. "Can you describe an engagement that did not go as planned, and how you handled it?"
What you are listening for: Honesty, self-awareness, and a description of how they course-corrected. Problems happen in every complex engagement. What matters is whether the consultant can identify what went wrong and what they did differently.
Red flag: The consultant cannot describe a single challenging engagement, or the story is entirely about external factors — client dysfunction, scope creep, bad timing — with no ownership of any part of the outcome.
7. "Will you recommend solutions other than AI if the analysis suggests they are a better fit?"
What you are listening for: Yes, and an explanation of when that has happened. The best technology consulting is technology-agnostic. If AI is not the right tool for a workflow, a good consultant says so. Sometimes a clearer SOP, a better-organized team, or a simpler software change is the right answer.
Red flag: The consultant cannot imagine a scenario where AI is not the answer. If the outcome of every engagement is an AI deployment regardless of the diagnosis, the diagnosis is not real.
8. "How do you handle tool selection? Do you work with specific vendors?"
What you are listening for: Tool selection comes after workflow design, not before. A good consultant chooses tools based on your specific requirements — integration needs, team technical comfort, budget, and workflow logic — not based on partnerships or familiarity.
Red flag: The consultant has preferred vendors and mentions them early. This is not disqualifying on its own, but tools recommended before workflows are mapped are tools recommended without an adequate basis.
9. "What does the first two weeks of the engagement look like?"
What you are listening for: Discovery, access to your team, and workflow mapping — not kickoff decks and roadmap presentations. The first two weeks of a well-scoped engagement should be almost entirely oriented toward understanding your business before any design begins.
Red flag: The first two weeks include presenting a generic AI strategy, demonstrating tools, or running a technical infrastructure review before business workflows are understood. Technical work before business design is a sequencing error with predictable downstream consequences.
10. "What will you need from our team, and what is our role in this process?"
What you are listening for: Meaningful involvement of your team in the design process — especially the people whose work will change. A good consultant treats internal knowledge as essential to the design, not as a background context dump. They should ask for access to the people who actually do the workflows in question.
Red flag: The engagement can be completed with limited involvement from your team. This almost always produces a system that makes sense to the consultant and does not reflect how your business actually works.
The "diagnosis before treatment" principle
The questions above are all variations on the same underlying standard: does the consultant diagnose before they prescribe?
A doctor who writes a prescription before examining the patient is practicing negligence, not medicine. An AI consultant who recommends tools before mapping workflows is doing the same thing — committing organizational resources to a direction that has not yet been validated by evidence.
Good consulting — in AI and in any domain — starts with understanding. It produces a diagnosis that is credible on its own, before any prescription is made. The prescription follows from the diagnosis. This is the model that produces sustainable outcomes.
This principle shapes every engagement at this practice. The AI Opportunity Blueprint begins with workflow mapping and a current-state assessment before any roadmap is developed. The goal is to be useful to you regardless of whether you choose to implement with this practice — because a credible diagnosis has value on its own.
What to do with your findings
After you have run these questions with two or three candidates, you will have a clearer picture of who is operating with a diagnostic process and who is selling a deployment.
For more on what a well-structured engagement looks like, the AI Opportunity Blueprint page describes the scope, deliverables, and sequencing in detail.
If you are not yet sure whether an engagement makes sense, take the readiness assessment first. It will tell you where your organization stands across four dimensions and what the right starting point is.
And if you want to run these questions with this practice — and evaluate whether we are the right fit — book a discovery call. No pitch. No pressure to buy. You will leave with clarity on whether there is a fit and what the next step would look like.