Business process automation examples: 14 real workflows, by department

Common examples are invoices raised and chased from a CRM status, supplier invoices read from a photo and confirmed by a person, purchase orders approved automatically within a spend limit, website leads routed to the right person with a response clock, a won deal opening its delivery project, an order parsed into a job with an SLA clock, onboarding packets sent and chased on a cadence, and appointment reminders that never message anyone twice. All fourteen below are builds we delivered, not hypotheticals, and each names where you can read the detail on our work pages.

What makes them good examples is not the tool they run on. Some are Make scenarios, some are Zapier builds, and some are purpose-built systems on a database. What they share is a trigger that already exists as data, a chain of steps that is the same every time, and a clear place where the automation stops and a person takes over. When one of those three is missing, the automation tends to be the thing people work around rather than the thing that does the work.

Strip the tools away and every example below has five parts. If you are sketching your own, write these five lines before you choose a platform.

1. 01A trigger that a system already records: a form submission, an email arriving, a status column changing, an invoice reaching zero due. If the trigger is someone remembering, there is nothing to automate yet.
2. 02Steps that are the same every time: look up the record, create the document, send the message, write the result back. These are the steps that go.
3. 03A human gate: the point where a person confirms, approves or decides. In every build cited here, money, compliance and anything said in public sit behind one.
4. 04A write-back: the outcome recorded where the team already looks (an invoice number on the CRM item, a status of 'Added', a log row), so nobody has to ask whether it happened.
5. 05A loud failure: an error that lands in a channel, a log or a manual list a person works, rather than a run that quietly did nothing.

Business process automation and workflow automation are often used as synonyms, and most of the examples work as either. The difference we draw is scope. A workflow automation is one chain of steps between tools: this form creates that record. Business process automation is the whole process those chains serve, including the approvals, the records that prove what happened and the exceptions. Most of the examples below are one workflow; the case studies are whole processes.

Finance is where most businesses should look first. The triggers are already data (an invoice, a status, a payment), the rules are usually written down somewhere, and a mistake is noticed quickly because someone is owed money.

1. Supplier invoice capture, confirmed by a person

• Trigger: someone photographs a supplier invoice.
• Steps: a vision model reads the line items and presents the extraction for review. On confirmation the system creates the purchase invoice and moves stock quantities, item cost prices and the supplier balance. If one AI provider fails, the scanner moves to a second.
• A person decides: whether the extraction is right. Nothing is written on the model's reading alone; only the confirmation creates the invoice.
• Shown in: the case study 'An ERP with AI invoice capture and an audit trail that holds', for a regional trading and distribution group. Its tiles read '18 operational modules' and '2 AI providers, auto-failover'.

2. A CRM status change raises the invoice, and a schedule chases it

• Trigger: a student's billing status changes in a monday.com CRM.
• Steps: find the contact in Xero (creating it if missing, for two of the three fee types), create an authorised invoice due in seven days from the CRM's price and item code, send it through the accounting system, and write 'Waiting Payment', the invoice number, the issue date and the link back onto the CRM item. Scheduled reminders then read that status: friendly before the due date, firmer once overdue.
• A person decides: when to set the status, and what to do about a disputed or unpaid invoice.
• Shown in: the Make flow 'A status change raises the invoice; a schedule chases it', for a vocational training provider. Its page shows '3 invoice types: recurring, enrolment, upfront', '7 days from issue to due date' and '78 runs, one error'. It also says plainly that the three reminder scenarios are switched off, that nothing writes 'Paid' back, and that selecting the trigger label twice raises a second invoice. Those are the gaps we would close first in a rebuild.

3. Purchase orders that approve themselves within limits

• Trigger: someone raises a purchase order.
• Steps: each person has a spend policy, and the order wizard shows a live verdict on whether the order will auto-approve before it is submitted. Orders over the limit route to finance, a director or operations. Goods are received against order lines, with partial deliveries tracked, and the supplier invoice is matched in one click against what was ordered and delivered.
• A person decides: every over-limit order, and whether a mismatched invoice gets paid.
• Shown in: the case study 'One login for a solar business, in place of a patchwork of tools', for a UK commercial solar installer, live with the client team. The same idea appears in the trading ERP above, where invoices move from draft to pending review to approved, and anything not yet approved is deliberately left out of revenue, purchases and outstanding totals.

4. Shop orders into the accounting system, line by line

• Trigger: an order is placed in a WordPress/WooCommerce shop.
• Steps: the order lands on a monday.com board, then becomes an invoice in Xero carrying every line item rather than a single total.
• A person decides: anything the order does not settle, such as refunds, credit notes and orders that need checking before they are billed.
• Shown in: a build we delivered on Zapier. We have no published case study for it, so there are no figures to quote. The same shape (a sale recorded once, then mirrored into the books with its lines intact) applies to QuickBooks or any other accounting system with an API, though we cite no QuickBooks build here. Our WooCommerce to Xero integration article covers this pairing in depth.

