Business Process Automation Guide: What to Automate and How

Business process automation means using software to carry out repeatable steps in a process, such as routing, approvals, data entry, notifications and handoffs between systems, so people spend their time on judgment rather than copying data around. Done well, it starts with a clear process, automates the right steps in the right tool, and is monitored like any other business system. Done badly, it hard-codes a broken process and creates silent failures nobody notices until a customer does.

This guide covers how I identify what to automate, choose the right automation layer, design automations that hold up in production, and keep them healthy afterward.

What business process automation is, and what it is not

Automation covers a spectrum:

• Rules inside one application: workflow rules, approvals, assignment, scheduled actions in your CRM or ERP.
• Integration between applications: passing orders, invoices, customers or tickets between systems without re-keying.
• Orchestrated workflows: multi-step processes that span people and systems, such as employee onboarding or order-to-cash exceptions.
• Document and data capture: extracting data from emails, PDFs and forms.
• AI-assisted steps: classifying requests, drafting responses, or suggesting next actions, with a person in the loop where it matters.

Automation is not a substitute for process design. If nobody agrees how purchase approvals should work, automating them simply makes the disagreement run faster.

Step 1: Find the right candidates

Start with the processes that cause visible pain: delays, errors, rework, missed follow-ups, or staff spending hours on copy-and-paste. Then score each candidate.

Typical high-value candidates in SMB and mid-market firms include lead routing and follow-up, quote approvals, sales order to invoice handoff, purchase approvals, vendor bill matching, customer onboarding, ticket triage, employee onboarding and offboarding, and recurring management reports.

Step 2: Map the process before automating it

For each candidate, map the current process: triggers, steps, decisions, people, systems and data. Then design the future process. Usually this removes steps rather than automating them. Questions I ask in every mapping session:

• Why does this step exist? Who uses its output?
• Which approvals actually change outcomes, and which are a formality?
• Where is the same data entered more than once?
• What are the exceptions, and how often do they happen?
• Which system should own each piece of data?

The future-state map becomes the specification for the automation. See my approach to business process consulting for more on mapping.

Step 3: Choose the right automation layer

The same outcome can often be built in several places. My order of preference:

1. Native features of the system of record. A workflow rule in your CRM or an approval rule in your ERP is supported by the vendor, visible to admins, and survives upgrades best.
2. Native integrations between applications, such as standard connectors between CRM and accounting.
3. Integration or workflow platforms, such as Zoho Flow and similar tools, for cross-application flows with triggers, conditions and actions.
4. Custom scripts and APIs, for example Deluge in Zoho, Python modules in Odoo, or server scripts in ERPNext, when logic is too complex for configuration.
5. Robotic process automation only when a system has no API and replacing it is not an option. Screen-based bots are fragile and need more maintenance.

Choosing the lowest layer that works keeps automation understandable for whoever maintains it next.

Step 4: Design for exceptions and failure

The happy path is the easy part. Production-grade automation also handles what goes wrong:

• Validation: check inputs before acting. Missing tax IDs, invalid emails and zero quantities should stop the flow with a clear message.
• Idempotency: running the same trigger twice should not create two invoices. Use unique references and check before creating.
• Error handling: catch failures, log them, and notify a named person or queue.
• Human in the loop: route exceptions and high-risk decisions to a person with the context they need.
• Retries: handle temporary failures, such as an API timeout, without duplicating work.
• Audit trail: record what the automation did and why, so finance and auditors can follow it.

Step 5: Build, test and roll out

• Build in a sandbox or test environment where the platform provides one.
• Test with realistic data, including edge cases and known exceptions.
• Run new automations in parallel with the manual process or for a single team first.
• Tell users what will change: which emails they will stop sending, which fields now fill themselves, where to look when something fails.
• Switch off the old manual steps deliberately, so work is not done twice.

A worked example: order to invoice

Consider a common handoff. A salesperson marks a deal as won in the CRM, then emails operations, who re-key the order into the ERP, and finance raises the invoice from a spreadsheet. A sensible automated version looks like this:

1. When a deal reaches the won stage, the CRM checks that the customer's billing details and tax ID are complete. If not, it sends the record back to the salesperson with a clear task.
2. The integration creates or updates the customer in the ERP, using the CRM ID as a reference to avoid duplicates.
3. A sales order is created in the ERP with the agreed products, prices and terms.
4. Orders above an agreed threshold, or with non-standard terms, go to a finance approver.
5. Once delivered or completed, the invoice is generated in the ERP and its status is visible back in the CRM.
6. Any failure is logged and sent to a named owner.

Notice that people still make the decisions that matter, while the copying, chasing and checking disappear.

Step 6: Govern and maintain

Automations are software, even when built with no-code tools. Treat them that way:

• Keep an automation register: name, purpose, trigger, systems touched, owner, last change.
• Assign every automation a business owner and a technical owner.
• Review failure logs regularly, especially in the first weeks.
• Re-test automations when connected systems change fields, versions or APIs.
• Retire automations that no longer serve a purpose.

Without this, organizations end up with dozens of undocumented rules firing in the background, and nobody dares to change anything.

Measuring the value of automation

Define measures before you build, then compare after rollout. Useful measures include cycle time from request to completion, the number of manual touches per transaction, error and rework rates, backlog size, and how often a process misses its service level. Measure on your own data rather than relying on generic benchmarks, because the value depends entirely on your volumes and how the process ran before.

Where AI fits

AI is useful for steps that rule-based automation handles poorly: reading unstructured emails and documents, classifying requests, summarizing records, or drafting replies. Use it inside a well-defined process, with confidence checks and human review for anything with financial, legal or customer impact. I cover this in more depth in AI in ERP.

Common automation mistakes

• Automating a process nobody has agreed on.
• Building the same logic in two places, such as a CRM workflow and an integration flow, that conflict.
• No error notifications, so failures go unnoticed.
• Over-automating rare exceptions instead of routing them to a person.
• Relying on one person who understands how everything is wired together.

Next steps

If manual handoffs, re-keying and approval delays are slowing your business, I can help identify the right candidates, design the future process and build automations that last. Learn more about my automation services and system integration work, or get in touch.

Frequently Asked Questions

Which business processes should we automate first?

Start with frequent, rule-based processes that cause visible delays or errors and whose data already lives in systems, such as lead routing, approvals, order-to-invoice handoffs and onboarding. Avoid automating processes that are not yet agreed or documented.

Should we use our ERP's built-in automation or a separate tool?

Use built-in automation in the system of record wherever it can do the job, because it is easier to maintain and survives upgrades. Use an integration or workflow platform for processes that span several applications.

Is RPA a good choice for business process automation?

Robotic process automation is best kept as a last resort for systems without APIs. Screen-based bots break when interfaces change, so API-based integration and native automation are usually more reliable.

How do we keep automations from becoming unmanageable?

Keep a register of every automation with its purpose, trigger, systems and owners, monitor failures, re-test after system changes, and retire automations that no longer serve a purpose.