u/Framework_Friday

When most business owners decide to start automating with AI, the first move is almost always the same. They look around at whatever is causing the most pain right now, the thing eating the most hours or generating the most complaints, and they point at it. That feels logical. If something is visibly broken and consuming resources, fixing it first seems like the obvious call.

The problem is that the most painful workflow and the highest leverage workflow are almost never the same thing. Pain is easy to see because it's loud. Leverage is harder to see because it's structural, and you only really understand it once you've mapped how work actually flows through your operation rather than how you think it flows.

What we found working across a portfolio of real operating businesses is that the workflows worth automating first tend to share a few specific characteristics. They sit at a handoff point between people or systems where information gets lost, reformatted, or delayed. They run on inputs that are already reasonably consistent and documented rather than highly variable and judgment-dependent. And they feed into downstream processes that are themselves relatively stable, so that when you improve the front end you're not just creating a new bottleneck one step later. Most businesses have two or three workflows that fit that description, and they're usually not the ones anyone was complaining about.

The other thing that trips people up is starting with something that requires the AI to carry too much context about how your business works before that context has been properly structured anywhere. This is how you end up with an implementation that works fine in testing and falls apart in production, not because the tool failed but because the information the tool needed to make good decisions was never captured in a usable form to begin with.

Getting the sequencing right before you build is genuinely most of the work.

They're failing because they started building before they had a clear picture of where they actually stood, and by the time that becomes obvious it's usually after two or three months of wasted effort and a team that's now skeptical of the whole thing.

The pattern we see most often is an operator who gets excited about a specific tool or use case, moves fast because the opportunity feels urgent, and then runs into the reality that the underlying operation wasn't ready to support it. The workflow they wanted to automate was never properly documented. The team didn't have a shared understanding of what the process actually looked like before AI entered it. Nobody had thought through who owns the output when AI is involved or what happens when it gets something wrong. So the implementation limps along, underperforms against the expectation, and everyone quietly agrees to revisit it later.

The frustrating part is that none of those problems are hard to solve. They just require working through them before you build, not while you're debugging a live system under pressure.

What actually needs to happen first is a clear read on three things: whether your workflows are documented well enough for AI to act on them reliably, whether your team understands what changes operationally when AI enters a process, and which workflow is actually the right one to start with given where your business is right now. That last one matters more than most people expect because the obvious answer and the right answer are usually different. The workflow that feels most painful is rarely the one that creates the most leverage when automated, and starting with the wrong one burns credibility with your team before you've had a chance to show what's actually possible.

We went through all of this the hard way across a portfolio of real operating businesses before we figured out a reliable way to sequence it, and the difference between the implementations that worked and the ones that didn't almost always came down to the work that happened before anyone touched a tool.