Beyond these, we have built accounting workflows and integrations that are not written up as case studies. Where a finance process is the main problem, our finance workflow automation, accounts payable automation and AI invoice processing pages go further than this article.

Sales automation is mostly about joins: between a form and the CRM, between the phone and the record, between a won deal and the people who deliver it. The leak is rarely a missing feature. It is a lead nobody claimed, or a deal that was re-keyed wrongly into the next tool.

5. Website and ad leads routed to a person, with a response clock

• Trigger: a website lead arrives as a notification email, or a lead-ad form is submitted.
• Steps: a model tidies the email into labelled fields; the lead is posted as a Slack card, written to Airtable and upserted into the CRM, with region and other fixed-list values mapped by rules rather than by the model. In business hours, after five minutes the scenario reads the claim thread and nudges the first owner if nobody has replied, then hands over to a second owner five minutes later. For the lead-ad version, each submission is looked up first, so a returning lead gets a note on its existing record instead of a duplicate.
• A person decides: who calls the lead, and what to say.
• Shown in: the Make flow 'A website lead becomes a card, a record, a contact and a response clock', for a short-term-rental company: '4 routes from a single parse', '10 min response clock, two escalations' and '31 runs, three on a lapsed connection'. Its page says it ran for about a month and was switched off on 2 October. The lead-ad version is 'One lead form, one scenario: lead-ad submissions into the CRM, once', for a vocational training provider, with '286 runs, no errors'.

6. Calls, voicemails and replies onto the CRM record

• Trigger: an event from the cloud phone system (a call, a voicemail), or a lead replying to a shared mailbox.
• Steps: every call becomes a row on a calls board; a voicemail becomes a routed follow-up task. A reply is matched to its CRM lead by sender address and forwarded to the rep who owns the lead, rather than sitting in a shared inbox.
• A person decides: the call back, and the reply.
• Shown in: the Make flows 'Every call on the board, every voicemail a task' ('2,783 call events logged, no errors' and '127 voicemails turned into tasks') and 'A lead's reply lands in their rep's inbox, not the shared one' ('441 runs in each forwarder, no errors'), both for the vocational training provider.

7. A won deal opens the delivery work

• Trigger: a deal is marked won.
• Steps: the system opens one project per building the deal covers, each with its own delivery board, tasks, milestones and procurement starters, and splits the contract value across the buildings, with a test that keeps the parts summing back to the total. Re-running the win is safe: a building linked later gets its project on the next run, with nothing duplicated.
• A person decides: that the deal is won, and everything about how the work is then delivered.
• Shown in: the case study 'An ops platform where the building is the record, not the deal', for a commercial solar installer, with the tile '1 project per building, on winning'. A smaller version of the same idea is the Make flow 'When the item moves, something happens: document chasers, milestones and billable rows', where moving a lead into a document follow-up group sends the email for that lead's pathway and sets a follow-up date two days out: '6 pathways, one email template each' and '17 runs, no errors'.

One more sales example worth knowing about, because it answers a question most small businesses cannot: which enquiries became sales. The Make flow 'Which enquiries became sales: matching quotes and invoices back to the lead', for a trailer manufacturer, normalises each enquiry's email and phone at intake, then matches the quotes and invoices raised in Xero back to the lead every four hours. Its page shows '523 runs; five early errors, none since', and says it matches by email alone, so a customer invoiced under a different address is not linked. Our CRM automation page covers this kind of work as a service.

Operations examples are where clocks and gates matter: a commitment measured in business days, or a physical thing that must not move until something else is true.

8. Order intake to installer allocation, with an SLA clock

• Trigger: an order document arrives at a webhook.
• Steps: the order is parsed into structured fields and the monday.com row fills itself in, matched against existing records so a resent order updates rather than duplicates. One install item is created per site; setting the installer sends an SMS; a two-business-day clock runs against a real public holiday calendar and escalates on its own. Installers update status from a page showing only their own jobs.
• A person decides: which installer gets a job, and what to do when an escalation fires.
• Shown in: the case study 'Orders that file themselves, and an SLA clock that never forgets', for a fleet-telematics provider: '2-day SLA clock, business days' and 'Shadow mode before cutover'. The allocation and SLA layer ran alongside the manual process, logging what it would have done, before it was trusted with the real thing. That shadow-mode step is worth copying for any automation that touches a live board.

9. A paid invoice releases the unit

