When a client enters an AI engagement, they typically arrive in one of two ways. They know exactly what they want: a custom AI build, an automation, an agent. They’ve seen, read, or heard something. They have a spec in their head.

Or they don’t know where to start. They know something is broken or slow or costing them money, but the solution is a blank page.

Here’s what fifteen years of watching businesses try to innovate taught me: the first type is often wrong about what they need. The second type almost always finds a better answer than they expected.

Either way, the job starts in the same place: diagnosis, not delivery.

The Four Things Every Business Actually Needs

Before any tool gets selected, any agent gets built, and any workflow gets automated, four foundational questions have to get answered.

Process first. What’s broken? Not “what tool do we need” but “where does value leak out of this operation?” AI layered on a broken process doesn’t fix the process. It automates the dysfunction and makes it faster.

Workflow automation second. Once the process is clean, what manual steps are eating up your team’s week? Repetitive, rule-based, predictable work that humans are doing because no one has set up the system to do it for them.

Data structure third. Where does information live? If the answer is “everywhere”, spreadsheets, inboxes, shared drives, people’s heads, you have a data problem, not an AI problem. Everything downstream depends on having one source of truth.

AI integration fourth. Now you layer intelligence on top of the foundation you’ve built. Agents, automations, decision logic. This is the part clients want to talk about first. It’s the last thing that should get touched.

Everything else is execution.

Three Ways an Engagement Actually Unfolds

Once the diagnosis is complete, the build typically falls into one of three patterns.

Full custom build. The client is running on Excel sheets and shared folders. There’s no infrastructure to build on, so you build it. Database, workflows, automations, the full stack. This is a ground-up engagement where the first win is just getting the business’s data into a structure that works.

Fix and implement. They have existing infrastructure. It’s messy, redundant processes, disconnected systems, and manual steps that shouldn’t exist. You clean up the foundation first, then build on top of something that actually functions.

AI and automation layer. The tech stack is solid. They just need intelligence added on top. No rebuild required. This is the fastest engagement to execute and the one where ROI shows up quickest, because the foundation is already there.

And sometimes it’s a hybrid. A full custom build for one department that then needs to connect directly into an existing ERP or CRM. New infrastructure and legacy systems running together. That’s more common than most people expect, especially in larger organizations.

What This Looks Like in Practice

A manufacturing client came to me with a customer service problem. New purchase orders were coming in through email, getting manually captured, manually entered into a spreadsheet, and then manually moved into a pre-production draft. Three separate human touches on a single piece of information that should have moved itself.

We automated the full handoff. Customer service emails came in, the system read them, extracted the PO, added it to the spreadsheet, and pushed it directly into the pre-production draft. Manual capture was gone.

The efficiency gain was real. But the outcome that mattered to the client wasn’t efficiency — it was that they recovered a full day of lead time. Orders that used to take an extra day to get into production were now in the queue within minutes of the email arriving. Client satisfaction went up. That’s the number they cared about.

The engagement was a fix and implement. The process existed. It had redundant steps baked in. The fix wasn’t a technology decision; it was a process redesign that technology then executed.

A different client, a print shop, came in with no clear idea of what they needed. They knew customer communication was a friction point. We started with a text AI agent, something simple that could handle inbound inquiries and route them correctly. As the business saw what was possible, we evolved it. Text became text and voice. The system grew as the client’s understanding grew.

They didn’t know they needed a voice agent on day one. They needed someone to start small, prove value, and build toward what actually fit the operation.

The Mistake Most AI Consultants Make

Taking the brief at face value.

The client says, “We need a custom AI build.” The consultant scopes a custom AI build. Sometimes that’s exactly right. Most of the time, especially when the engagement involves doing something the business has never done before, the client is describing a symptom or a solution they’ve heard about, not the actual problem.

Innovation is unfamiliar territory. When someone is doing something new, they don’t have the reference points to know what they need. That’s not a client failure. That’s the nature of the territory.

The consultant’s job, before any code gets written, before any tool gets selected, is to figure out what’s actually going on. What’s broken? What does the data look like? Where is the friction?. What would an outcome actually feel like to this business?

Most of the time, the real answer is cleaner than what they walked in asking for.

Where to Start

If you’re an executive trying to figure out where AI fits in your operation, start with the process, not the tool. Find where time and value are leaking. Get the data into one place. Then have the conversation about what AI can do on top of that foundation.

If you’re working with a consultant on an AI engagement, the right first question isn’t “what are we building?” It’s “what problem are we actually solving?”

The answer to that question determines everything else.