Business process automation: six examples, one pattern.

At 4:40 on a Thursday, somebody in your finance team has two windows open. A supplier PDF on the left, your ERP on the right. They read a number off one and type it into the other. Then they do it again, 180 more times, and go home.

That person is the automation candidate. Not "accounts payable." Not "the finance function." That specific act of reading from one screen and typing into another.

Almost every list of business process automation examples you'll find is written one level too high to be useful. It tells you invoice processing can be automated. It does not tell you which step in invoice processing a human is currently holding together, at what volume that step is worth removing, or what happens to the automation nine months later when your supplier changes their invoice layout.

So this is the version organized around the step, not the department. Six processes, the exact human handoff inside each one, and the thing all six turn out to have in common.

What is business process automation, in one sentence?

Business process automation is removing the human steps from a repeating, rule-governed sequence of work that crosses more than one system. The definition matters less than the boundary: if the step needs someone to weigh a tradeoff, read a room, or make a call they'd have to defend later, it stays with a person.

The word doing the work in that sentence is "crosses." A task that lives inside one system usually already has a button for it. Your ERP can email a payment confirmation. Your CRM can assign an owner by territory. Nobody writes an article about that.

The expensive work is the work between the systems, and there is a lot more of it than most operators assume. Salesforce's MuleSoft division surveyed 1,050 IT leaders for its 2026 Connectivity Benchmark Report and found the average organization now runs 957 applications, up from 897 the year before, with just 27% of them integrated with each other.

Read that number as an org chart rather than an IT statistic. Seventy-three percent of the connections in your company are not built. They are staffed.

Six business process automation examples worth doing first.

These are ordered by how reliably they pay back in a 50 to 500 person company, not by how well they demo. Each one names the process, the human joint inside it, and the volume at which pulling that joint out starts to be worth the effort.

Treat the volumes as rules of thumb rather than benchmarks. They are the points at which the build stops being a science project in most companies this size, and your own error rate can move them in either direction.

1. Supplier invoice to posted payable

The process runs from an invoice landing in a shared inbox to a coded, approved entry sitting in the ERP. The human joint is one step wide: someone opens the PDF, finds the vendor, amount, PO number, and tax lines, and retypes them into fields.

Everything around that step is already rules. Match to PO, route by amount band, flag anything outside tolerance for a person. Worth doing at roughly 250 invoices a month and up, earlier if your suppliers send layouts that change often. Below about 60 a month, the exception handling costs more than the typing. We went deeper on where this stalls in AI accounts payable automation and the 33% ceiling.

2. Emailed purchase order to sales order

A customer sends a PO as an email attachment. Someone opens it, reads part numbers and quantities, and keys them into the order system, usually while the customer waits.

Same joint as the invoice, pointed the other direction, and an error here costs more because it ships. For distributors and manufacturers this is the one that pays back fastest, because the same keystrokes also gate your cash. The Hackett Group's 2025 Working Capital Survey found an 18-day gap in days sales outstanding between top-quartile and median performers. Some of that gap is credit policy. A surprising amount of it is order entry queued behind one person's Tuesday. The mechanics are in how to automate order processing without the upkeep.

3. Signed offer to a working new hire

Between the signature and the first productive morning, someone creates the same human in six or seven places: payroll, the HRIS, email, the VPN, the CRM, the ticketing tool, the badge system. Then does it in reverse when they leave, usually late, which is also your access-control problem.

What you are removing is the repeated identity entry. Worth automating once you're past roughly two hires a month, and worth it immediately if you're regulated, because the offboarding half is an audit finding waiting to happen.

4. Expense claim to reconciled ledger

Receipt photo, category, project code, policy check, approval, export. Coding the category and the project is the human step, and it survives because the coder is guessing from a blurry photo and a memory of the trip.

This one has a real threshold. Under about 150 claims a month it is not worth building; the policy exceptions eat the savings. Above that, the win is less about the finance team's hours and more about closing the month on schedule.

5. Inbound lead to routed, enriched, assigned record

A form fills. Somebody looks up the company, decides if it fits, finds the right owner, and pastes in headcount, industry, and a guess at intent.

The lookup is the joint, with a judgment call stapled to it. Salesforce's State of Sales research puts 60% of a rep's time on work that isn't selling, and this sits squarely in that 60%. Worth doing above roughly 200 inbound records a month, or any volume at all if your response time is currently measured in days.

6. Customer request to the right queue with the right context

An email or form arrives. Someone reads it, decides what it is, tags it, attaches the account history, and routes it. Then a second person reads it again to answer.