• Trigger: a signed delivery note is submitted; separately, an invoice reaches nothing left to pay.
• Steps: the handover pack (delivery note, ID, payment proofs, registration document, photos) is attached to the invoice in Xero, with the unit's VIN written on as its reference. Every fifteen minutes in business hours, a watch looks for invoices fully paid; the first time it sees one, it creates a release form prefilled with invoice number, VIN and customer and emails the branches.
• A person decides: the handover itself, and whether the unit actually leaves the yard.
• Shown in: the Make flow 'The invoice carries the handover: delivery packs filed, units released when paid', for a trailer manufacturer: '11 router branches per handover, each fail-soft', '15 min between release checks, in business hours' and '1,926 runs in the last 30 days'. Its page is candid that most of those runs are one-operation polls that find nothing newly paid, and that a rate-limit morning produced most of its errors before it was changed to process runs one at a time.

10. Quotes: from enquiry to a priced draft

• Trigger: a customer enquiry, or an estimator's plain-English brief.
• Steps: for a heat-pump installer, the enquiry runs through grant rules, price bands and the kit list held as validated settings, and the system refuses to quote if a setting is missing rather than guessing. For an AV integrator, a model turns the brief into sections and picks parts only from the price book, and code sets every price, with each line showing where its number came from.
• A person decides: the final quote. In the heat-pump build a designer reads every scanned survey; in the estimating demo the estimator edits and owns the draft.
• Shown in: the case studies 'Heat-pump quotes with the compliance gates written into the code' (in build, '42 settings keys held as validated data') and 'An estimating assistant where the model names the parts and code sets the prices' (a working demo, '100% of prices set by code, none by the model'). Neither is in front of customers, and both pages say so.

Onboarding is a chase with paperwork attached: send something, wait, remind, file what comes back, and decide whether it is acceptable. The first four steps automate well. The last one should not.

11. Worker onboarding and rostering with compliance gates

• Trigger: a new worker signs up; an event needs filling.
• Steps: recruitment, right-to-work, rostering, check-in and pay sit in one system instead of a legacy tool and manual follow-up. A headless browser runs the right-to-work check and stores the result and photograph (built, and switched on only once the agency signs off the legal position and a live test passes). Filling an event runs hard gates first (role, blocked workers, double bookings with a two-hour gap between venues, the weekly hours cap) and only then scores what remains. Pay is computed from check-in and check-out against the booked shift.
• A person decides: whether a worker is verified. An administrator compares the photo with the worker's selfie and presses Verify or Reject; the automation never marks anyone verified.
• Shown in: the case study 'A staffing platform that keeps its rules in the database', for a UK event-staffing agency: '3 front ends over one database' and '5,000+ database assertions in CI'. It is live with the agency's office, workers and venues, and its page says what was audited before go-live and what is not claimed.

12. Vendor onboarding packets: send, chase, file

• Trigger: a vendor becomes eligible for a packet; a daily schedule; a signed packet coming back.
• Steps: each vendor gets a personal tokenised link; reminders go out at 7, 14, 21 and 28 days, with a final-reminder tone from the third; a returned packet is matched by token, then by email, filed in the vendor's folder, and a row is logged for each document supplied.
• A person decides: whether the vendor is compliant. Status is set to received, pending review, and expiry dates are left for a person to check.
• Shown in: the Make flow 'Vendor onboarding packets: sent with a token, chased on a cadence, filed for review', for a short-term-rental company: '3 scenarios: send, remind, collect', '4 reminders, at 7, 14, 21 and 28 days' and '6 document types logged per packet'. Its page says the run history is short and the send and reminder scenarios are switched off, so it describes a design rather than a volume.

The same pattern covers access. In the Make flow 'Approving a person should give them the right seat, team and boards', for a workforce-development programme, an approval is the only human step, and the guest invitation, team memberships and board access follow from it ('8 scenarios across three audiences'). It was built ahead of intake and has run only five times, which its page says.

13. Clinic appointment reminders and patient recalls

• Trigger: a daily schedule at each site; a patient becoming due for a check.
• Steps: at midday, every patient booked for tomorrow is sent a reminder and logged; at six, a catch-up pass sends only to bookings missing from that log, so nobody is messaged twice. Recalls read eligibility from a formula staff can edit, send at most 100 a run, stamp the patient so they drop out of the list, and a webhook records who replied or booked.
• A person decides: who is due (by owning the eligibility rule), and follow-up for anyone the system could not reach, who lands on a manual list.
• Shown in: the Make flows 'Appointment reminders at noon, and a catch-up pass at six' ('2 passes a day: noon and 6 PM', '3 sites, one branch each', '74 runs, recent scheduled runs all successful') and 'A recall loop that logs every message and hears who came back' ('100 patients per run at most'), for a multi-site clinic. Both pages note that the scenarios do not check consent or opt-out themselves. Separately, we have connected Gravity Forms to Cliniko with conditional logic and different settings per case: a build we delivered on Zapier, with no published figures.

