When people talk about business automation, one of the first ideas that comes naturally is to take an activity that is currently carried out manually and make a system perform it automatically.
It is a correct way of thinking, but only up to a certain point.
Before automating a process, in fact, it is worth understanding whether that process still makes sense, whether it contains unnecessary steps, whether it comes from old habits or whether it exists only because two systems have never been connected.
A process may be slow because it is performed manually, but it may also be slow because it was designed badly.
If we take the wrong procedure and automate it completely, we simply obtain the wrong procedure being executed more quickly.
This is why automation should come after analysing the work, not before it.
THE PROCESS BEFORE AUTOMATION
Inside a company there are many activities that gradually become procedures.
A request arrives by email.
Someone reads it.
The data is copied into a management system.
A colleague is notified.
A document is created.
Later, a spreadsheet is updated and, at the end, someone checks that every step has been completed.
If we look only at the work of each individual person, every operation may appear correct.
The problem becomes visible when we look at the entire path.
To give a very simple example, a customer may fill in a form on the company website with their name, company, email address and reason for contacting the business. The data is already provided digitally, but a person receives it by email and manually enters it into the CRM.
We could automate the copy and paste.
But the question before that should be different: why does that information need to pass through email if the system receiving it can place it directly into the CRM?
This type of analysis is what separates real automation from simply accelerating an unnecessary step.
HOW COMPLICATED PROCESSES ARE CREATED
Many business processes were not designed at one single moment.
They grew over time.
A check is added because an error once occurred.
A new approval is introduced because responsibilities change.
An Excel spreadsheet is created to compensate for a function missing from the management system.
Someone starts sending an email to a colleague because the systems used by the two departments do not communicate.
After a few years, all these steps become normal.
People joining the company later learn them as they are and often no longer know why they were introduced in the first place.
This is one of the reasons why a procedure should be observed as a whole before it is automated.
It is not enough to ask each person what they do.
We need to understand why they do it, which information they receive, where it comes from, what they produce and who will use that result in the next step.
At that point, activities that no longer add any value often become visible.
DIGITALISING A STEP DOES NOT MEAN REMOVING IT
Digitalisation has made many processes faster, but it has also created a particular situation: old analogue procedures have often been transferred into digital tools without being truly redesigned.
A paper form becomes a PDF.
A signature on paper becomes a digital signature.
A register becomes an Excel spreadsheet.
A filing cabinet becomes a cloud folder.
These are all important improvements, but they do not necessarily change the process.
If someone previously entered the same information three times on three different sheets of paper and now enters it three times into three different software systems, the underlying problem is still there.
Only the tools have changed.
The same applies to automation.
Automating those three entries may save time, but it would be even better to understand whether those three copies of the same information are actually necessary.
In many cases, they are not.
STARTING FROM THE REAL WORK
When a company wants to automate a process, official documentation is useful but it does not always describe how the work is actually performed.
There is often a difference between the theoretical procedure and the operational procedure.
The procedure may say that an order is entered into the management system and then approved.
In reality, before the order is entered, someone may check an email, verify an Excel file, call the salesperson and consult a document stored in a shared folder.
These informal steps are often exactly what determines delays, errors and dependencies.
For this reason, analysis should begin by observing the real work.
Which tools are opened?
Which information is searched for?
Which data is copied?
Which decisions are made?
Where does someone have to stop because information is missing?
Where does a process wait for a response?
These are the points where the opportunity for improvement is found.
REMOVE BEFORE YOU AUTOMATE
An effective path is very simple to describe:
remove → simplify → integrate → automate → measure
First, remove the steps that are no longer needed.
Then simplify what remains.
Next, connect the systems that need to exchange information.
Only at that point does it make sense to automate what is still repetitive.
For example, imagine a procedure where a customer request is received by email, copied into a CRM, reported in a tracking spreadsheet and then sent to a technician.
We could build an automation that performs all four steps.
Or we may discover that the tracking spreadsheet exists only because the CRM has never been configured to display the status of the request.
By removing that step, the process becomes shorter before we automate anything.
This is a better result, because every step removed is a step that does not need to be developed, maintained, monitored or fixed later.
- Remove
- Simplify
- Integrate
- Automate
- Measure
INTEGRATIONS COME BEFORE MANY AUTOMATIONS
Many manual processes exist because the software being used does not communicate.
This is very common in companies that have adopted different tools over time.
Sales uses a CRM.
Administration uses an ERP.
Support works with a ticketing system.
Documents are stored in the cloud.
The website uses another platform.
Each system may be perfectly suitable for its own task, but the problem begins when information has to move across them.
If a person has to copy data from one system to another, that person is effectively doing the work an integration should perform.
Before creating a complex automation, it is therefore worth checking whether the systems provide APIs, webhooks, structured exports or other mechanisms that allow them to exchange information directly.
In some cases, a good integration removes entire manual stages without any need to introduce artificial intelligence.
EXCEPTIONS ARE PART OF THE PROCESS
A common mistake is to design automation only around the ideal case.
The customer fills in the form correctly.
The data exists.
The system responds.
The order is complete.
The procedure follows the expected path exactly.
In reality, however, exceptions exist.
A document may be missing.
A customer may use an unexpected format.
A system may be unavailable.
A piece of information may be ambiguous.
A request may require a decision.
A well-designed process therefore needs to define what happens when something does not go as planned.
Not everything has to be automated all the way to the end.
At some points, it may be more effective to pause the process, automatically gather all available information and ask a person to make the decision.
This type of automation is often much more reliable than a system that tries to handle every possible situation autonomously.
WHERE ARTIFICIAL INTELLIGENCE CAN ENTER THE PROCESS
Artificial intelligence becomes interesting when part of the process requires interpretation.
A traditional rule can check whether an amount exceeds a certain value.
An AI system can analyse the text of a request and understand which category it belongs to.
It can read a document and extract information.
It can compare content.
It can prepare a summary.
It can identify elements that require attention.
In this way, AI can handle the variable part of the process while traditional automation continues to execute the deterministic parts.
For example, a support request received by email can be analysed by an AI system that identifies the customer, topic and priority. An automation can then use that information to open the ticket, assign it and retrieve the necessary information from the CRM.
The value comes from combining the two systems, not from introducing AI into every step.
MEASURE BEFORE AND AFTER
Before changing a process, it is useful to understand what that process currently costs.
This does not necessarily mean calculating a precise financial value.
It may be enough to measure:
- how long it takes;
- how many people are involved;
- how many manual steps exist;
- how many times the same information is entered;
- how many errors occur;
- how much time passes between start and finish;
- how many requests remain waiting.
This makes it possible to understand whether the work carried out afterwards produces a real improvement.
If an automation removes ten minutes from an activity performed once a month, the advantage is limited.
If it removes three minutes from an activity performed two thousand times a month, the result may be very important.
Automation therefore also means deciding where to intervene.
AUTOMATION IS A PROCESS PROJECT
Today’s tools make it increasingly easy to build workflows, connect applications and use AI systems.
This is a major advantage.
But precisely because the technology has become more accessible, there is a greater risk of starting from the tool instead of the work.
A well-designed workflow is not the one containing the greatest number of steps, integrations or AI components.
It is the one that achieves the required result with the smallest number of necessary steps and the correct level of control.
Sometimes the best solution will be a complex automation.
Sometimes it will be an API.
Sometimes it will simply be removing a procedure that nobody had questioned for years.
This is why, before asking what should be automated, it is worth asking what should continue to exist.
Because making a bad process faster does not make it better.
It only makes it wrong faster.