Skip to content

Which workflow should you automate first?

Fenix Admin
Which workflow should you automate first?

There is plenty of work worth automating, but a business cannot easily tackle everything at once. HR wants faster leave-request processing, finance needs receivables matching and operations wants maintenance reminders. Where should you begin?

A sensible starting point depends on benefits you can assess, the data available and clear processing rules. You also need to know who takes over when errors or unexpected cases occur. High frequency is an advantage, but it does not determine priority on its own.

Use the questions below to compare proposed workflows. Choose a tool only after identifying the work that needs support and the outcome you want to improve.

1. List the work, not the technology

Rather than setting a broad goal such as “automate HR,” describe a piece of work from the moment it starts to the point it is complete. For a leave request, that might mean receiving the form, checking the details, routing it for approval and recording the outcome. This makes it easier to identify the data needed, each person’s responsibilities and the work a tool could support.

Consider a hypothetical business that already uses a standard leave form and knows who approves each type of request. The team can use that existing process to choose a trial scope. If requests still arrive by email, chat and word of mouth, the first improvement should be to agree on a single intake point; otherwise, the tool may handle only some of the requests actually being made.

Managing work in Excel: When is it time to change?

Do not automate every step simply because you have mapped it. A check that exists only because information is re-entered may become unnecessary when data is connected properly. Automating a redundant step preserves complexity without addressing its cause.

People doing the work often know steps missing from the documentation: asking for clarification, correcting department codes or waiting for an approver. Include these in the process map before selecting the automation scope.

From Business Process to Software: What comes first?

2. Assess each process with five questions

How often does the work occur, and what impact does it have?

To judge whether a task deserves priority, look at both its volume and its impact. Over a period that reflects the work’s cycle, record how often it occurs, the time staff spend handling it, waiting time and recurring errors. Together, these details show where effort is being spent and who is affected by delays.

A monthly report may deserve priority if it takes substantial effort and informs important decisions. Conversely, a small daily task may offer limited value after maintenance costs are included.

Are the rules clear enough?

Next, consider whether the people doing the work can explain the processing rules consistently. “Return the form if a required field is missing” gives a clear condition to check. “Send it to a manager if it looks unreasonable” still depends on individual judgment. For those steps, agree who makes the decision and how much the tool is allowed to handle.

A human decision does not disqualify the whole workflow. Intake and data checks can be automated before an assessment is passed to the responsible person.

Are the data and access permissions ready?

Clear rules are useful only if the tool receives suitable data. Check where the information is stored, whether the necessary details are available and whether the proposed tool is permitted to access them. If the inputs exist only as screenshots in different formats, they will need to be standardized or extracted before the next processing step.

Employee, financial and customer information must stay within the approved scope of use. Do not upload real data to an external service for a quick trial without checking its conditions of use.

What exceptions occur, and who handles them?

Even a familiar workflow has cases that fall outside the usual path. An approver may be absent, an employee may change the dates after approval, or a request may involve someone who has moved departments. Agree which cases need to pause for review, who receives a notification and who takes responsibility for resolving them. This helps prevent a request from being overlooked simply because the tool has no defined next step.

Is the ongoing cost proportionate?

Finally, account for the work required to keep the solution running after the trial. Beyond initial development, there may be tool and licensing fees, time spent monitoring errors, user support and updates when the process changes. A setup tied to one employee’s account or to a screen whose layout changes frequently may need more maintenance than expected. Someone needs clear responsibility for that ongoing work.

3. Compare three practical situations

For leave requests with a standard form and clear approval levels, a trial might cover information checks, approval routing and status updates. Special requests remain with authorized decision-makers.

Matching customer payments against outstanding invoices may involve more checks than leave-request processing. Although it could reduce reconciliation work substantially, the team still needs to understand payment references, single payments covering several invoices, partial payments and discrepancies in the data. A practical first scope might therefore suggest clear matches for an accountant to confirm, rather than automatically confirming every payment.

Maintenance reminders, meanwhile, can sound straightforward: send a message at the right time. But a fixed calendar date is different from a schedule based on machine operating hours. If those hours are not reliably updated, an automated reminder is unlikely to be dependable either. In that case, improving the input data comes before building the notification.

These examples show why priority should not rest on the impression that “this looks easy.” Record benefits, missing conditions and the consequences of incorrect processing. Internal scores can support discussion but cannot replace risk assessment.

4. Run a trial and decide whether to expand

A useful trial has a start, an end and an accountable owner. For example, it could receive leave requests from one department, check the information and route them for approval, without including payroll.

Before running it, agree on checks: do requests reach the right person, do statuses update correctly, and are errors detected and handed over? Retain an alternative way to work if the tool is unavailable.

When assessing the result, measure more than the actions the tool has taken over. Staff time spent checking results, correcting data and resolving exceptions is also part of the new process’s cost. Including that work helps establish whether the total workload has actually fallen or has simply moved from one step to another.

How can you tell if your software is delivering value?

After the trial, consider both benefits and new costs. If handling time falls but staff spend longer correcting inputs, adjust the process before expanding it.

There are three reasonable options: continue within the validated scope, revise the process or stop if benefits are not proportionate. A trial revealing that conditions are not ready still informs the next decision.

If the work requires interpreting emails or free text before reaching a judgment, assess any proposed use of AI separately. Alongside the input data, define how outputs will be checked and who must confirm them before they are used in the next step.

Is your business data ready for AI?

The first automation does not need to cover an entire department. A task with a clear benefit, usable data and an agreed approach to exceptions provides a more practical starting point. Once the results have been checked and the maintenance effort is understood, the business can make an informed decision about extending the approach to other work.

Explore IT consulting with Fenix

Get started with us now

Let's build something extraordinary

Start a conversation