Business Process Automation Examples, Department by Department

Business process automation examples are easiest to judge when each one is written the same way: what starts it, what the software does, which systems it touches, what a person still decides, and which number proves it worked. Below are twelve, grouped by department, from invoice intake in finance to the weekly report for management. Two come from our own published builds, with their measured results. The rest describe how the process usually runs, without invented percentages. Most of them need an integration platform such as Zapier or n8n plus the systems you already own. If you only want the short list, the examples most likely to pay back first are invoice intake, lead routing, order entry and new-hire onboarding, because each runs often on inputs that arrive in a predictable form.

Which examples are worth looking at, and how hard is each?

The difficulty column is our own rating of a first build in a small or mid-sized company. Low means two or three systems with stable APIs and simple rules. Medium means a matching or routing rule that has to be written down first. High means unstructured inputs, an old system without an API, or a rule the business has never agreed on.

"An integration platform" means Zapier, Make, n8n or code you own. Which one fits is a separate decision, covered further down; make vs zapier prices a lead-routing workflow like the one below on both.

How should you read each example?

Every example below follows the same five fields, because those are the fields that decide whether a project ships.

• Trigger: the event that starts the work. If you cannot name it, the process is not ready.
• Steps: what the software does, in order.
• Systems: where data is read and written.
• What a person still decides: the step that commits money, terms or access.
• What to measure: the number you pull before the build and again after it.

The fourth field matters most. A workflow that quietly agrees a discount or grants admin access is a liability however fast it runs, and our rules for keeping a person in the loop explain where we draw that line.

What can finance automate first?

Invoice intake and accounts payable matching. Trigger: a supplier invoice arrives in the accounts inbox as a PDF. Steps: extract supplier, invoice number, date, amounts and the purchase order reference; look up the purchase order and the goods receipt; compare the three (the "three-way match"); flag duplicates by supplier plus invoice number; post a draft bill with the document attached. Systems: shared inbox, document extraction, accounting or ERP system. A person decides: every invoice that fails the match, every invoice above an approval threshold, and any change to a supplier's bank details, which is a well-known fraud route and should never be accepted on the strength of an email. Measure: days from receipt to approved bill, share of invoices that pass without a touch, and duplicates caught.

The matching rule is where projects stall. "Matches" needs a written tolerance (exact amount, or within a set amount for rounding and freight), and the team may have been applying one by feel for years without writing it down.

Payment reminders. Trigger: an invoice passes its due date unpaid. Steps: send a polite reminder, a firmer one after a set interval, then create a task for a person. A person decides: anything sent to a customer in dispute or on a negotiated plan, which means the workflow needs a "do not chase" flag that someone keeps current. Measure: days sales outstanding and the share of invoices paid after the first reminder.

Expense receipts. Trigger: an employee photographs a receipt. Steps: read merchant, date and amount, suggest a category, attach to the card transaction, send to the approver. A person decides: anything outside policy. Measure: days from spend to reconciled entry at month end.

What does sales automation look like in practice?

Lead routing and first reply. This is our first published case, from a real estate brokerage. Trigger: an inquiry about a specific listing arrives through a portal, the website or a messenger. Steps: check whether the person already exists under another number or portal; check that the listing is still available; apply the agency's routing rule; reply within minutes with facts from the listing and viewing slots from the assigned agent's real calendar. Systems: listing portals, CRM, calendars, messaging. A person decides: the routing rule itself (round-robin, specialization or load, usually a blend), and anything binding, since the reply never negotiates or quotes outside the published price. Measure: time from inquiry to first reply, duplicate contacts, and out-of-hours inquiries answered.

The full write-up of the brokerage inquiries is careful about causation: the deal cycle moved because viewings, documents and pipeline visibility were fixed in the same project, with document preparation going from 2 days to 20 minutes. A project that fixes only first response gets a good headline number and a deal cycle that barely moves.

Quote and contract documents. Trigger: a deal reaches the proposal stage in the CRM. Steps: fill an approved template with the customer, line items and prices from the CRM, send for e-signature, store the signed copy against the deal. A person decides: any price or term outside the template. Measure: time from stage change to document sent, and the number of documents corrected after sending.

Which operations processes are worth automating?

Order entry and availability. This is our second published case, from an equipment rental firm. Trigger: a booking arrives by phone, email, form or messenger. Steps: turn a free-text request into a structured order; check availability against every state the asset can be in; reserve it at the moment of confirmation; assemble the agreement from an approved template; schedule dispatch. Systems: the existing rental system, the spreadsheet it replaced, messaging, drivers' schedules. A person decides: discounts outside the rate card, non-standard terms, customers with an open damage dispute, and any booking that leaves no buffer before the next job. Measure: booking-to-dispatch time as a distribution, double-bookings, and inquiries never answered.

