Business Process Automation: How to Choose Your First Pilot

Which business process should you automate first?

If an employee retypes a request from an email into a spreadsheet, then chases an approval and enters the same details into another system, you have good material for analysis. The first task is to understand why every step exists. Automating an unnecessary approval would only create the same bottleneck faster.

Choose a frequent process with a recognisable input and rules you can explain. Give priority to a problem someone in the company is willing to own and maintain, and one for which data is available.

Microsoft's recommendations for automation point to clearly defined, repeatable tasks and the selection of suitable existing tools. Parts of the process can still include a human decision. It is a useful framework even if you do not use Microsoft products.

Use the questions in the table for an initial comparison of candidate processes. The answers inform the choice; they are not an automatic cost-benefit formula.

Do not choose the most sensitive process for the first attempt just because it looks impressive. A comparable, bounded task gives you a better basis for the next decision.

Map the current workflow before choosing tools

Describe one real case from arrival to completion. For each step, note the person, the system used, what goes in and what comes out. Include rework loops, temporary spreadsheets and phone checks. Those intermediate steps often hide work that the initial description leaves out.

Separate active work from waiting. Five minutes of checking and two days of waiting for approval are different problems. Automated entry can shorten the first part while the request still sits with the same person.

Then mark what you can remove, simplify or standardise. If a required piece of data is missing, a better form may come first. If the same request is reviewed twice with no clear purpose, the process owner needs to decide whether the second check is necessary.

To compare buying, connecting and building, use the guide to off-the-shelf software versus custom development. Only after describing the process should you check whether a module you already have covers it.

Pilot example: a purchase request with human approval

The flow below is an imagined example, not a description of a client result. An employee submits a request for office equipment, a responsible person reviews it, and the approved details are prepared for further processing.

1. A form collects the item, quantity, reason for purchase and the team the cost belongs to.
2. Rules check whether the details are complete and whether a possible duplicate exists.
3. The request goes to a named person for approval or return for more information.
4. After approval, the details are transferred to the agreed system, if it supports the required input.
5. The requester can see the status, and unfinished items stay on a review list.

Power Automate approvals is an example of an off-the-shelf capability that combines automatic routing with a human decision. The choice of a specific product depends on your existing systems, access and running cost.

In this pilot, approval and the actual purchase remain separate. Automation should not sign a contract or trigger a payment on its own. That keeps a clear point for business judgement and checking the terms.

What happens when a rule cannot decide?

A code is missing, an amount does not match, or the destination system does not accept the data. For each such situation, define a status and the person who takes over. The employee should see what has already been done so they do not repeat the whole request from the start.

Microsoft's guidance on error handling in workflows describes separate paths after a failure or timeout, event logging and limited retries. Ask for a demonstration of those cases. A demo that shows only the happy path leaves part of the process untested.

If you introduce text recognition or AI suggestions, test incorrect and ambiguous inputs separately. Send any result that needs interpretation to a human review. For structured fields with clear rules, start with an ordinary value check; AI is not a prerequisite for automation.

What a pilot plan must contain

The plan should fit in a document that both the operations team and the vendor can use. Write down the scope, the users involved and the event that marks completion. Also prepare a procedure for temporarily stopping the automation.

Complete this checklist before you start:

• The process owner confirms the rules and decides on changes.
• The baseline measures case volume, active time, waiting time and rework.
• The scope covers common cases and known exceptions.
• The automation receives only the access its task requires.
• It is agreed where failed actions are visible and who responds.
• Acceptance criteria define the permitted error rate and the required oversight.
• The results review ends with a decision: expand, change or stop the pilot.

Choose the duration based on the volume and variety of the work. A quiet week can give a different picture from a month-end close. Include a period and a sample that represent the work the solution is meant to handle.

How to calculate genuinely freed capacity

Compare the same scope of work and the same level of quality. Microsoft's guidance on measuring business value includes business metrics and user feedback. That is why you should track rework, solution usage and costs alongside lead time.

Illustrative monthly calculation, with no market estimates or promised result:

Those ten hours do not automatically cut costs by ten working hours. Staff costs can stay the same. Agree where the capacity will be used, for example to handle more requests or reduce a backlog, and check that it actually happens.

Include build, initial training and transition, licences, maintenance and support separately in the financial assessment. Measure quality too: faster processing with more errors can simply move the work to another team.

If the biggest problem is the handover between existing systems, consider system integrations. Where the process for capturing, reviewing and approving requests is missing, review the scope of custom business software development.

Prepare one process, a sample request with no sensitive data and a baseline measurement. Tell Novero about the work you want to automate so the conversation starts from a verifiable pilot and your team's responsibilities.

Sources

• Microsoft's recommendations for automation
• Power Automate approvals
• Microsoft's guidance on error handling in workflows
• Microsoft's guidance on measuring business value