What Is Business Process Automation?

Guide hub Surendra Lal, Managing Partner · · 6 min read

Quick answer

Business process automation is software that carries a piece of work from one step to the next without someone copying it by hand. The useful version is narrow and measurable: an invoice that posts itself, a leave request that routes to the right manager, a customer email that creates a ticket with the order already attached. It is not a new philosophy of work. It is removing the retyping.

A definition you can use in a meeting

If a person is moving the same information from one system to another, or chasing the same approval every Tuesday, that is a candidate. Automation is the piece of software that does the moving and the chasing, according to rules you can write down.

That last clause matters. If nobody can write the rules down, you do not have an automation project. You have a process-design project that has not happened yet. We see this constantly: a business asks for automation and discovers, in week one, that three people do the “same” job three different ways.

Automation is not digital transformation

Digital transformation is a change in how the business operates — often a new system of record, a new channel, a new operating model. Automation is a change to a single path through work you already do. Confusing the two is how a six-week workflow becomes a two-year programme.

If you are replacing the system of record itself, you are closer to custom ERP or legacy modernisation. If you are leaving the systems in place and connecting them, you are in automation.

Where it pays off first

ProcessWhy it works
Invoice capture and postingHigh volume, fixed fields, errors show up in the next reconciliation
Approval routingRules are usually simple once someone writes them down
New-staff onboardingThe same ten accounts, every time, in the same order
Customer email to ticketThe customer already typed the facts; stop retyping them
Stock or job-status notificationsPeople forget; software does not

A longer treatment of how the work actually flows is in workflow automation explained. If you are not sure a process is ready, read when to automate first.

When AI is the wrong tool

If the next step is always the same, you do not need a model that “reasons”. You need a workflow. AI earns its keep when the input is messy — a PDF, an email, a spoken request — and the output still has to land in a structured system. That distinction is the whole of AI versus automation.

What it costs

A single approval or notification workflow, talking to systems that already have APIs, is usually two to four weeks. Connecting two systems that were never meant to talk is longer, because the work is the integration, not the “automation” slide. A document-heavy process that also needs extraction sits closer to an AI integration than to a pure workflow.

Budget the unglamorous parts: exception handling, an audit trail, and a named owner. Unowned automations get switched off the first time they do something surprising.

A day this is meant to remove

Someone in accounts opens email, downloads a PDF, types it into Tally, files the PDF, then messages the branch that the bill is in. Someone in operations copies a status from one screen into WhatsApp because the customer already asked twice. Someone in HR chases a manager for a leave approval that has been sitting three days. Each step is short. Together they are why the afternoon disappeared.

Automation is not “digital transformation” of that company. It is: the PDF creates a draft bill, the status change notifies the customer, the leave request expires upward if the manager is away. Three small paths. Measure each. Then decide whether a fourth is worth it.

What a first project should include — and exclude

Include: one trigger, one happy path, the three most common exceptions, a log, and a person who will look at the failures. Exclude: “while we are at it” reports, a mobile app, and rewriting the ERP. The first project is allowed to look unimpressive in a demo. It is not allowed to be unowned.

If two people cannot draw the same flowchart, stop. Write the process down. That hour is cheaper than encoding an argument. The test for readiness is in when to automate a process.

A briefing you can send without a strategy slide

Write: the job (one sentence), how often it happens, which systems already hold the facts, what “done” looks like on a Tuesday, who will own exceptions, and the three cases that already go wrong. That is enough for a serious partner to say “workflow”, “extract then workflow”, or “not yet”. It is also enough for you to see that you do not yet agree internally.

Attach one real example — a redacted invoice, a leave form, a ticket. Abstract process maps hide the handwritten quote and the supplier who uses three letterheads. The example is the project.

What we would automate first in a typical SME office

The mailbox that already holds supplier PDFs, if finance will own exceptions. The leave form if HR can write the rules and the attendance system has an API. The “where is my order” email if the order already lives in a system you can query. We would not automate “make sales faster”. We would not start with an agent that emails customers. We would not buy a new platform login to do work that Tally or the portal can already route.

That list is boring. It is also how you get hours back in a quarter instead of a transformation programme. If your first request is not on that list, write why. Sometimes the answer is good — the painful job is unique. Sometimes the answer is that a vendor sold you a category. Categories are not projects. See when to automate before you sign.

Where this usually lives in the stack

Inside one system — use that system’s workflow if it has one. Across Tally, a custom portal and email — a small service, usually ASP.NET Core, that already knows how to talk to those APIs. On top of messy documents — extraction first, workflow second. We do not start from a new “automation platform” login unless there is a reason the existing systems cannot hold the work.

Who has to sit in the room — and who does not

The person who currently does the job, the person who owns the exception queue after go-live, and someone who can grant API access. Not a steering committee of eight. Not the vendor’s “change champion” slide. If the person who types the invoice cannot spare two hours a week, you will encode guesses and they will ignore the result.

Write the process on one page before anyone opens a tool. Two people, separately, then compare. Where they disagree is the project. Software cannot settle an argument you have not had.

What “done” looks like for a first automation

A trigger you can name. A happy path that runs without a hero. The three exceptions that already happen every week, routed to a person. A log you can open on Thursday when someone says “it posted the wrong bill”. Training that is not a PDF in a shared drive. If any of those are missing, you have a demo, not an automation.

For the mechanics of triggers and exceptions, continue with workflow automation explained.

In this guide

Related knowledge

How LavisTech can help

← All Business Automation pages

Want this built properly?

We design and build these systems for growing businesses. Tell us the problem and we will scope it honestly.

Start a Conversation