Business process automation: where to start and how to measure results

1. Choose the right first process

A good candidate repeats regularly, uses accessible data and has a clear outcome: create a request, assign an owner, update a status or flag an overdue task. The fewer judgement calls inside the workflow, the easier it is to validate the result.

Avoid starting with a company-wide redesign. If colleagues disagree about when an order is ready, settle that rule first. Otherwise software will simply move inconsistent data faster. For an infrequent task with little manual effort, a template or a clearer instruction may be enough.

• ✓The process happens often enough to measure an effect.
• ✓Someone owns the outcome and the processing rules.
• ✓Input data is accessible and has a known format.
• ✓Errors can be detected, corrected and handed to a person.

2. Map the journey of one request

Follow an anonymised request from arrival to completion. For each step, record the system, the person's action, the required fields and the condition for moving forward. Separate working time from waiting time: five minutes of handling and two days awaiting an answer need different improvements.

Consider an illustrative workflow: a website receives a maintenance enquiry, the CRM creates a deal, a manager confirms the details and a task is assigned to a technician. Unusual requests stay with the manager. Define the data owner, allowed statuses and failure handling at each handover, including who can see a request while the CRM is unavailable.

3. Estimate the effect without inflating it

For an initial estimate, multiply monthly operations by minutes saved and divide by 60. Subtract time spent monitoring, resolving exceptions and maintaining the workflow. Count only actions that will actually disappear after launch.

This is a hypothetical calculation, not a client case: 300 monthly requests, with handling reduced from six to two minutes each, release 20 hours. If monitoring and exceptions take five hours, 15 remain. At an assumed fully loaded labour cost of €20 per hour, that represents €300 of team capacity per month. Subtract an assumed €100 for tools and maintenance to get €200 of net monthly benefit. An illustrative €2,000 implementation would have a simple payback of ten months if those assumptions hold.

Released time is not automatically cash saved. It becomes valuable when the team uses it for useful work or actually reduces costs. This is an operational estimate, not a financial forecast; it excludes taxes, the cost of capital and workload changes. Track fewer lost enquiries and faster responses separately rather than promising an unverified revenue increase.

4. Decide between a connector and custom integration

First check the capabilities of the systems you already use. A ready-made integration may be sufficient if it supports the required fields, transfer direction and retry behaviour. An automation builder can suit a pilot, but check operation limits, permissions and visibility into failures.

A custom backend becomes worth considering for unusual rules, multiple sources, complex permissions or specific recovery requirements. Compare configuration, subscriptions, maintenance, future changes and data export as part of the total cost. The number of connected services is not a useful measure of quality.

5. Give the pilot measurable acceptance criteria

Limit the first version to one request type or one team. Agree on an observation period and a meaningful number of operations: three successful tests do not represent everyday use. Capture baseline metrics over a comparable period before launch.

Acceptance should describe outcomes. A repeated submission must not create a second task; a temporarily unavailable service must not cause a saved request to disappear; failed operations must be visible to staff. Assign someone to watch failures and document the temporary manual procedure.

• ✓Test normal requests, missing fields and repeated submissions.
• ✓Verify that external failures cannot silently lose an accepted request.
• ✓Provide a failure log and a recovery procedure.
• ✓Grant only necessary permissions and keep secrets out of the browser.
• ✓Compare handling time and error rates with the baseline.

6. Prepare a useful project brief

Share the process map, system list, anonymised examples, operation volume and known exceptions. Identify who can provide test access and accept the work. If documentation is missing, start by walking through several typical requests together.

The first discussion should produce a pilot scope, explicit assumptions and success criteria. Once that workflow has been validated, extend it to adjacent steps such as status synchronisation, notifications and reporting.