A client's onboarding process had someone copying and pasting LLM output into a Google Doc, by hand, every single time. That's not a technology problem. That's a workflow nobody had looked at from the outside.

What a Workflow Audit Actually Looks Like

Most people come to me thinking they need software. What they actually need is someone to sit with their process and figure out where it's bleeding time, and that's business process automation before any tool gets picked. The audit is the actual work. Everything after it is just building what the audit told you to build.

What I'm Actually Listening For on a Strategy Call

The strategy call isn't a pitch. I'm not there to sell anything on that first conversation, and I tell people that up front, because it changes what they're willing to tell me.

What I'm doing is diagnostic. We dig into what the client is wanting for their business, what they want to streamline or automate, and from there I'm digging for where the actual pain points are, kind of underneath whatever they think the problem is. Because what a business owner tells me the problem is and what the problem actually is are two different things a lot of the time. Someone will say their CRM is bad. The CRM is fine. What's bad is that three people are manually updating the same record in three different places because nothing talks to anything else.

Most problems trace back to one root cause, not a dozen separate ones. That's the thing I'm listening for on the call, not a list of complaints, but the single thread running under all of them. Usually it's information breaking down somewhere between two systems that were never meant to talk to each other. If you want to know what this actually looks like in practice, how the strategy call works is the page that walks through it start to finish.

Manual Data Entry Is the Root of Almost Every Workflow Problem

Here's the pattern, almost every time. Most of the workflow problems I uncover have to do with a lot of manual data entry, or transferring information from one platform to another by hand. Someone gets an email, types the contents into a spreadsheet, then copies that into a project management tool, then updates a client somewhere else manually. Every one of those hops is a place where something gets missed, mistyped, or just never gets done because the person doing it is busy.

Once I see where that's happening, there are really two fixes, and which one I pick depends on the platform itself. Sometimes it means we export the data and abandon a platform entirely, building something that actually fits what the client needs instead of forcing their business to bend around software that was never built for them, particularly when the platform is fighting you the whole way and forcing integration would only add more friction. Other times the existing system is worth keeping, and we build a webhook or some kind of integration into it, so information gets pushed or pulled automatically instead of retyped. Neither is the "right" answer on its own. It's a decision you make once you actually see how the platform behaves and what it's costing the business to keep it around.

Wonderfish's Onboarding Was Clunky, and That's the Point

Wonderfish is a good example of exactly this, because the fix wasn't glamorous. It was just so much manual input and clunky processes. Nothing was tight or consistent, which caused errors, because inconsistency always does. A lot of it was copying and pasting LLM output into a Google Doc by hand, every time, for every new client.

None of that information needed to be discussed live on a call in the first place. A lot of it was just facts the client already knew, sitting there waiting to be typed somewhere. So that information got moved into a form, automatically triggered once the engagement started, and the client filled it in on their own time instead of someone manually transcribing it during or after a call. That's what business process automation looks like in practice most of the time. It's not a dramatic overhaul so much as removing one repetitive, error-prone step and letting the system do it instead. Once you see where the friction actually is, systems built around how the client actually works is the natural next step, because the fix has to match the business, not the other way around.

Why Businesses Don't Catch This Themselves

I think most businesses don't do this step on their own because they built the process themselves, and it works. It serves a purpose, but working isn't the same as optimized, and once you're inside a system that's functioning, even badly, it's hard to get outside yourself to see where it's breaking down. You built the workaround, you know why it exists, and you've stopped noticing that it's a workaround at all anymore because it just looks like Tuesday.

That's usually where I come in. I show up as an unbiased observer, watching the workflow from outside so I can actually see the bottlenecks and the gaps in the flow, the places where things could open up and smooth out, the kind of thing that's easy to miss when you're the one running the process every day. A real workflow audit isn't about finding fault with anyone. It's about noticing what nobody inside the system has the distance to notice anymore.

The Real Aha Moment Isn't Dramatic, It's Just Surprise at What's Possible

People ask me what the biggest "aha moment" has been on a project, expecting some single dramatic reveal, but it's usually a more common thing I hear over and over: oh, you can do that? People don't realize what's possible with automation these days. If you're willing to build it, you can essentially build anything you can imagine at the moment.

That reaction shows up on almost every automation project I run, big or small. It's rarely one giant fix that changes everything. It's a string of smaller surprises, each one landing the same way: people just didn't know the option existed. Which is most of what the audit is for. Half the value is finding the problem. The other half is telling someone it's fixable at all.

The Audit Is the Part Most Automation Projects Skip

If you're reading this and recognizing your own business somewhere in it, you're probably running on processes that work well enough that nobody's stopped to look at them from outside. That's normal. It's also exactly the gap I described above, and it's not something you're going to see clearly from inside your own operation.

I've written before about fixing the workflow before connecting the tools, and this is really the same idea from the other side. You don't start with the tools. You start by seeing where the information actually breaks down, and everything else, the integrations, the automations, the AI, comes after that.

If you think your process is fine because it's working, it's probably worth a conversation anyway. That's usually where the real problems turn up.