Principles

Automation is almost always treated as progress in companies.

Manual work becomes automated. Less of people’s time is required. Errors decrease. Work gets done faster, and the company can serve more customers with the same team.

Well-chosen automation can achieve all of this.

But automation does not turn a bad process into a good one.

It removes people’s ability to notice that the process was bad.

In manual work, an employee may notice that the input is wrong, the customer’s situation is different, or the next step does not make sense. Automation follows the logic it has been given quickly, consistently, and at a much greater scale.

When the logic is right, the impact is amplified.

When the logic is wrong, the damage is automated.

Automation amplifies what is already there

Automation is an amplifier.

It can amplify:

• a good process;
• clear accountability;
• high-quality data;
• a viable business model;
• a repeatable customer experience.

But it can just as easily amplify:

• wrong decisions;
• inaccurate data;
• unnecessary work;
• a poor customer experience;
• exceptions built into the process;
• confusion between departments.

If the sales process reaches the right customer with the right message, automation can help the company do so at a greater scale.

If the company does not know who the right customer is or what problem it solves, automation simply allows it to send an irrelevant message to more people.

If the invoicing process is clear and the data is correct, automation reduces manual work.

If pricing, contracts, and customer data do not match, automation may start sending incorrect invoices before anyone notices the problem.

The quality of automation is not determined by how quickly the system operates.

It is determined by the logic it repeats.

First, ask whether the activity is needed at all

Companies often begin automation with the most time-consuming activities.

This seems logical: if people spend a lot of time on something, automating it will generate substantial savings.

But the volume of work does not prove that the activity is necessary.

People may be preparing a weekly report that no one uses to make decisions.

The same information may be entered into several systems because the software does not work well together.

The customer support team’s heavy workload may be caused by a product that repeatedly generates the same questions.

Salespeople may be manually preparing complex proposals for customers the company should not be selling to in the first place.

Automating this kind of work does not create new value for the company.

It makes an unnecessary activity cheaper and gives it a reason to continue existing.

Before automating, always ask:

• Why is this activity performed?
• What outcome does it create?
• Who uses that outcome?
• What would happen if we stopped the activity entirely?
• Can we eliminate the problem before automating its consequences?

The best automation may be the decision to stop the activity altogether.

An unstable process should not be automated

For a process to be automated, it must be sufficiently clear and repeatable.

If the way of working changes every week, the company is not yet ready to build it into a system.

Otherwise, today’s temporary version is what gets automated.

The following week, the customer’s needs, pricing, responsibilities, or workflow may change, and the automation will have to be rebuilt.

The company then finds itself constantly fixing a system that is trying to capture a moving process.

Signs of an unstable process include:

• people perform the same work in different ways;
• there is no agreement on the outcome the process should produce;
• there are almost as many exceptions as standard cases;
• the process owner is unclear;
• the sequence of work steps changes depending on the situation;
• the necessary information only emerges while the work is underway;
• management constantly changes priorities;
• no one knows which of today’s ways of working is actually correct.

This kind of process should not be automated first.

It should first be made visible, simplified, and stabilized.

Automation should not be the method a company uses to understand its own process.

Automation can lock in the wrong process

A manual process is relatively easy to change.

Managers and employees agree on a new way of working and begin testing it.

When the same logic is built into software, making changes becomes more expensive.

It becomes necessary to:

• analyze the impact on the system;
• change configurations or code;
• adapt integrations;
• test different scenarios;
• migrate data;
• train users;
• manage the transition from the old logic to the new.

Automation is therefore not merely an efficiency project.

It is a decision to make a specific operating model more permanent.

If a company automates too early, it may invest a substantial amount in a process that it would prefer to abandon a few months later.

The process is then defended not because it is good, but because the company has already invested in automating it.

The technical solution begins to constrain business choices.

Automating bad data produces confident errors

Automation depends on data.

If the source data is inaccurate, incomplete, or has different meanings in different systems, the result of automation cannot be trusted.

In manual work, a person may notice that the customer’s name, price, or contract status does not match.

Automation may take the incorrect information and quickly propagate it to every downstream system.

One error can reach:

• customer communications;
• the contract;
• the invoice;
• the management report;
• the sales forecast;
• the production plan;
• the customer’s access permissions;
• the next automated decision.

The more systems are connected, the further a single incorrect data field travels.

Bad data is not merely a technical problem.

It may result from the company failing to agree on:

• what a particular status means;
• which system is the official source of truth;
• who is responsible for the accuracy of the information;
• when the data must be updated;
• what information is genuinely necessary for making a decision.

Before automating the movement of data, the company must decide which data can be trusted.

Otherwise, automation turns inaccurate information into the official truth.

Automation can make the customer experience worse

