Automation
Workflow: how to decide whether to define, improve or automate it
An order arrives by email, someone copies the details into a spreadsheet, another person prepares the documentation and, if information is missing, the process stops until someone notices. It may work for a while, but it can also rely too heavily on memory, scattered messages and manual checks.
The decision is not about using more tools. It is about knowing whether your workflow needs structure, operational changes or automation. By the end, you will be able to distinguish which option suits your situation, which risks are worth taking and what you need to clarify before investing in a solution.
Business decision: what should you change?
A workflow is the sequence of actions, decisions, people and tools required to complete a task. For example: receiving a request, checking the details, assigning it, delivering the service, notifying the customer and recording the outcome.
Not every workflow needs to be automated. In many cases, the first useful step is to make it visible and agree on how it should work. The decision usually lies between these three alternatives:
- Document the current workflow when people work in different ways or it is unclear who does what.
- Improve the workflow when there are unnecessary steps, duplicated approvals or information requested more than once.
- Automate a specific part when there is a repetitive sequence, sufficiently clear rules and data that can move between tools without constant intervention.
Before choosing a solution, separate three levels:
| Level | Question you need to answer |
|---|---|
| Objective | What operational or commercial problem do you want to reduce? |
| Scope | Which steps, people, data and exceptions are involved? |
| Solution | Which tool, integration or automation can cover that scope? |
This separation prevents you from buying a tool for a problem you have not yet defined. If your objective is to respond to requests more quickly, for example, the scope may include receiving, categorising and assigning them. The solution could be automation, but it could also be a better-designed form or an internal allocation rule.
Signs that support reviewing or automating the workflow
There are sound reasons to intervene when the process already has a recognisable structure and its operation affects the business. These signs usually indicate that it is worth analysing:
- The same actions are repeated. Copying data, creating documents from a template, sending notifications or changing statuses are tasks worth reviewing.
- Information arrives through several channels. Emails, calls, forms and messages can make it difficult to know which request has been handled and which has not.
- The team needs to check the status constantly. If answering “where is it up to?” requires asking several people, the process lacks visibility.
- There are relatively stable rules. For example, assigning a request according to a category, notifying someone when data is missing or generating a follow-up after a specific action.
- The volume or frequency makes manual work difficult to sustain. The process does not need to be large: repetition simply needs to divert attention from tasks that require judgement.
- An error in transferring information has operational consequences. When incorrectly copied data, an unassigned request or a missed notification blocks the next step, the workflow design should be reviewed.
These signs do not prove that you should automate everything. They indicate an opportunity to understand the process and identify the point where a change would make the most sense.
Hypothetical example
Imagine a service company that receives requests through its website and by email. One person reviews them, requests any missing information, assigns them to the relevant person and updates a spreadsheet.
If requests differ significantly from one another and require interpretation from the first contact, automating the full assignment may be risky. However, it may make sense to centralise incoming requests, detect incomplete fields and record each request in one place. Professional judgement would remain with the person responsible.
Signs against automation: when it is not yet advisable
Automating a confusing process can make errors happen more quickly. Before considering a technical solution, pause if you recognise any of these situations:
- There is no agreement on the expected outcome. If each person understands differently when a task is complete, you first need to define that criterion.
- Exceptions are the norm. A workflow with many unique cases may require human review as a central part of the process, not as a workaround.
- Input data is incomplete or unreliable. Automation cannot safely compensate for information that arrives unstructured or with frequent errors.
- Rules change without a clear owner. If no one can confirm which condition applies, it will be difficult to maintain the system when needs change.
- The task requires judgement, authorisation or a personal relationship. Deciding on a commercial exception, approving an amount or responding to a sensitive situation are decisions that should retain appropriate human validation.
- You do not know who will maintain the workflow. Any system needs someone to review incidents, tool changes, access and business rules.
In these cases, document the actual journey first. Identify the starting point, the outcome, the people involved, the necessary data and the points where decisions are made. With that foundation, you can decide what to simplify without turning a tool into a new source of dependency.
Costs and dependencies to assess beyond the tool itself
The cost of a workflow is not limited to its implementation. It also matters what it needs to operate reliably and who will take decisions when something changes.
Initial work
The initial phase may include defining the objective, analysing steps and exceptions, preparing data, configuring tools, integrations, testing and documentation. If any of these elements are excluded, you should know before comparing alternatives.
It is also useful to clarify who prepares access, who validates the workflow's behaviour and who approves changes. An apparently simple rule may require more work if it depends on several applications or on data that is not standardised.
Recurring and operational costs
Depending on the chosen solution, there may be licences, external services, technical maintenance, support, monitoring, updates and process evolution. Not all these elements apply in every case, but they should be separated from the initial build.
A practical question is: if a person, a tool or a business rule changes, what will need to be reviewed and who will be able to do it. The answer reveals part of the true operational cost.
Dependencies that may influence the decision
Pay particular attention to these dependencies:
- The tools where data originates and ends up.
- The permissions and account owners required.
- The quality and format of incoming information.
- The limits of integrations between services.
- Process continuity if an external service becomes unavailable.
- The person responsible for validating incidents and changes.
- The ability to retain or transfer data if you change tools in the future.
The goal is not to avoid every dependency. It is to accept them consciously and in proportion to the problem you want to solve.
Decision matrix for your workflow
Use this matrix as guidance. It does not replace analysis of the specific process, but it helps you choose the most prudent next step.
| Observed situation | Most reasonable decision | Risk to watch |
|---|---|---|
| People follow different steps for the same task | Document the workflow and agree responsibilities | Turning an informal practice into a rule that nobody has validated |
| There are repetitive steps and clear rules | Assess automating a defined part | Failing to define what happens in the event of errors or exceptions |
| The process has duplications and avoidable waiting times | Simplify before automating | Retaining legacy steps that no longer add value |
| Each case requires significant interpretation | Keep human review and support only auxiliary tasks | Delegating sensitive decisions to overly rigid rules |
| Data comes from scattered or incomplete sources | Organise inputs and data before connecting tools | Automating inconsistent information |
| The solution depends on several applications | Design the integration and maintenance with defined owners | Failing to plan for access, service changes or incidents |
| The process changes frequently | Start with a limited, reviewable scope | Building a solution that is difficult to adapt |
Conditional recommendation
Start by defining a single workflow with a recognisable impact: receiving requests, preparing quotations, order follow-up, document management or internal communication. Describe what triggers it, what information it needs, who is involved, what decisions are made and how you know it has been completed correctly.
If the workflow is repetitive, its rules are clear and you can identify exceptions, partial automation may be a reasonable option. If there are still doubts about steps, data or responsibilities, prioritise defining and simplifying the process. That preparation is not wasted time: it reduces the risk of implementing a solution that automates disorder.
When you need to review which part of the process can be automated without losing control, you can tell AVSISTEC about your automation project.