You Can't Automate a Process Nobody Can Describe

Almost every business owner who calls us says some version of the same thing. "We want to automate our process." Good. So we sit down and ask the obvious next question. "Walk me through how it works today." And that's where the room goes quiet.

Usually one of two things happens. Either nobody can finish the sentence, or three people give three different answers and start arguing about who's right. These are smart people who run a real business that makes real money. They just can't describe how it actually works, because nobody has ever had to write it down.

The process on paper is not the real process

Plenty of companies do have a process written down somewhere. A flowchart a consultant drew years ago. An SOP sitting in a shared drive. A slide from the new-hire training deck. It always looks clean. Order comes in, manager approves, warehouse ships, finance invoices. Box A to box B to box C. Very tidy.

Then you go and watch how the work really happens, and it looks nothing like the chart. People skip steps. Someone found a faster way two years ago and never told anyone. The real approvals happen in a WhatsApp group, not in the system. The official software gets updated at the end of the day to match what already got done by hand. The chart is the story the company tells itself. The real process is the messy thing that quietly keeps the lights on.

So where is the real process hiding?

It's not written down because it never needed to be. It got built up slowly, by people solving problems in the moment, and it lives in four places that don't show up on any chart.

None of this is a sign of a badly run company. It's how every business that grew the normal way actually works. The problem only shows up the day you try to hand that process to a computer, because a computer needs you to spell out every step, including the ones you do on instinct.

"It depends" is the most expensive phrase in the room

When we sit down and start mapping a process properly, the answer to almost every question turns out to be "it depends." Depends on the customer. Depends on the amount. Depends on the day of the month. Depends on who's on shift. Depends on whether the boss is around to say yes.

Those "it depends" answers are the real process. The clean chart only covers the easy 80% where everything goes to plan. The "it depends" is the messy 20% that nobody wrote down, and that 20% eats most of the real work. It's also exactly the part that breaks automation if you pretend it isn't there. You can't tell a computer "it depends" and walk away. You have to drag out every single "depends on what" and turn it into a rule.

What happens when you automate a process that doesn't exist

Here's where a lot of projects quietly go wrong. The client says "automate our process." A lazy vendor takes the clean chart at face value, builds exactly that, and gets sign-off because the demo follows the happy path perfectly. Everyone's pleased.

Then it goes live, and it breaks on day one. Real life shows up with all the exceptions nobody mentioned. The system has no idea what to do with the weird customer, the rush order, the partial payment, the return that came back damaged. Staff hit a wall, shrug, and go straight back to the old spreadsheet. Now you've paid good money to automate a process that never really existed, while the real one carries on in the background untouched. We've written before about how software built for the boss instead of the users gets quietly abandoned, and how staff resist systems that don't fit how they actually work. This is the root cause underneath both.

The discovery is the hard part, not the code

People think the difficult bit of automation is the building. It isn't. Anyone can build boxes that pass data around. The hard part is getting the real process out of people's heads and onto paper, exceptions and all. We've said it plainly before: coding is the easy part. Figuring out what to build is the job.

That means sitting with the people who actually do the work, not just the manager who describes it from memory. It means watching them do a real day, asking "what do you do when this goes wrong," and hunting down every side spreadsheet and WhatsApp group. Half the time, the people doing the work have never said any of this out loud, so it comes out slowly, one "oh, and sometimes we also..." at a time. That conversation is the project. The software is what you build after you finally understand the answer.

The whole business is often in one person's head

Very often the real process lives almost entirely inside one long-serving staff member. The person who's been there fifteen years and just knows. Knows which customers pay late, which supplier to call when stock runs short, which approval you can skip and which you absolutely cannot. They don't follow the SOP. They are the SOP.

When that person takes leave, the place slows down. If they ever quit, you're in real trouble. Forcing the process out of their head and into something written is worth doing on its own, before a single line of code gets typed. Most owners only find out how much of their business was riding on one person the day we sit down and try to write it all out.

What good actually looks like

None of this is hard in a clever way. It's just work that most vendors skip because it's slow and unglamorous and doesn't look like progress on a Gantt chart. Here's what doing it properly looks like.

This is how we run it at Heartbyte, and not to pad the bill. We do it because building software on top of a process nobody actually understands is the fastest way to waste everyone's money. Get the real process on paper first and the build becomes the easy, predictable part. Skip it, and you're guessing with a budget.

The honest version

When a business says "we want our process automated," what they usually mean is "we want someone to finally figure out what our process even is." The software is the last 20%. Working out how the business truly runs is the first 80%, and it's the part that decides whether the whole thing works or sits unused.

The companies that win at automation aren't the ones with the fanciest tools. They're the ones who got honest about how their business actually runs, wrote it down, and fixed the messy bits before pointing a computer at them. That part you can do today, even before you pick a vendor. Try to describe your own process, end to end, including every "it depends." If you can't, that's not a problem with the software. That's the first thing worth fixing.