Automated communication may seem efficient to the company.

To the customer, it may feel indifferent, confusing, or even aggressive.

This is especially true when automation fails to account for changes in the customer’s situation.

A customer receives sales emails after making a purchase.

An unhappy customer receives an automated request to recommend the company.

A customer who has resolved a payment issue is sent another reminder.

A person with a complex problem is repeatedly directed to the same bot.

An automated response arrives quickly but resolves nothing.

The cause of such mistakes may not lie solely in poor software.

Often, the company itself has not defined:

• when a customer needs a standard response;
• when a person should become involved;
• what context the system must take into account;
• when automated communication should stop;
• which signal indicates that the customer relationship is at risk;
• who is responsible for the overall customer experience.

Automation is well suited to repetitive, low-risk activities.

It becomes dangerous when understanding the customer’s situation is more important than responding quickly.

Automation can deprive the company of an important opportunity to learn

Some manual work is considered inefficient even though it provides the company with important information.

A founder may want to automate customer onboarding, but that is precisely where the company discovers why customers do not understand the solution.

Customer support may want to automate recurring questions, but the substance of those questions reveals the product’s real shortcomings.

Sales may automate follow-up communication, but personal conversations reveal why purchase decisions stall.

Automation may resolve the customer’s problem quickly, or at least hide it.

At the same time, management loses direct contact with a signal that could help improve the product, process, or business model.

Before automating, therefore, ask:

• What information do we currently obtain through this activity?
• Who uses that information?
• After automation, how will the lesson reach the right people?
• Does the system show only completed activities, or also the causes of recurring problems?
• Are we automating a consequence that we should eliminate instead?

The purpose of automation should not be to make the customer’s problem invisible to the company.

Automation can conceal a lack of accountability

When a process has no clear owner, automation may create the impression that someone is managing the work.

The system sends notifications, changes statuses, creates tasks, and moves data.

But when something goes wrong, no one knows who should intervene.

The technical team says the system operated according to the rule.

The business manager says they did not configure the automation.

The employee assumes the system has already dealt with the task.

The manager sees a green status in the report.

Automation cannot be accountable for a business outcome.

Every automated process must have a person who is responsible for:

• the purpose of the process;
• the correctness of the rules;
• the quality of the input data;
• resolving exceptions;
• monitoring the outcome;
• deciding whether to change or stop the automation.

“The system did it” is not accountability.

The system did what the company allowed it to do.

At low volumes, automation may cost more than manual work

Not everything that can be automated makes economic sense to automate.

If an activity occurs infrequently, takes little time, or changes quickly, performing it manually may be cheaper and more flexible.

The cost of automation is not limited to the initial development or setup.

It also includes:

• process analysis;
• integrations;
• testing;
• maintenance;
• monitoring;
• troubleshooting;
• adapting to software updates;
• documentation;
• managing access and security;
• employee training.

If automation saves two hours a month but takes dozens of hours to build and maintain, it may not be an investment.

It may be technically interesting but commercially pointless.

The right question is not: “Can this be automated?”

The right question is: “Does automating this create more value than the entire lifecycle of the solution costs?”

Too many exceptions make automation fragile

Automation works best when inputs, rules, and expected outcomes are sufficiently predictable.

If every customer, order, or project is different, the system must support a large number of exceptions.

Every new exception adds a condition.

If the customer is of one type, do one thing.

If the price is different, do another.

If the contract was signed before a specific date, use a third set of logic.

If one system does not respond, send the information to a fourth location.

After a while, no one understands the overall logic anymore.

Changing one rule may affect ten other scenarios. An error emerges only with a particular rare combination and is difficult to reproduce.

The automation becomes fragile.

The system works most of the time but fails precisely in the complex situations where the impact is greatest.

In a process like this, a better solution may be to:

• reduce customer-specific exceptions;
• standardize the offering;
• automate only the shared core;
• deliberately route exceptional cases to a person;
• stop offering the most expensive exceptions.

Not every exception needs to be programmed into the system.

Some exceptions indicate that the business model needs to change.

A high-risk decision should not be fully automated

The greater the potential impact of an error, the more important human oversight becomes.

Full automation can be dangerous when a decision affects:

• a substantial financial obligation;
• a person’s job or income;
• a customer’s access to a critical service;
• legal or regulatory compliance;
• sensitive personal data;
• the company’s reputation;
• an irreversible action;
• an important customer relationship.

In these situations, a person does not necessarily have to perform all the work themselves.

Automation can collect the data, check the conditions, flag the risk, and prepare a recommendation.

But the final decision, or at least a high-risk exception, should reach a qualified person.

Good automation does not remove people simply because doing so is technically possible.

It uses people where professional judgment creates more value than maximum speed.

