Business process automation: how to choose and build the first workflow
Business process automation connects an event to a useful outcome through defined steps, rules and responsibilities. A process can include branches and human decisions. This guide shows how to map one, decide what software should do and check whether the change improved the work.
- Start
- What triggers the process?
- Decide
- Which rule or person chooses?
- Finish
- What proves the work is done?
What counts as a business process?
A process does not need identical steps on every occasion. An enquiry may need clarification, a standard quote or a specialist review. These are branches within a process if the team can explain what triggers each path and what counts as completion. Automation can handle some transitions while people retain decisions that require context, authority or a conversation with the customer.
A repeatable outcome
Choose an outcome more precise than saving time. For an enquiry process, completion might mean a relevant request has an assigned owner and either a next action or a documented reason for closure. Sending an automatic acknowledgement is only one event along that path. If nobody handles the request afterwards, the system has made a notification faster without completing the business task.
A boundary you can describe
Set the boundary before estimating the work. A process might start at form submission and finish when a qualified request reaches the sales queue. Invoicing and delivery can remain outside the first version. This boundary determines which applications, employees and data are involved. It also prevents a small project from quietly expanding into a replacement for the entire operating system of the business.
Map what happens today, including the waiting
Follow a few recent cases
Sit with someone who performs the task and trace several recent cases. Record the starting event, information received, systems opened, decisions made and final state. Look at an ordinary case and a troublesome one. A screenshot of an ideal diagram is less useful than knowing that staff copy a reference from an attachment because the form does not collect it.
Separate activity from delay
Distinguish hands-on work from time spent waiting for information or approval. Software may reduce copying but leave a queue unchanged because nobody has authority to approve a quote. For each delay, ask who can resolve it and what they need. Sometimes the useful change is assigning a backup owner or collecting a missing field before adding another integration.
Name decisions and exceptions
List the conditions that change the path: missing details, an existing customer, a high-value request, an unsupported location or a disputed record. Separate an expected exception from a technical failure. An unsupported service is a normal business outcome; a disconnected mailbox is an operating error. They need different handling, messages and measures of success.
Worked example: an enquiry becomes a quote task
Illustrative workflow. An exception can pause any step and route to a person.
- Capture and identify
- Consider an illustrative service business receiving requests through a website form and email. The first step stores the original request and a unique reference, then checks whether the same enquiry already exists. The required information might be the service, contact details and location. Missing data creates a clarification task rather than an empty customer record that someone must discover later.
- Check and route
- The next step uses agreed rules to route the request. A standard service in the supported area can go to the relevant owner. An unusual scope goes to a named reviewer with the original message attached. AI may help propose a category from an email, but it does not need to decide contractual terms. The routing rule and the model's suggestion should remain distinguishable.
- Prepare and close the loop
- A prepared quote task contains the request, source information and any draft wording. A person approves the actual offer. Once sent, the record tracks the next action and stops reminders when the customer replies or declines. The endpoint is a visible status with a responsible person. A process diagram that ends at send email misses the work required to prevent stale follow-ups.
Decide which record is authoritative
Before connecting applications, define the meaning of each field and which system controls it. A customer name, legal billing name and contact name may be different values. A generic synchronisation can overwrite useful information if these distinctions are ignored. Agree identifiers, required fields, time zones and what happens when a value is blank or a record has been archived.
One-way transfer
One-way transfer is often enough. A submitted form creates a sales task, while later sales changes stay in the CRM. The automation needs to recognise repeated events and avoid creating another task for the same submission. Keep the original source where the team can inspect it, and define a retention policy appropriate to the information being processed.
Changes in both directions
Two-way updates require a conflict policy: which system wins if both change the same field, whether old events may overwrite newer values and how deletions are handled. Ready-made tools can support sophisticated synchronisation when their connectors and logic fit the requirement. Custom code is another option, not an automatic guarantee of consistency. Test the conflict cases using the actual applications.
Choose built-in features, an automation tool or custom code
- Start with what already exists
- Look at the native features of the software the team already uses. A CRM may already support assignment, reminders or an approval step. Using those can reduce the number of moving parts. Still check the relevant plan, permissions and actual behaviour. A feature listed on a marketing page does not establish that it handles the fields and exceptions in your process.
- Check the integration rather than its logo
- A connector list tells you that an application can be connected, but not necessarily that the needed event or action is available. Ask whether the integration can detect the right change, read the required record and write the necessary fields. Check limits, authentication and failure behaviour. If the destination has no suitable interface, the plan may need to change.
- Add custom work for a specific gap
- Custom work can implement an unusual rule, a specialised interface or a missing connection. It also creates code that someone must maintain. Compare that responsibility with the limitations and ongoing charges of a platform. Many useful systems combine native features, a workflow tool and a small custom part. Select the simplest combination that covers the real process and can be operated responsibly.
Specify failure and recovery before accepting delivery
Make failures visible
Agree where failed cases appear and who receives an alert. An error message in a developer's log is not enough if a customer request is waiting. The record should identify the affected case, last confirmed step and next recovery action without exposing unnecessary private data. Microsoft's automation guidance describes error scopes, logging and retries; the appropriate mechanism depends on the chosen platform.
Retry without multiplying the work
Test a repeated submission and a timeout after the destination accepted an action. The system should check what already happened before trying again. Some operations can be retried safely; others need a unique reference or human review. A successful technical response also needs a business check: creating a task in the wrong queue is still an incorrect outcome.
Keep a manual route
The team should be able to pause automation and continue the essential task manually. Define how records are reconciled when the system resumes so that manual work is not repeated. Have the intended owner perform this recovery during handover. A process that only its original developer can restart is an operational dependency that must be acknowledged and supported.
Measure the result and decide what comes next
Your acceptance and measurement brief
Record the current volume, handling time, waiting time, error types and completion rate. Define the same measures for the pilot and the conditions for acceptance. Compare similar case types, and note changes in staffing, season or lead quality that may affect the result. Include the time spent reviewing automated work and recovering failures, not just the seconds saved in one action.
A faster reply is useful evidence, but it does not prove higher revenue by itself. Track whether requests reach an owner, receive a suitable response and progress to the next meaningful stage. For low volumes, individual case review may be more informative than a percentage. Keep the measurement simple enough that the business can continue using it after the project ends.
HeadPills lists one automation process from €500 and systems of several processes from €1,500; scope and running costs are assessed separately. Before seeking a quote, prepare your current map, a few anonymised examples, the systems involved and the intended owner. That lets a supplier price a defined outcome and identify prerequisites instead of promising to automate a vague department.
How we can help
Our part
HeadPills scopes and builds connected workflows, including the rules, exception path and handover. We can assess whether existing tools are enough or a specific custom integration is justified.
Questions
Questions from readers
Does every process need AI?
No. Known rules, transfers and reminders can use ordinary automation. A model is useful where interpreting variable language or documents improves a specific step.
Is a process ready only when every case is identical?
No. Branches and human decisions can be part of a defined process. The important questions are what triggers each path, who owns it and how completion is checked.
Is custom code always better for two-way synchronisation?
No. Assess the supported fields, conflict rules, retry behaviour, maintenance and total cost. Both platform workflows and custom code need careful testing.
Bring one real process and its awkward cases.
We can assess the boundary, connections and first useful implementation.