Automating a business process: the steps before choosing a tool
Updated on
“We spend too much time on this” often starts a discussion about automation. It is a useful symptom, but it is not yet a specification. Find where the time goes, which information moves between people and which steps genuinely require human judgement. The answer determines what can usefully be automated.
In the video, I explain how we begin: qualify the problem before proposing a tool. The need may lead to artificial intelligence, an integration between systems or a much simpler function. Understanding the work comes first. A list of fashionable technologies cannot substitute for a clear description of the process.
Contents
Describe one situation from beginning to end
Choose a specific process, such as receiving an inquiry, preparing a quote or filing a document. Identify its starting point, the people involved, the tools used and the intended result. Include the handovers between people, because waiting for information can matter as much as the time spent entering it.
Examine exceptions as well. An incomplete inquiry, an unreadable document or a customer already in the system may change the route. These cases often reveal more about the required work than an ideal demonstration in which everything arrives correctly and every decision is obvious.
A first measurement can remain simple: how often the task happens, roughly how long it takes and how much rework is required. Those observations do not guarantee a future saving. They help choose a problem and provide a baseline for checking whether the new process actually improves it.
Decide between a rule, an integration and AI assistance
If the task is to transfer known fields to another tool, an integration with explicit rules may be sufficient. If it involves varied text, AI assistance can be evaluated, with defined limits and validation steps. The method should follow the uncertainty in the input rather than the desire to use a particular technology.
Imagine an estimate request arriving by email. A system could prepare a record and flag missing information. The commercial decision and sending the price could remain with the team. This is a possible design scenario, not a promise that the process will work unattended or that the generated interpretation will always be correct.
To understand how information travels between systems, the article about APIs and connecting business software provides a starting point. It explains the connection itself and the decisions needed to make the exchange useful and dependable in daily work.
Build in a controlled environment
The video mentions tools used at that time, including n8n, code and Git. Their purpose is to support building and tracking a system. An automation must be selected and maintained according to the current project’s constraints. A historical tool list is not a complete method or a guarantee of suitability today.
Distinguish testing from production, track modifications and identify the necessary access. Permissions, information handled and the owners of the different services belong in the design discussion. The team should understand which actions are real during a test and which are simulated or restricted.
For a business process automation project, these are parts of the delivered operation. They should not depend solely on the memory of the person who built the first workflow. Document how to investigate a failure and who can change the configuration when the process evolves.
Test the cases that create uncertainty
A useful test checks more than a successful submission. What happens if the inquiry arrives twice, the destination responds slowly, a field contains an unexpected value or someone needs to correct a record? Each situation can expose a different assumption about how the workflow should behave.
Plan how staff find pending actions, recover from errors and confirm what has actually happened. A silent failure may simply move the work elsewhere, forcing someone to reconstruct the history later. Clear operational visibility belongs in the acceptance criteria alongside the automated action itself.
Start with a limited scope when appropriate. Observe the results, exceptions and monitoring effort before extending the workflow. That gives the team a chance to understand the system under real conditions while the number of affected tasks remains manageable and the recovery process is familiar.
Comparison: explicit rules, API connections and AI assistance
These approaches can work together, but they address different difficulties. Compare the information available, the result required and the necessary control. Starting with those criteria avoids using an interpretive tool where an explicit condition would do the job more clearly.
A rule for a decision already defined
Situation: structured fields determine an action through known conditions. Illustrative example: assign a record according to the selected region and service. Control: test each combination, including missing values. This fits when the business can explain the intended outcome without ambiguity. If the rules conflict, resolve the process first. Encoding a disagreement does not make the decision more coherent for the people using the result.
An API connection for transferring information
Situation: the same information must move from one tool to another. Illustrative example: create a CRM task after an inquiry is accepted. Control: check identifiers, duplicates and recovery after errors. The main issue is dependable transfer. The connection may apply rules, but it does not itself resolve disagreement about what counts as a customer or project. Those definitions need to be agreed during scoping.
AI assistance for proposing an interpretation
Situation: varied text needs summarising or classifying. Illustrative example: prepare an email summary so staff can review it more easily. Control: compare the proposal with the original and handle uncertain cases explicitly. Fluent output can still be inaccurate. Define which actions require human validation, particularly when they affect a commercial relationship or modify important records. Make the boundary visible to the team.
One journey may begin with a proposed summary, continue with approval and end with a CRM transfer. Separating those stages shows where judgement occurs, where a rule applies and where the task is simply to confirm that information arrived. Each stage can then have suitable tests and ownership.
Choose a first project small enough to observe
Compare two candidate tasks through their frequency, actual time spent, exceptions and consequences of error. A repetitive but unstable task may be less suitable for an initial trial than a smaller transfer with clear rules. This is a scope decision, not a permanent ranking of the business’s needs.
Prepare representative cases: an ordinary request, incomplete information, a duplicate and a situation that must return to a person. Write the expected result before running the system. Reuse those cases after changes, so checking new behaviour does not come at the cost of overlooking something that previously worked.
During the first rollout, keep a straightforward way to pause processing and continue the work. Assign someone to examine anomalies. A project becomes easier to evaluate when the scope is limited and the team knows what it is observing. Expand afterwards, using the exceptions actually encountered as evidence for the next decisions.
Measure the benefit and retain an accountable owner
After launch, compare equivalent tasks with the baseline: time spent, errors, delays and remaining interventions. Include the work required to supervise and maintain the system. Removing a data-entry step does not automatically mean the same amount of time has disappeared from the overall process.
The team should know whom to contact when a tool changes or a new situation appears. Business processes evolve, and useful automation needs an organised way to evolve with them. Continuing ownership is therefore part of the outcome, not an optional extra after delivery.
The best first project is not necessarily the most impressive demonstration. It is one whose problem is understood, whose result can be observed and whose day-to-day operation the team can sustain. Those qualities create a practical basis for deciding what should be automated next.
FAQ: preparing a business automation project
Does automation require artificial intelligence?
No. A rule, calculation or connection between tools may be enough. AI deserves evaluation when the input requires interpretation that the planned rules handle poorly. First define the expected result and the errors the process can tolerate. That helps select an approach proportionate to the problem and makes the required human involvement clearer.
How can we estimate savings without inventing results?
Measure the current work and observe a trial on a comparable scope. Include human review, corrections and maintenance. You can then distinguish avoided data entry from the total time actually saved. An early estimate remains a hypothesis until operation has been observed under relevant conditions, with exceptions and ongoing supervision taken into account.
Should the whole process be automated immediately?
A well-defined segment is often easier to test. It still needs a clear beginning, end and responsible person. Automating receipt of an inquiry without assigning exceptions leaves a gap. Define the handover between automated work and the team, including what information the person receives and how they confirm that the case has been handled.
What should we prepare before speaking with Umbeli?
Bring anonymised examples, the list of tools involved and an explanation of decisions made at each stage. Difficult cases are especially useful. A process automation project can then begin with real work: what repeats, what varies and what should remain under your control. That gives the discussion a more useful foundation than selecting a tool first.