Why "we want to explore AI" isn't a project brief

We get a version of this message regularly: "We're interested in exploring how AI could help our business. Would love to chat."

And we do chat. These conversations are useful. But there's a pattern that plays out often enough to be worth naming, because it costs companies time and money and produces disappointment on both sides.

The pattern: a company knows they want AI to do something for them. They're just not sure what. They engage a vendor to "explore" the possibilities. Six months and a significant budget later, they have a strategy document, a proof of concept that doesn't work in production, and a clearer sense that the vendor didn't quite understand what they needed.

"Exploring AI" isn't a problem statement. It's a starting point. And the earlier you move from exploration to specificity, the more likely you are to get something that actually works.

What "explore" usually means

When a company says they want to explore AI, they usually mean one of a few things:

They have a problem they suspect AI could solve, but they haven't validated that yet. This is the most productive version. The conversation that follows has real content: here's the problem, here's what we've tried, here's why we think AI might help. From there you can get somewhere.

They feel pressure to do something with AI and aren't sure where to start. There's legitimate anxiety in the market right now about falling behind on AI. This is understandable. But anxiety about AI in general doesn't become a project brief on its own.

They've seen AI do something impressive and want that for their business. "We saw a demo of X and want something like that." Sometimes this is specific and grounded; often it isn't, because the demo was built for a different context with different data and different constraints.

They genuinely don't know where AI could help and want someone to find the opportunities. This is the most honest version of "exploration," and there's a right way to do it. A structured discovery engagement with a clear scope and deliverables is different from an open-ended "explore and tell us what you find" arrangement.

Why vagueness is expensive

Vendors operating on a vague mandate have to make a lot of assumptions. They make them, usually without flagging them as assumptions, because making assumptions is how you make progress when the brief is unclear.

Those assumptions bake into architecture decisions, model choices, data requirements, and scope. When they turn out to be wrong — and some will — the rework is expensive and the conversation about why things didn't go as expected is uncomfortable.

The companies that get the most out of AI engagements are the ones that show up with a specific problem, concrete data, a clear sense of what success looks like, and a realistic understanding of what they can bring to the process. They don't need to know the technical solution. But they need to know what they're trying to solve.

What a useful starting point actually looks like

You don't need a complete brief before you talk to anyone. But before you commit time and money to an AI engagement, it helps to have answers to a few basic questions.

What process are you trying to improve or automate? Be as specific as you can. Not "our operations" — the specific workflow, who does it today, how long it takes, what the current error rate looks like.

What does the data look like? Is it structured or unstructured? How much of it is there? Is it clean and well-organized, or do you know there are quality issues? The data situation is often the most important constraint in an AI project, and knowing the rough shape of it early saves a lot of time.

What does success look like in concrete terms? Not "we want AI to help with X" — "we want to reduce the time spent on X from Y hours per day to Z, with this level of accuracy." If you can't define success, you can't evaluate whether you achieved it.

What have you already tried? Has anyone inside the company attempted to automate this? What worked, what didn't? Are there existing tools or vendors involved that any new system would need to work with?

You don't need complete answers to all of these. But the more you can bring to the first conversation, the faster you'll get to something useful.

The productive version of exploration

There is a right version of "explore AI for my business." It's a short, structured discovery engagement with a clear scope: here's what we're trying to understand, here's what we'll produce, here's how we'll know if it was useful.

An AI Automation Audit is designed for exactly this. One week, a systematic look at your workflows and data, a prioritized list of automation opportunities with realistic effort estimates, and a recommendation for where to start. It's not "explore AI in general" — it's "figure out specifically where AI makes sense for this business and what it would take."

That's the version of exploration that leads somewhere useful.

If you want to have a conversation about whether your situation is ready for something structured like that, book a discovery call. If you're still at the "I don't know what I want" stage, that conversation is still useful — it usually clarifies things quickly.