Where the four hours went shows why it rates "High" in the table: availability turned out to have seven states, four of which leave the machine in the yard and still not rentable, so most of the work was data modeling. A language model handled one step only, reading inquiries written in the customer's own words.

Dispatch and delivery notices. Trigger: an order is confirmed. Steps: assign a slot and a driver, send the customer a confirmation, send a reminder the day before, notify on departure. A person decides: reshuffles when a job overruns. Measure: missed or late deliveries and inbound "where is my order" calls.

Stock reorder. Trigger: stock falls below a reorder point. Steps: draft a purchase order with the usual supplier and quantity, send it for approval, email it. A person decides: the reorder points and any change of supplier. Measure: stockouts and days of stock held.

What can HR automate without losing the human part?

New-hire onboarding. Trigger: the offer is signed in the HR system. Steps: create the email account and the default group memberships, open an equipment request, add the person to payroll, send a first-week schedule, assign required training. Systems: HR system, Google Workspace or Microsoft 365, IT ticketing, payroll. A person decides: access beyond the role's default, and the welcome itself, which should come from a manager rather than a template. Measure: days from signature to all accounts working, and access tickets raised in the first week.

Offboarding. Trigger: a leaving date is confirmed. Steps: schedule access removal for the last day, transfer file ownership, collect equipment, stop payroll. A person decides: the date, and what happens to shared accounts. Measure: accounts still active after the leaving date, which should be zero. This one can matter more than onboarding, because an account left open after someone leaves is a security problem.

How does support ticket triage work?

Ticket triage and first draft. Trigger: an email or ticket arrives. Steps: classify the type and urgency, attach the customer's order or account, draft a reply from the knowledge base, route to the right queue. Systems: helpdesk, CRM or order system, knowledge base, a language model. A person decides: whether to send the draft, and every refund, credit or exception. Measure: time to first response, share of drafts sent with light edits, and tickets reopened.

This is where a model does real work, because tickets arrive as free text. Keep the boundary sharp all the same. The model drafts and classifies; it does not grant refunds.

What can management automate?

Weekly operating report. Trigger: a schedule. Steps: pull last week's numbers, compare with the week before, email a short table to the people who act on it. A person decides: what the numbers mean. Measure: whether anyone reads it. A report nobody opens should be switched off, and improving it will not help.

Which example should you start with?

Pick the process that passes four filters, kept from the earlier version of this guide because they still hold:

Then measure before you build. At the rental firm we spent a week counting from the systems before writing anything, and two of the four numbers everyone expected to matter turned out not to: the average hid a slow tail where customers gave up, and annual volume flattened a peak season that earned most of the year. The method is the first stage of a process audit before automation, and the payback sum you can do on your own is on is my process worth automating.

What tools do these examples run on?

Most of the examples above need an integration platform plus the systems you already own. The billing unit decides which platform is cheaper for a given example. Zapier counts a task each time it completes a unit of work, and triggers and polling do not count, so a workflow with a trigger and five actions uses up to five tasks per run. n8n counts one execution per run of the whole workflow: "It doesn't matter how many steps are in the workflow." Both pricing pages were read on 2026-10-07. Multi-step examples such as invoice matching or onboarding therefore favour per-run billing as volume grows, while a two-step reminder is cheap anywhere. The worked numbers are in n8n vs Zapier, and the INITE Atlas card for Zapier keeps its pricing with the date it was read.

Where a system has no API, a screen robot can fill the gap; the RPA implementation guide covers when that is worth the maintenance. For the full set of workflows we build, see AI automation.

Why do automated processes break later?

They tend to fail months after launch, when a supplier changes its invoice layout, a CRM field is renamed, or a vendor alters its API, a pattern described in when the integration changes underneath you. Three habits keep them alive:

1. Run last week's real cases through the workflow every week. A frozen test set does not drift; production does.
2. Log each step's input, output and decision. When something breaks, the log shows where.
3. Keep a person checking a random sample of cases indefinitely, chosen at random rather than only the flagged ones, so quality drift shows up before customers notice it.

Each workflow also needs one named owner. Without one, nobody notices when the match rate slides or the reminders stop, and the automation decays quietly while still looking switched on. Before accepting any figure a vendor quotes for these examples, ours included, run it through the four questions that break most ROI claims.