When to automate: finding processes worth building internal tools

Last month, I talked to a founder who wanted to automate everything. His team was drowning. Orders came in through email. Someone copied them into a spreadsheet. Someone else moved that data into their inventory system. A third person sent confirmation emails. Four hours a day, gone. He wanted software to fix it all.

But here's what I told him: not every broken process needs software.

Some need a better spreadsheet. Some need a new hire. Some need to be killed entirely. You made them five years ago, and since then, no one has questioned them.

But a few processes? A few are quietly bleeding hours and money every single week. Those are the ones worth building for. Those are the ones that pay back tenfold.

The question is, how do you know which is which?

I've spent years helping companies figure this out. Here's what I've learned.

The "Three People Touched It" rule

Watch a task move through your company. Count the hands it passes through.

A customer signs up. Sales mark them as closed. Then ops gets a Slack message. They set up the account. Then, finance sends an invoice. Three people. Three handoffs. Each handoff is a chance for something to go wrong.

This is what I call the Three People Rule.

If a task requires three or more people, you've found something worth automating.

It's not that handoffs are bad. Some work genuinely requires multiple specialists. But most handoffs exist because tools don't talk to each other. Or because the process grew organically and nobody designed it.

Here's how to spot these:

Pick any common task in your business. Client onboarding. Order fulfillment. Invoice collection. Now trace it. Literally draw it out if you have to. Where does it start? Where does it go next? Who handles it before it's finished?

If you see a ping-pong pattern, sales to ops to finance back to ops, that's your signal. Not necessarily to automate. But to analyse.

Ask yourself. Do these handoffs add value, or do they add steps?

The "We Just Know" problem

There's a woman at a logistics company I worked with. Let's call her Maria. Maria has been there for nine years. She knows everything.

When a shipment gets flagged, Maria knows which carrier to call. When a client complains, Maria knows their history without checking the system. When something weird happens with customs, Maria knows the workaround.

Maria is invaluable. Maria is also a liability.

Not because she's bad at her job. She's extraordinary at her job. That's the problem. So much of the company's operational knowledge lives in her head and nowhere else.

If Maria gets sick, things slow down. If Maria takes a vacation, people wait for her to return before making decisions. If Maria quits, and people do quit, the company loses years of knowledge built up over the years.

This is what I call "We Just Know" processes. They work beautifully because someone competent figured them out. But they're fragile. They don't scale. They can't be taught easily to new hires.

Here's how to find them:

Imagine your best operations person leaves tomorrow. What breaks first? What would a new hire have absolutely no idea how to do without asking someone?

That's where documentation should live. And often, that's where automation can help. Not to replace Maria, but to capture what Maria knows so the business doesn't depend on any single person.

The Copy-Paste audit

Watch where your team copies and pastes.

Between browser tabs. Between spreadsheets. From an email into a system. From one system to another system that should really be connected, but isn't.

I once watched an ops manager spend 20 minutes copying order data from Shopify to a spreadsheet. Then copying into their shipping software. Then copy the tracking numbers back into Shopify.

Twenty minutes. Every single day. That's over 80 hours a year or two full workweeks, spent copying and pasting.

This is manual integration. And it's almost always the highest-return automation target you'll find.

Why? Because there's no expertise required. A human being is doing robot work that a robot should be doing.

Here's how to audit this:

Ask your team, "What data do you regularly move from one place to another?" Then watch them work for an afternoon. You'll see it. Sometimes it requires a simple integration. Sometimes it's a small piece of custom software. But it almost always exists.

The "We Tried a Tool" graveyard

Every company has one.

The project management app that nobody updates anymore. The CRM that sales stopped using after three months. The automation tool which ended up creating more problems than it solved.

These failures aren't embarrassing. They're pointing at real problems.

Think about it. Someone at your company saw a pain point. They searched for solutions. They found software that promised to fix it. They bought it, set it up, and tried to make it work.

And it didn't.

Why not?

Usually one of two reasons. Either the workflow was too specific for off-the-shelf software. The tool required you to change how you work rather than fit into your existing workflow. Or the integration was too painful. The tool worked fine in isolation, but didn't connect to everything else you use.

Both of these point toward the same conclusion. The problem was real, but the solution was wrong.

Here's how to learn from your graveyard:

List the tools you've bought and abandoned in the last two years. For each one, answer two questions. What problem were we trying to solve? Why didn't this tool solve it?

Those problems haven't gone away. They're still costing you time and money. The difference now is you know what doesn't work, which gets you closer to what might.

How to prioritise what you've found

By now, you might have a list.

You can't fix everything at once. You shouldn't try.

Here's how I help companies decide what to tackle first. Three factors. Score each item on all three.

Frequency

‍How often does this happen? A process that runs daily beats one that runs weekly. Weekly beats monthly. The more frequent the pain, the faster the payback on fixing it.

Severity

‍Is this merely tedious, or is it actually dangerous? Being dangerous causes mistakes, loses customers, and creates compliance risks. Addressing such situations is the priority.

Visibility

Does this affect your customers or your revenue? Internal issues are important, but focus on processes that impact client experience.

A process that's frequent but low-stakes? A simple automation or even a better checklist.

A process that's severe but rare? Maybe documentation and training rather than software.

But frequent, severe, and visible? That's where custom tooling is most effective. That's where you build something.

What comes next

So you've spotted the processes. You've prioritised them. Now what?

You have options.

Some processes just need duct tape. A Zapier connection. A better spreadsheet formula. A simple integration you can set up in an afternoon. These are fine for frequent, low-stakes problems.

Some processes need better off-the-shelf software. Maybe the tool you tried before was the wrong one. Maybe a different product fits your workflow better. Worth exploring before you build anything custom.

But some key processes need to be done correctly and may require a custom internal tool.

Not because a custom internal tool is always better. It isn't. It's more expensive. It takes longer. It requires maintenance.

But when a core process can't rely on off-the-shelf solutions, and costs rise, a custom internal tool is sensible.

You know your business better than anyone. You feel where it's smooth and where it sticks. The framework I've shared here gives you a way to see those friction points more clearly.

Start with observation. Watch how work actually flows through your company. Not how it should flow. How does it do?

Then ask the questions. How many handoffs? What lives in someone's head? Where's the copy-paste? What tools did we abandon?

The answers will tell you where to look. The prioritisation will tell you where to start.

And if you find something too specific for off-the-shelf and too important for duct tape? That's usually when a conversation with a team like ours makes sense.

‍