14. Short-term rental: an owner's email becomes a calendar block

• Trigger: a form notification email asking to block a property for the owner's own stay, edit it or cancel it.
• Steps: a model classifies the email as new, edit, cancel or a notification to ignore and extracts the dates; the scenario checks the live calendar and creates the block only if every night is free, cancels the cleaning task the system creates (waiting five minutes and trying up to three times), confirms to the owner and posts to Slack. Every exception goes to a person through an error log and an alert.
• A person decides: every conflict. A clash is sent to the owner and the admin team rather than resolved by the automation.
• Shown in: the Make flow 'Owner stays blocked from an email, and the cleaning cancelled five minutes later': '5 min polling interval', '8,657 runs, no errors recorded' and '3 tries to catch the cleaning task'.

A few more, more briefly. A school group's fee chasing became a scheduled WhatsApp reminder from templates rather than a notebook (the case study 'School management ERP with permissions enforced per branch'). A solar installer's marketing team gets four drafted LinkedIn posts a week in an approval queue, with a publisher that has made '4,000+ unattended publisher runs in two weeks' and posts nothing that has not been approved (the case study 'A content engine that is not allowed to make things up'). A construction-materials marketplace keeps its rules in data rather than in someone's head: the home page reads live supply against a threshold to decide which side of the market to recruit, and enquiry limits are counted per buyer and seller (the case study 'A marketplace that recruits whichever side of itself is short'). That last one is less a workflow than a rule that runs itself, which is often the better answer.

Beyond the published work, we have built CRM and project-management tool setups, solar CRM and ERP systems, and ERP, CRM and project-management systems for hospitality, events and furniture businesses, plus Zapier builds connecting Airtable with Calendly, Heymarket SMS and a range of form tools. None of those is written up with figures, so we do not quote any.

Pick the process that passes four tests, and among those, the one whose failure costs you most. The tests are about whether the process is ready to be automated, not about how much it annoys people.

1. 01It has a trigger a system already records. A status column, a form, an email from a platform, a payment. If the trigger is 'when someone notices', the first project is getting that event into a system, not automating what follows it.
2. 02It happens at least weekly. A process that runs four times a year is cheaper to do by hand with a checklist, and an automation that rarely runs is one nobody remembers how to fix.
3. 03Its rules can be written down today. If two people would do it differently and both are right, settle the rule first. Automating an argument fixes one side of it in place.
4. 04A failure would be noticed. Choose a process where a missed run shows up quickly (an unpaid invoice, an unclaimed lead), and build the alert anyway.

Among the processes that pass, the best first project is usually a hand-off between two systems you already own, triggered by a status change: CRM to accounting, form to CRM, board to board. Examples 2, 5 and 7 above are that shape. They need no new system, the people involved already work in both tools, and the write-back makes the result visible on day one. Run it in shadow mode first where it touches anything live, as in example 8: let it log what it would have done for a week or two, compare that with what people did, and only then let it act.

Automation makes a process run the same way, faster. That is a problem whenever the process is not yet the right one, or when running it the same way every time is the wrong goal.

• When the rules are still being decided. The heat-pump business above did not yet know its own prices or grant figures, so the build holds them as settings and refuses to quote without them. If you cannot do even that, write the rules down by hand for a month first.
• When a step exists only to correct an earlier step. Automating both makes the mistake and the correction faster. Fix the first step.
• When the input is still on paper or in someone's head. The trading ERP's first job was recovering the history trapped in a desktop ledger ('3 yrs of history recovered'), before any capture was built. Automating on top of records you cannot trust only spreads them faster.
• When the work is a judgment call that only looks routine. Claims, compliance, refunds and public replies can be read and drafted by automation, but in every build of ours that touches them, a person decides. The Make flow 'An AI claims adjudicator, a blind cross-check, and a human at every gate' cannot approve a claim or move money, by design.
• When volume is too low to repay the build or the upkeep. A checklist and a calendar reminder beat an automation for a quarterly task.
• When the honest answer is a native feature. Many tools have built-in rules that cover a single-board or single-app case. Use those before you add a second platform; our monday.com automations article covers where that line falls for monday.com.

And the examples above have limits of their own, which their pages state: an invoice that is not idempotent, a matcher that uses email alone, reminders with no opt-out check, scenarios with no error route. Those are the usual ways automations fail quietly, and our article on why automations break covers them. An example is a starting point, not a specification.

If one of these examples looks like your process, read its case study or flow page for how it was built and where it stops. If you want help mapping and building your own, our business process automation service page is the place to hire us: the work starts with mapping the process as it is actually done, exceptions included, before anything is built. For what it costs, read our article on how much business process automation costs; for choosing a platform, our Make vs Zapier vs n8n comparison.