Get in touch

Process automation that starts at the right end

Automating the wrong process is expensive. Here's the method I use to find the processes worth automating, automate them and make sure the gains stick.

It’s easy to automate the wrong thing. A process that takes a long time but runs twice a year gives you almost nothing back. One that takes five minutes but runs ten times a day can give you half a working day a week. The difference only shows when you count, which is why process automation starts with counting, not with tools.

What is process automation?

A process is a series of steps that happen roughly the same way every time. An inquiry becomes a quote, which becomes an order, which becomes a delivery and finally an invoice. Often several people and several systems are involved along the way.

Process automation means the steps that don’t need judgment run on their own. Information moves between systems, documents get created and the right person gets a signal when it’s time to act. What people do is make decisions and handle the exceptions.

The method in four steps

1. Map

Take one real case and follow it from start to finish. Write down every step, who does it and in which system. Pay special attention to every time the same information gets typed in again or passed on by hand. That’s where the time usually hides, and it’s rarely where you’d expect.

2. Measure

Estimate how long each step takes and how often the process runs. Time multiplied by frequency gives you a number per week or month. Look at the mistakes too. A step that often goes wrong costs more than the time it takes, because someone has to fix it and a customer ends up disappointed. The process with the highest number and the most mistakes is your first candidate.

3. Automate

Start with the smallest step that removes the most. Usually that means connecting the systems so information moves on its own, through their APIs. Sometimes AI belongs in one of the steps, for example to read an inquiry that arrives as free text in an email. The point is to build something small that works, rather than something big that’s meant to do everything.

4. Follow up

Measure again after a few weeks. Did it get as much better as you thought? Make sure the exceptions are visible too. An automated process that silently drops a case is worse than a manual one, so someone should always hear about it when something didn’t go through. Then move on to the next process.

Process automation or RPA?

RPA, robotic process automation, uses software robots that click through programs the way a person would. They open windows, copy fields and press buttons. It can be the right tool when an old system has no API and can’t be connected any other way.

But the robots are fragile. If someone moves a button or renames a field, they stop working. That’s why I’d rather connect directly to the systems’ APIs when possible. It talks to the system instead of the screen, and it lasts much longer.

Which processes fit best?

Processes that run often, follow the same rules every time and move information between several people or systems. A few classics:

  • Quotes. From inquiry to finished quote, without looking up the same details every time. More in the article on automating quotes.
  • Orders. From purchase to delivery without retyping. See system integration.
  • Invoicing. Orders and hours that turn into invoices on their own.
  • Reports. Numbers collected and compiled without anyone pasting them together.
  • New customers or employees. Accounts, documents and welcome emails created in the right order.

Where should you start?

With one process. Pick the one that runs most often and annoys the most people. Get it right, measure what it gave you and move on to the next. It sounds slow, but it’s the fastest way to actually get somewhere. Big automation projects that try to solve everything at once have a habit of never getting finished.

If you want help with the mapping, that’s often where I start with new clients. One call is usually enough to see where it’s worth putting the effort.

Updated 29 September 2026

Where it started for me

In 2011 a freight forwarder ran every shipment in one shared spreadsheet that only one person could edit at a time. Replacing it with a real system was my first automation project.

  • 2011
  • Spreadsheet to system
  • Everyone at once
Read the case study →

Common questions

What is process automation?

Letting the steps in a work process that don't need judgment run on their own. Information moves, documents get created and the right person gets told what to do, while people handle the decisions and the exceptions.

How is it different from RPA?

RPA uses software robots that click through programs the way a person would. It's useful when an old system has no API. Connecting systems through their APIs is usually more reliable, because it doesn't break when someone moves a button.

Which processes are best to automate?

The ones that run often, follow the same rules every time and move information between several people or systems. Quotes, orders, invoicing and reports are the classics.

How do I get started?

With one process. Pick the one that runs most often and annoys people most, follow one real case through it from start to finish and count where the time goes. That's your first candidate.

So what keeps grinding your gears?

I like hearing about the problems companies run into. Ideas for fixing them usually show up fast. No strings attached.