The same thing happens with automation. Automating a process that does not work reliably will not make it work better.
So, how do you actually build the “perfect process”?
The perfect process is born from what is not scalable.
Which processes should you automate?
Before answering that, it helps to ask a more basic question: where does a process come from?
That is the key.
Whenever you start something from scratch, you begin with a small action that leads to a next step, and so on, until the cycle is complete. The next time you notice that the same actions, in the same order, solve a similar situation, you have the start of a process.
The important part is that not every process works at different scales.
This may sound abstract, so let’s use an example.
Imagine you sell t-shirts. Someone buys one as a birthday gift for that same afternoon. The delivery truck with the day’s orders has already left. Because you care about the customer and you want to solve the problem, once the workday ends you drive to the customer’s address and deliver it yourself.
Problem solved, but it is impossible to do that the day you have 100 orders that must be delivered before the end of the day.
Scale requires a different process.
Was it wrong to solve the first problem the way you did? No.
Every process should start in a non-scalable way. That is what helps you understand where the real pain point is in the situation you want to fix.
In every action, you can find the underlying problem. That is what allows you to design smarter actions when you scale.
For example, if we go back to the case above, once you have many orders per day, you could organize deliveries at midday and late evening. Two separate batches, aiming to deliver the highest number of orders per day while also optimizing routes.
Doing that creates new problems. In this case, costs might increase, which is why it becomes smart to add rules and filters.
If by 3pm you exceed 100 orders, you hire another van to deliver by the end of the day. Otherwise, the remaining orders move to the next day.
Then, you send an email that communicates the rule so each customer knows when the order will arrive. In the future, that email becomes another automation.
Little by little, you add actions that reinforce the base process.
Only once you can execute the process flawlessly without a single automation should you start thinking about workflow automation.
Technology should be a helper, a complement to what you already do well. It should never be the foundation of how you run operations.
Eliminate before you digitize
Before you automate any step, ask a single question: does this step need to exist?
It is a question people rarely ask. The energy usually goes to “how do we automate this?” without first asking “should this exist?”
The result is that companies automate approvals that add no value, notifications nobody reads, reports that generate themselves and end up in a folder nobody opens, and validations that duplicate controls that already exist elsewhere in the process.
Each of those steps has a cost: development time, maintenance, potential failure points, and added system complexity.
And none of it adds value to the customer or to the business.
The rule is simple: if a step cannot justify its existence with a concrete answer in one sentence or less, that step should be eliminated before anyone writes a single line of code.
What does not exist cannot fail.
What does not exist does not need maintenance.
What does not exist cannot slow down the process when something goes wrong.
Simplification is the cheapest and most underestimated stage of any business process automation project.