How to Automate Business Processes: An Operator's Guide

How to automate business processes without buying a shelf of tools that nobody uses? Start with one chore that eats hours, has documents coming in, and ends with a person typing the same fields into the same software over and over. That is the shape of a real candidate. The rest of this guide is about how to spot it, what a working system looks like inside the software you already run, and when to walk away from the build entirely.

Key takeaways

• A good automation candidate has three traits: it repeats, it starts from a document or record you already receive, and a person is currently re-keying the result into a system like your ERP.
• Real business process automation reads your existing inputs and writes into your existing software; it does not replace your ERP or ask your team to work inside a new app.
• Every write to a live record should route through a person on your team for approval. Full autonomy over money-touching systems is not a feature, it is a risk.
• Throughline built a rebate-and-margin recovery system inside Kelsan, a multi-state distributor in our group running Epicor P21, that has recovered over $100,000 in margin.
• Every Throughline engagement starts with a fixed-fee AI Capability Audit at $7,500. The initial call is free.

What "automating a business process" actually means

Two different things get called automation, and confusing them is expensive.

The first is task-level plumbing. Move a row from a spreadsheet to a CRM. Send a Slack message when a form is filled out. Useful, cheap, and mostly not what a mid-market operator needs when they say the back office is drowning.

The second is a system that reads the documents and records you already receive, makes a decision about them, and writes structured entries back into the software that runs your business (your ERP, your accounting system, your order management tool). That is business process automation in the operator sense: the manual work goes away because the software that already holds your data now has a helper that reads the inputs and drafts the entries. A person approves. The record posts.

The distinction matters because the first kind is a subscription you cancel in six months. The second is a system you keep.

How to pick the first process to automate

Look for four traits at once. Miss one and the payoff gets thin.

It repeats. If it happens twice a year, write a checklist instead. Automation earns its keep on volume.

It starts with a document or a record. A supplier statement, an invoice, an emailed order, a PDF rebate agreement, a spreadsheet from a vendor. Something structured enough to read, unstructured enough that a person is currently doing the reading. This is where intelligent document automation earns its budget.

A person is re-keying the result into a system of record. If the output of the work is fields getting typed into your ERP, your accounting system, or your CRM, you have a candidate. If the output is a decision that lives only in someone's head, you have a different problem (a training or hiring problem, not an automation one).

The dollar impact is legible. You should be able to say, in one sentence, what breaks or leaks when this work is late or wrong. Missed rebate credits. Late invoices. Wrong margins on quotes. If nobody can name the cost of the current process, automation will not fix that.

Rank your candidates on those four. The top of that list is where the back office automation work usually lives.

What a real system looks like inside your existing software

Here is the mechanism, plainly.

A tool reads the documents you already receive (PDFs, emails, spreadsheets, EDI files). It extracts the fields that matter. It matches those fields against records already in your system (invoices, purchase orders, customer accounts). It drafts an entry, a credit, a journal line, a corrected quote. A person on your team reviews the draft and approves it. The approved entry writes back into the software that runs the business.

That last step is where most "AI" pitches fall over. The interesting work is not the reading, it is the writing back. Getting a language model to summarize a document is easy. Wiring the output into a live ERP so it posts a real record with the right general ledger account, the right customer, the right period, that is the work. That is ERP automation, and it is where a system either pays for itself or becomes a demo that never ships.

A first-hand example

We built a rebate-and-margin recovery system inside Kelsan, a multi-state distributor in our group running Epicor P21. Supplier rebate documents arrive in the shapes you would expect: PDFs, spreadsheets, agreements with tiered structures and quarterly windows. The tool reads those documents, matches the terms against invoices already in P21, and surfaces the entries where money is owed. A person on the Kelsan team reviews each entry and approves it before anything posts. To date, the system has recovered over $100,000 in margin that would otherwise have been lost.

Two things about that system are worth underlining. First, nobody at Kelsan works in a new app. The system lives inside P21, the software they were already running. Second, the humans stayed in the loop on every write. That is not a limitation. It is the design.

If you want the longer version of the story, see the rebate-and-margin tool we built inside Kelsan or the broader case for AI for distributors running P21.

When not to automate

Some processes should stay manual. Be honest about which.

Skip automation when the process runs a few times a year, when the inputs change every time (no repeatable shape), when the real problem is a policy nobody has written down, or when the "process" is a person exercising judgment on unusual cases. Automating a bad process just produces bad outputs faster.

Skip it too when nobody on your team will own the approvals. A system that drafts entries needs a person who reads them. If you cannot name that person before the build, the build is premature.

What it costs and how it gets scoped

Cost has two parts. The build is a fixed fee, quoted in writing after we understand the process. The running cost is metered like any cloud service (compute, model calls, storage), and we quote a range before you commit.

Every Throughline engagement starts the same way: a fixed-fee AI Capability Audit at $7,500. We look at the processes you named, the software they touch, and the documents that flow through them. You get a written recommendation: what to build first, what to skip, and what the build will cost. The audit is useful whether or not you hire us to build.

If you are still comparing categories of partner (enterprise consultancy, offshore dev shop, no-code agency, builder-operator), the buyer's guide on how to choose an AI partner lays out the tradeoffs plainly.

Ready to figure out which process is worth automating first?

Book a call with Throughline, or start with a fixed-fee AI Capability Audit ($7,500). The call is free. Call 865-417-3554.

About the author

Throughline is a small team of builders inside Keller Group. We build AI systems into our own operating companies first, then into yours.