Every AI project I’ve worked on has started the same way. A client would come to us with an idea for a tool they had seen somewhere before. They also had a general sense that their team was spending too much time on a task that AI should be able to handle.
That part is usually right. The time is being spent. The problem is real. What’s less clear almost every time is what a good solution actually looks like for that specific business. That’s what the questions are for.
“What does the current process look like, step by step?“
This is always the first one, and it’s the one that people least expect.
Most clients come in describing the desired output, not the process that produces it. “We want to summarize customer feedback automatically.” Great. But who collects the feedback? In what format? From which channels? Where does the summary need to end up? What happens to it after that?
The answers to these questions determine almost everything. They determine whether the workflow is technically straightforward or genuinely complex. They determine whether an off-the-shelf tool fits or if something needs to be built. They also determine whether the problem is actually an AI problem or a misidentified data organization problem.
I’ve walked into more than one conversation expecting to set up an AI workflow and left recommending a spreadsheet.
“Who owns the output, and what do they do with it?”
An AI workflow that produces output that no one acts on is a cost center, not a useful tool.
Before designing anything, I need to know who the output is for, what decision or action it supports, and how the decision is currently made without the output. If the answers are vague, it usually means the workflow is solving a problem that has been described at a higher level of abstraction than it actually exists in the business.
This question also raises the issue of accountability. For example, if the AI summarizes a report and the summary is inaccurate, who is responsible for catching the error? Who is responsible for ensuring the output is accurate enough to act on? AI workflows require a human in this role until the system’s reliability is well understood. Skipping that conversation can lead to quiet failure, where an automated process runs for months, producing output that nobody trusts, but that nobody questions because they are too busy.
“What does the data actually look like?“
This is where most AI projects encounter their first real obstacle.
The demos always use clean, structured, and well-formatted data. Reality is usually messier: Documents are in five different formats. Feedback is scattered across email threads, a CRM, and a shared inbox. There’s information that exists but isn’t accessible to the tool.
I ask to see a real sample before making any recommendations. Not a chosen example that looks good. I want a random ten from last month, including the awkward ones. That sample tells me more about the project than an hour of requirements discussion would.
It also sets expectations early on. If the data needs to be cleaned or restructured before an AI workflow can reliably process it, that work is part of the project. Clients who find that out after the tool is built tend to be more frustrated than those who hear about it upfront.
“What’s the acceptable error rate?”
Every AI system makes mistakes. The relevant questions are how many mistakes are acceptable in this context and what kind.
For example, a workflow that drafts internal meeting notes and gets one detail wrong out of ten is probably acceptable. However, a workflow that extracts figures from financial documents and gets one detail wrong in ten is not acceptable. The same level of accuracy can be acceptable in one situation and a serious problem in another.
This question also prompts a useful conversation about what happens when the system is incorrect. Is there a review step? Is the output clearly labeled as AI-generated, so the recipient knows to verify it? Are errors recoverable?
I’ve seen businesses deploy AI workflows without clear answers to these questions because the tool worked well enough during testing that no one thought to ask. The error rate only becomes apparent at production volume.
“What does success look like in three months?“
It’s not about “what features do you want.” Rather, ask, “How is the team’s work different?”
This question accomplishes two things. First, it grounds the project in a measurable outcome rather than a capability. Second, it reveals whether the client has considered adoption. A workflow that exists but that the team has stopped using after three months is not a success, no matter how well it was built.
I also use this question to calibrate scope. Some clients describe success in terms that require a simple tool. Others describe it in ways that imply something much more involved than what they initially asked for. Aligning on this early prevents the project from drifting in either direction.
What these questions have in common
None of them are about AI.
That’s deliberate. The technology is usually the easiest part of an AI project: It involves picking a model, wiring up an API, and building a pipeline. This work is well understood and, at this point, not particularly expensive.
What’s harder is the organizational and process side. Who owns what? What the data looks like. What success looks like. What success means. These questions determine whether an AI workflow is used and solves the intended problem.
Clients who have gotten the most value out of AI projects were willing to slow down and answer these questions before writing a single line of code or signing up for a tool.