Business Process Automation Services: The Two Halves

Every provider on this search sells the same shape of engagement: a process assessment, then bots, then support. The bots are the part worth being precise about, because the technology under most of this category does one specific thing, and the step that actually costs you money in a real process is usually not that thing.

A federal audit of the US General Services Administration's own automation program describes the mechanism plainly. Robotic process automation uses bots, software applications that simulate human actions, and those bots interact with existing systems to copy data, fill in forms, sign into applications and send emails. That is a fair description of the whole category as it is normally sold, and it tells you the boundary: a bot drives the screens you already have, by rules you wrote in advance.

Which means it is excellent at the half of your process that is already decided, and it cannot do the half that requires reading.

Split the process before you buy anything

Take one process you would actually pay to automate and write it out as steps. Not the diagram a vendor draws, the steps as a person does them this week. Then mark each step with one of two labels.

Deterministic. The rule is already known and does not change with the input. Look up the supplier in the ledger. Check the total against the purchase order. Route anything over the approval limit to the right approver. File the document under the vendor and the month. Email the requester. Every one of these is a rule somebody can state in a sentence, and that sentence does not change when a different document arrives.

Model-dependent. The step requires reading something whose shape you do not control. Which of these figures is the invoice total, when the layout is different for every supplier. What was actually agreed in this email thread. Which of the three dates on the page is the one the payment terms run from. Does this complaint need a person today. These steps cannot be written as rules because the input has no fixed structure, and a rule that works on one supplier's PDF fails on the next.

Most processes come out heavily deterministic by step count and heavily model-dependent by cost. Twenty of the twenty-five steps are rules, and the two that need reading are where the hours go, which is why a provider who sells only one of the two tools will scope the process in a way that flatters the tool they sell.

Do not put a model where a rule works

This is the expensive mistake of the current moment, and it runs in the opposite direction to the usual advice.

A rule re-run on the same input gives the same answer, costs nothing per execution, and can be read by the person who has to sign off on the process. None of those three things is true of a language model. If a step already has a correct rule, using a model for it buys you a per-call bill, a result that can vary between runs, and an explanation problem the first time somebody asks why that invoice was approved.

So the order of work is: automate the deterministic half with deterministic software, which is what this category has always been good at, and only then look at what is left. What is left is the part worth paying attention to, and it is usually small, which is good news for the budget and bad news for anybody selling a platform licence by the seat.

The reading half needs a boundary, not an accuracy score

When a step genuinely needs a model, the question that matters is not how accurate it is. It is what happens on the wrong answer.

A model asked to find the total on a document it cannot read does not return nothing. It returns a plausible figure, in the right format, with no sign that anything went wrong. That is the failure this half of the work is built around, and the handling is the same every time: decide per field whether a wrong value is recoverable or not, and put a person in front of the ones that are not. A misfiled document is recoverable. A payment released against a figure nobody checked is not.

In practice that means a short list of fields that cannot pass unreviewed, a confidence threshold that sends anything uncertain to a queue instead of onward, and an actual person who owns that queue. The mechanics of extracting fields from documents, including the checks that catch a reading that was right and a writeback that was lossy, are worked through in what AI document processing actually involves.

Governance frameworks exist for this and are worth reading before you write your own policy. NIST publishes an AI Risk Management Framework, intended for voluntary use, with a profile aimed at the risks specific to generative AI. It will not tell you which fields in your invoice need a human. It will tell you what you are supposed to have decided.

Cost the model-dependent half before you scope the project

The deterministic half is a build cost. The model-dependent half is a build cost plus a bill that arrives every month and scales with volume, and that second part is the number most proposals leave as a footnote.

You can estimate it before committing to anything. Take one real document of the kind the process handles, count what it would cost to read it once, and multiply by how many arrive. Our LLM cost calculator does that arithmetic across models, which matters because the same process can be a rounding error or a real line item depending on which model the reading step uses and how much of the document you send it. Run it on your highest volume document type first, because that is where a wrong assumption compounds.

Two things make this estimate go wrong in the same direction every time. Retries are real traffic, and a step that fails on a bad scan and runs again has been paid for twice. And the first version of any extraction prompt sends far more of the document than it needs, so the figure you measure during a pilot is usually the worst it will ever be, not the best.

The automation is an identity, and somebody has to own it

This is the part the vendor pages skip, and it is the part that turns up in audits.

The same federal audit named above found that the agency's automation program did not comply with its own IT security requirements, did not consistently update system security plans to account for access by bots, and had no process for removing access when a bot was decommissioned, which left access in place that nothing needed. The report is worth reading in full if you are about to put automation into a system that holds customer or financial data: GSA Should Strengthen the Security of Its Robotic Process Automation Program, published in August 2024.

The lesson transfers to a company of any size. An automation signs into your systems, which means it holds credentials, which means it is an account. Decide three things before it goes live. Which systems it can reach, and whether that is less than the person whose work it took over could reach. Who is notified when it fails, as opposed to who finds out from a customer. And what the shutdown looks like, because the automations that cause trouble are almost never the ones somebody is actively watching, they are the ones that were switched on for a project that ended.

What to ask a provider

Four questions separate the providers who will scope this honestly from the ones who will scope it to fit their platform.

Ask which steps of your process they consider deterministic and which need a model, and whether they would say the same if you asked them to quote for only the deterministic half. Ask what the per-document running cost is at your volume, as a figure, not as a range that happens to end above your budget. Ask which fields their design sends to a human and who that human is. And ask what access the automation needs, and how that access is removed.

A provider who has done this before will answer all four in the first conversation, because the answers are the design. A provider selling a platform will want the assessment first.

Start with the process, not the category

If you are choosing between buying a product and having something built around how your business actually works, the split above is most of the answer. The deterministic half is well served by products that already exist. The model-dependent half is specific to your documents and your tolerance for a wrong field, and that is the part worth building deliberately.

What AI automation services should cover walks through the engagement shape, and what a small business should expect from an AI consultant covers the choosing. If you would rather start from your own process than from a sales conversation, our free AI readiness assessment asks the questions a scoping call opens with, including which steps carry a consequence you cannot reverse.

For more on building and measuring these systems, see the rest of our writing.