Artificial intelligence does not work like conventional automation

Conventional automation generally follows predefined rules.

When an input meets a condition, the system performs the specified action.

The output of artificial intelligence may not be equally predictable. It can interpret text, draw conclusions, and create new content.

This creates more opportunities but also introduces different risks.

AI can provide a confident answer even when it lacks sufficient information.

It may:

• misinterpret a customer’s request;
• use outdated or inaccurate information;
• produce a plausible but false claim;
• overlook an important exception;
• respond differently to similar situations;
• process information in a way the company cannot later explain.

For AI automation, it is therefore necessary to define:

• what information the system may use;
• which decisions it may make independently;
• which output requires human review;
• what probability of error is acceptable;
• how responses are verified;
• how changes in quality are detected;
• who is responsible for the final outcome;
• when the automation must be stopped.

AI’s speed does not reduce accountability.

It increases the need to decide very clearly what the system should be allowed to do in the first place.

Automation without monitoring creates invisible risk

An automated process can operate for a long time without human attention.

That is one of its advantages.

But if the system begins performing the wrong action, the same characteristic can make the error very costly.

An integration stops transmitting some of the data.

A pricing rule is applied incorrectly.

An automated email is sent to the wrong target audience.

Notifications are generated, but no one monitors them.

A report shows a figure, but the source data is no longer complete.

When automation reduces human involvement, monitoring must take its place.

The company needs to know:

• whether the process runs at all;
• how many cases succeed;
• which cases fail;
• how long the process takes;
• whether the output meets the expected quality;
• who is notified of an error;
• how quickly someone must intervene;
• how the process can be stopped safely;
• how work continues when the automation is unavailable.

Automation whose failure is noticed only after a customer complains is not under control.

Automation can deprive the company of the ability to operate without it

When a critical process is fully automated, people may gradually forget how the work is actually done.

This is not always a problem.

No one needs to retain manual skills for an activity that the system performs reliably and whose interruption is not critical.

But the company must understand its dependencies.

What happens if:

• the software stops working;
• an integration fails;
• the service provider changes its terms;
• the price rises sharply;
• access to the account is lost;
• a key employee leaves;
• the data is corrupted;
• an external API is discontinued;
• the partner who created the automation is no longer available?

If the failure of a single service stops sales, invoicing, service delivery, or customer communication, it is no longer merely a convenient tool.

It is a critical business dependency.

In that case, the company needs a contingency plan, control over its data, and an understanding of how to restore operations when necessary.

When is a process ready for automation?

A process is suitable for automation when:

• the activity creates clear value;
• the work occurs frequently enough;
• the purpose of the process is unambiguous;
• the inputs are available and reliable;
• the core operating logic is stable;
• the number of exceptions is manageable;
• the owner is known;
• the expected outcome can be measured;
• the impact of an error is understood;
• a person can intervene when necessary;
• the total cost of automation is lower than the value it creates;
• the solution genuinely reduces work or risk.

If several of these conditions are missing, it does not mean automation is impossible.

It means that business and organizational decisions must be made before a technical solution is implemented.

The right sequence before automation

The sequence for good automation is simple.

1. Make the work visible

How does the process actually operate, who does what, and where do problems arise?

2. Eliminate what is unnecessary

Do not automate an activity whose removal would not make the outcome worse.

3. Simplify the necessary work

Reduce steps, handoffs, approvals, and exceptions.

4. Assign accountability

One person must remain accountable for the business outcome of the process after automation.

5. Put the data in order

Define the source of truth, the meaning of the data, and who is responsible for its quality.

6. Automate the most stable part

Do not try to cover every possible exception in the first version.

7. Retain necessary human oversight

Especially in cases involving high risk, uncertain input, and complex customer situations.

8. Measure the actual impact

Did working time, the number of errors, waiting time, cost, or the customer experience genuinely improve?

9. Monitor and improve

Automation is not a one-off project. Processes, data, and business needs change.

Bad automation removes people; good automation removes waste

The purpose of automation should not be to remove as many people as possible from a process.

The aim is to eliminate work that does not require the best of human thinking.

Good automation frees people from:

• copying data;
• repetitive checking;
• sending standard notifications;
• performing simple calculations;
• moving information between different systems;
• repeatedly starting the same work.

People can focus on situations that require understanding context, assessing risk, making a choice, or creating a new solution.

Bad automation does the opposite.

It removes people from the point where their judgment was needed while preserving all the unnecessary complexity of the process.

The result is not a better company.

The result is a system that does questionable things quickly, without anyone paying close attention anymore.

It makes sense to automate what the company understands.

What the company does not understand, it should not yet hand over to a machine.

Mikk OrglaanChalleng.ist