Everything hinges on that first read. Worth automating above roughly 400 requests a month, or at any volume once a second person is re-reading tickets a first person already read. Automating it does not mean a bot answers your customers. It means the request lands with the person who can answer, already carrying the order number, the contract terms, and the last three tickets.

What is the difference between BPA, RPA, and BPM?

BPM is the map, BPA is the removal of human steps from the map, and RPA is one specific way to do the removal. They get used interchangeably in vendor copy, and the distinction costs real money when it's blurred.

Business process management is the discipline of documenting and improving how work flows. It produces diagrams and owners. It does not, by itself, take anything off anyone's plate.

Robotic process automation is a bot that drives the user interface: it clicks where a person would click, types where a person would type. That is the model UiPath, Automation Anywhere, and Blue Prism built their platforms on. It is the only option when a system has no API, and it is fragile for the same reason, because a vendor moving a button on a Tuesday release is an outage on Wednesday. We laid out why that fragility is structural in AI agents vs RPA.

Business process automation is the outcome, whatever the method. In practice a good build is mostly ordinary integration code, with a small model-driven step where the input is genuinely unstructured, like reading an invoice layout nobody has seen before.

Every one of these examples breaks in the same place.

Look back at the six. Invoice to payable, PO to sales order, offer to new hire, claim to ledger, lead to owner, request to queue. In each one, the step that a person performs is a translation between two systems that do not speak to each other. The person is the integration.

That is why the vendor lists are unsatisfying. They describe the process and skip the joint, and the joint is the entire build.

It's also why so many of these automations quietly stop working. What you removed was a human compensating for a missing connection. When either end of that connection changes, a new invoice template, a renamed CRM field, a supplier switching portals, the compensation has to change too. Nobody notices for a while, because a flow that fails silently looks exactly like a flow that's working.

BCG's July 2026 survey of 152 CEOs at companies above $500M in revenue found 89% report some cost or revenue benefit from AI, while only 26% have built it into how the business actually runs and only 14% can name a defined P&L impact across their AI work. The projects mostly aren't failing loudly. They're sitting in a corner, technically alive, moving nothing.

There's a second failure mode worth naming, because it's arithmetic rather than opinion. If you build a process as ten chained AI steps and each one is 95% right, the whole thing finishes correctly 59.9% of the time. Reliable automation puts the model in the one step that needs judgment and runs the other nine as deterministic code. That ratio, roughly 90% code and 10% AI, is what separates a process you can put in the critical path from a demo.

Which process should you automate first?

Rank your candidates on three axes and take the highest score: how often the process runs, what a single error costs, and how much of it is genuinely rule-governed rather than judgment. Frequency times error cost is the payback. Rule density is whether it's buildable at all.

Then apply a filter almost nobody applies: check the ends before you scope the middle. Does the source system have an API, or is the data trapped in an emailed PDF? Is the destination on-premise? Is the "system" actually a spreadsheet on someone's desktop? For a mid-size company that grew by buying software one department at a time, these questions decide whether an example on this page is a two-week build or a two-quarter one.

Eurostat's enterprise survey shows how uneven the starting line is. 30.4% of firms with 50 to 249 employees used AI in 2025, against 55.0% of firms above 250. The gap isn't ambition. It's that a 200-person distributor has the same integration problem as a 5,000-person one and none of the internal engineers.

If the honest answer is that you don't know which process to start with, that's a normal place to be, and it's the question Uplift's Brainstormer exists to answer. It looks at what each role actually does day to day and proposes what's worth automating, drawing on a library of over 14,000 real automations built by people in roles like yours. You get a ranked list with the joints already identified, rather than a blank canvas and a training budget.

Who keeps it running once it's live?

Somebody has to, and in a company your size that somebody is usually one operations manager who already has a job. This is the part that never makes the list, and it is the part that decides whether any of this is still working next year.

There are three ways to answer it. Hand every department a builder license and let them make their own flows, which is like buying everyone a fishing rod: it looks generous, and most of the rods stay in the closet while the two people who were already technical build everything. Hire an agency, which works well while they're in the building, and then the engagement ends and the knowledge leaves with them. Or hand the whole thing to a team that builds the automation, operates it, and absorbs the downstream changes when a vendor rewrites an endpoint.

That third option is what Uplift does. You describe the routine the way you'd describe it to a new hire, and you get back a working agent that somebody else maintains. There's no canvas to learn and no run history to check on Monday morning. There are also no tokens, no per-seat licenses, and no bill that moves because a busy month happened; the whole organization gets access at a flat price, because what you're buying is a working process, not a tool. There's a breakdown of what each department actually gets, and of how a build gets scoped and handed over.

Six processes, six joints, and one question worth settling before you build any of them: who owns this in March? That is the whole distance between working with AI and having AI that works for you.