Business process automation: where to start

Which process is a suitable candidate?

Repeatedly entering the same information in different systems, manually assigning enquiries and preparing recurring status reports are possible candidates. Record frequency, waiting points, error types and the impact of errors on the business. These are prioritisation criteria, not claims of measured savings.

If rules change constantly or every step requires individual judgement, establish a working standard first. Keep consequential decisions subject to a responsible person’s review in the first pilot. Identify the process owner and the person who takes over when something fails.

Example: from an enquiry to sales follow-up

Imagine a service business distributing website enquiries through internal email. An illustrative automation creates one record for a validated enquiry, assigns an owner based on service type and makes follow-up status visible. This is an implementation scenario, not a completed client project.

A repeated submission should not create a duplicate. If no owner can be found, the enquiry should enter a shared queue. A failed notification should not destroy the saved record. Defining these exceptions is as much part of the project as the successful path.

An existing tool, an integration or a custom app

If your current software can handle the task, review its workflow features first. When information must move between several tools, connection options and data access permissions become central. Custom interfaces, role-based use and complex process tracking may justify considering a custom application.

Do not decide solely on initial setup convenience. Include licensing and usage costs, data export, connection changes and maintenance ownership in the assessment. The handover plan should explain how dependency on a tool will be managed.

A checklist for the first pilot

Bound the pilot with one trigger and a verifiable outcome. In this example, success means a saved enquiry with a visible owner, not just a sent notification. Write acceptance criteria before development starts.

• Are the input, required fields, process owner and expected output defined?
• How will missing information, retries, connection failures and unauthorised access be handled?
• Which step requires human approval, and who can view the activity history?
• When a failure is reported, is there a retry path and a way to continue manually?
• Will the responsible team check and accept both normal and exception paths using sample data?

Measure usefulness before expanding

Before the pilot, record completion time, pending records, rework and manual interventions. Compare these under a similar workload afterwards. Review whether missing records or incorrect assignments have increased as well as how long the work takes. The right success measure depends on your operation.

For the first meeting, prepare the current steps, the tools used, a sample record and the most common failure. You can describe the workflow without sharing passwords or real customer data. That information helps define the first automation and its required connections.