Business Process Automation: What to Automate First
Most companies that invest in business process automation are automating the wrong processes. Gartner predicts that over 40 percent of agentic AI projects will be canceled by the end of 2027 because of escalating costs, unclear business value and inadequate risk controls. An MIT Media Lab study of enterprise deployments found that the overwhelming majority of generative AI pilots produced no measurable impact on the profit and loss statement. Those two findings describe the same failure, and it is not a technology failure.
The failure is selection. Companies pick the process that is most visible, most annoying, or most requested by the loudest department, then discover eighteen months later that they spent six figures making a low value activity slightly faster.
I am not writing this as a software vendor. I have founded and run companies, I have bought automation that worked and automation that quietly rotted in a corner of the stack, and I now work with founders and operators on both sides of the Atlantic from Miami. What follows is the method I use to decide what to automate, in what order, at what cost, and how to know within ninety days whether it worked.
What business process automation actually is
Business process automation is the use of technology to execute a recurring sequence of business activities with minimal human intervention. That definition sounds obvious, and it hides the single most important distinction in the field: automation replaces the execution of a process, it does not replace the design of a process.
If the process is badly designed, automating it produces the same bad output at higher speed and lower cost per unit of badness. This is the most expensive mistake in the discipline and it accounts for a large share of the failure statistics quoted above.
There is a second distinction that matters commercially. Business process automation is not a single technology, it is a stack of four different capabilities that get sold under one name.
Rules based automation. Deterministic workflows: if this happens, do that. Approval routing, notifications, data transfers between systems. Cheap, reliable, boring, and responsible for most of the value actually delivered in the last decade.
Robotic process automation. Software that mimics human interaction with user interfaces, used when systems have no usable interface for integration. Fast to deploy, expensive to maintain, brittle when the underlying screens change.
Document and data intelligence. Extraction and classification of unstructured inputs: invoices, contracts, claims, emails. This is where machine learning genuinely changed the economics, because the alternative is human reading.
Agentic execution. Systems that plan a sequence of steps toward a goal, call tools, and adapt when conditions change. Genuinely new capability, genuinely immature governance. I covered the mechanics of this layer in the guide to agentic AI and how it works.
Most vendors sell one layer and describe it as the whole discipline. Most buyers need three of the four, in an order that depends on the process, not on the vendor.
What business process automation is not
It is not digital transformation. Transformation changes what the business sells and how it competes. Automation changes how work gets executed. The two are related and they are not substitutes, and conflating them is how a three month operational project becomes an eighteen month program with a steering committee.
It is not headcount reduction with a technical label. It can produce headcount effects, but companies that frame the project that way get organizational resistance from day one and lose the process knowledge they need to configure the system correctly. The people who understand the exceptions are the people who feel most threatened.
It is not a tool purchase. The software is typically between fifteen and thirty percent of total project cost. The rest is process discovery, integration, data cleanup, exception handling and change management.
Why most automation programs fail
The failure modes are consistent across industries and company sizes. I have seen the same five patterns in manufacturing, hospitality, healthcare services and financial services.
Automating a process nobody documented. If the only description of the process lives in the head of the person who runs it, the automated version will encode that person's assumptions, including the wrong ones and the undocumented workarounds. Discovery is not a formality, it is the project.
Automating the exception instead of the rule. Teams design for the hardest case because that is the case people complain about. The hard case is often three percent of volume. You end up with a system that handles the rare case elegantly and the common case awkwardly.
Buying the platform before defining the process. The sequence matters. A platform chosen before the process is understood forces the process into the platform's shape, and the mismatch shows up as configuration debt for years.
No owner with authority. A project sponsored by IT and resisted by operations does not ship. A project owned by an operations leader with budget authority and a named deadline ships.
Measuring adoption instead of outcome. Licence usage, number of workflows built, tickets closed. None of these tell you whether the business is better off. The MIT research on enterprise AI deployments identified this precisely: the organizations that captured value measured workflow change, not tool adoption.
The largest study available on this question points in the same direction. McKinsey's State of AI global survey, published in November 2025 with responses from 1,993 participants across 105 countries, found that 88 percent of organizations report regular AI use in at least one business function, while only 39 percent attribute any level of EBIT impact to it, and most of those report an impact below 5 percent. The distinguishing behavior of the small group capturing real value was not better technology selection. It was that they had fundamentally redesigned the workflows themselves, a practice the research identifies as one of the strongest contributors to measurable business impact.
That finding is the entire argument of this article compressed into one sentence. Companies that automate the existing workflow get a faster version of what they already had. Companies that redesign the workflow and then automate it get a different cost structure.
There is a sixth pattern that is less discussed and more expensive: automating a process that should have been eliminated. A meaningful share of recurring corporate activity exists because a system could not talk to another system, or because a report was requested once by an executive who left four years ago. Before you automate, ask whether the output has a consumer.
The process selection framework
This is the part that decides everything else. Score each candidate process from one to five on six dimensions, then rank.
Volume. How many times does this run per month? Automation economics are driven by repetition. A process that runs eight times a year is almost never worth automating, regardless of how painful each occurrence is.
Standardization. What percentage of instances follow the same path? Below about seventy percent, you are automating a decision, not a task, and the cost profile changes completely.
Rule clarity. Can you write the decision logic down without using the words "it depends"? If a human needs judgment on every instance, you are looking at augmentation, not automation.
Data availability. Is the input digital, structured and accessible through an interface? A process fed by paper, PDFs from twelve different senders, or a spreadsheet someone maintains manually will need a data project first.
Error cost. What happens when the automation gets it wrong? A misrouted internal notification is cheap. A misprocessed payment or a wrongly rejected claim is not. High error cost does not disqualify a process, it changes the required level of human review.
Value at stake. What is the annual cost of running this process today, including error correction, rework and delay? This is the number most companies cannot produce, and it is the number the whole business case rests on.
How to read the scores
Add the six scores for a maximum of thirty.
24 to 30. Automate now. These are the processes with high volume, clear rules and clean data, and they usually sit in finance operations, order management, and customer service triage.
16 to 23. Redesign first, then automate. The process is worth fixing, but automating it as it stands will encode the current mess. Expect the redesign to deliver a meaningful share of the total benefit on its own.
Below 16. Leave it alone, or eliminate it. Automating a low volume, judgment heavy, data poor process is the single most common way to spend a budget without moving a number.
One practical warning about this framework: run it with the people who actually do the work, not with the people who manage the people who do the work. The gap between the documented process and the real process is where the project either succeeds or dies, and only one of those two groups can see it.
If you run the scorecard and find that your top three candidates all score below sixteen, that is not a reason to lower the bar. It is a signal that the constraint sits in process design rather than in execution speed, and a short diagnostic conversation before committing a budget will save you the cost of finding out through an eighteen month project.
Where the value actually sits, function by function
After running this exercise across companies of very different sizes, the same clusters keep coming out on top.
Order to cash. Order entry, credit checks, invoicing, collections chasing, cash application. High volume, high standardization, clear rules, and the benefit shows up directly in working capital rather than in a soft productivity estimate. This is the single most reliable starting point for a mid sized company.
Procure to pay. Purchase requisitions, three way matching, supplier onboarding, invoice processing. Document intelligence changed the economics here more than in any other function, because invoice variety was the historical blocker.
Customer service triage. Classification, routing, first line responses, and retrieval of the answer from internal documentation. The gains are real, and the failure mode is deploying it as a wall between the customer and a human rather than as a filter.
Sales operations. Lead qualification, data enrichment, pipeline hygiene, quote generation, follow up sequencing. I laid out the concrete build sequence for this function in the guide to automating your sales pipeline with AI.
Employee onboarding and HR operations. High standardization, low error cost, immediately visible internally. Frequently a good second project because it builds internal credibility cheaply.
Reporting and reconciliation. Anything where a person exports data from one system, transforms it in a spreadsheet, and pastes it into another system. This pattern is the fingerprint of an automation opportunity and it is present in almost every company above thirty employees.
Notice what is absent from that list: strategy, product decisions, relationship management, and anything where the value comes from judgment about an unfamiliar situation. That absence is not a limitation of the current technology. It is the definition of what a process is.
Build versus buy: the decision that sets your cost curve
Every automation program eventually hits this question, and most companies answer it by instinct rather than by criteria.
Buy when the process is standard across your industry. Invoice processing, expense management, payroll, e signature workflows. Someone has solved this ten thousand times and their version handles edge cases you have not thought of yet. Paying for that is not a weakness, it is the correct trade.
Build when the process is the thing you compete on. If your fulfillment logic, pricing method or underwriting approach is the reason customers choose you, embedding it in a generic platform gives away the advantage and constrains it to the platform's model of the world.
Configure, do not code, in the middle. Most processes are neither commodity nor proprietary. For these, low code platforms are usually the right answer, provided that someone owns the configuration and it is documented. Undocumented low code builds become the new legacy system within three years, and they are harder to unwind than the code they replaced.
The financial framing matters more than the technical one. Buying converts capital expenditure into a recurring operating cost with a predictable curve. Building converts an upfront cost into a maintenance obligation that nobody budgets for and that grows with every integration. Neither is cheaper in the abstract. The relevant question is which cost your business is better equipped to carry.
The same logic applies to capability: whether you build an internal team or bring in outside help follows the same commodity versus differentiation test. I worked through that decision in detail, with a cost model, in the AI consulting versus hiring in house framework.
What business process automation actually costs
Vendors quote licence fees. Licence fees are the smallest line in the budget. Here is the structure of real project cost, expressed as a share of total first year spend for a mid sized deployment.
| Cost component | Typical share of year one | Notes |
|---|---|---|
| Software licences | 15 to 30 per cent | The only number most quotes contain |
| Process discovery and design | 10 to 20 per cent | Skipped most often, causes most failures |
| Integration and data work | 25 to 40 per cent | Scales with the age of your systems |
| Change management and training | 10 to 20 per cent | Underestimated in almost every plan |
| Ongoing maintenance | 15 to 25 per cent annually | Recurring, not one off |
The number that surprises operators is the last one. Automation is not a fixed asset that sits there producing value. Interfaces change, suppliers change formats, regulations change, and a workflow that nobody maintains degrades quietly until someone notices that a third of cases are being handled manually again.
The ROI model that survives contact with reality
Four steps, in this order, and the order is not negotiable.
Establish the baseline before you start. Pull twelve months of real data from the systems: volume, cycle time, error rate, cost of rework. If those numbers do not exist, building them is the first deliverable of the project and it belongs in the budget explicitly.
Pick two metrics, not eight. One efficiency metric and one quality metric. More than two and none of them get watched.
Set an honest measurement horizon. A finance operations workflow shows results in ninety days. A change to a business to business sales cycle with six month deals does not, and anyone promising otherwise either does not know your business or is selling.
Isolate the effect. If you changed pricing, staffing and season in the same quarter, you will never know what worked. Where possible keep a control: one branch, one region, one product line running unchanged.
The full mechanics of building this calculation, including how to handle costs that are real but do not appear in any budget line, are in the guide to measuring AI ROI for business.
Four real cases, and what they teach about selection
Market statistics frame the problem. What decides an outcome is a different kind of evidence. Here are four engagements I worked on directly, with the result and the lesson.
Sports betting operator: 30 per cent increase in sales. The work restructured segmentation and personalization using AI driven systems. The lesson is not the percentage. The project worked because clean behavioral data on customers already existed. Without that precondition, the same project would have spent its first six months on data cleanup, sold as strategy.
Hotel business: revenue from 9 million to 10 million euro. The levers were dynamic pricing and booking channel management. The additional million did not come from more volume, it came from a higher realized average rate, which means the incremental margin was almost pure. This is the profile with the best ratio between project cost and value created: no capital investment, better decisions on assets that already existed.
Medical center: 20 per cent increase in delivery capacity. Scheduling and workflow redesign, with no additional staff and no additional space. The lesson is that in service organizations, lost capacity never appears in the accounts. It shows up nowhere as a cost line, which is precisely why nobody attacks it until someone from outside measures it.
Agritourism business: doubled guest numbers. Distribution and positioning were rebuilt. The lesson is that below a certain company size the bottleneck is demand, not internal efficiency, and automating a process that serves a demand you do not have produces nothing.
The common thread across all four is that the result came from a decision made differently, not from a tool bought. In three of the four cases, automation was the delivery mechanism for the decision, not the decision itself. If you are evaluating where to start and cannot say which of those four situations describes your company, that conversation is worth having before any budget is committed, because forty minutes on the diagnosis is worth more than six months of a project built on the wrong premise.
Governance: the part that decides whether it survives
Automation programs die in year two, not year one. Year one has attention, budget and a sponsor. Year two has none of those and the system has to survive on its own.
Name an owner per workflow, not per program. Every automated process needs one person accountable for its output. Not a team, not a committee. When exceptions accumulate, someone has to notice.
Instrument exception rates from day one. The single best early warning signal is the share of cases falling out of the automated path. When it climbs, something upstream changed. Companies that do not track this discover the problem when a customer complains.
Keep a human decision point where error cost is high. Full automation is not the goal, appropriate automation is. A workflow that routes ninety percent automatically and escalates ten percent to a person is usually better business than one that routes one hundred percent and is wrong two percent of the time in expensive ways.
Write down what the system is allowed to do. As agentic capabilities enter the stack, the boundary between "the system suggests" and "the system acts" becomes a real governance question with real financial exposure. That boundary belongs in a document, approved by someone senior, not in a configuration file that a contractor set up.
Review quarterly and retire aggressively. Workflows accumulate. A significant portion of automations built three years ago are running against processes that have changed, producing outputs nobody reads. Retiring them is as valuable as building new ones.
The people side follows the same logic. Automation changes what a role does, and if nobody says so explicitly, the affected team will define it for themselves in the least productive way available. I set out the sequence for handling this transition in the AI change management framework.
Your 30, 60, 90 day roadmap
Days 1 to 30: find the truth
Map the top ten recurring processes by volume. Not the ones people complain about, the ones that run most often. Sit with the people who execute them and watch, do not interview.
Score every candidate on the six dimension framework above. Publish the scores internally. The conversation the scores generate is worth more than the scores themselves.
Pull the baseline data for the top three candidates. Volume, cycle time, error rate, cost of rework. If the data does not exist, that fact is your first finding.
Name an owner for the pilot with real decision authority and at least one day per week of protected time.
Days 31 to 60: build narrow
Pick one process, the highest scoring one, and automate it end to end rather than automating three processes halfway. Partial automation across many processes creates handoffs that are worse than the manual version.
Design the exception path before the happy path. What happens when the input is malformed, the system is down, or the case does not match any rule? Teams that design this last ship systems that fail loudly in production.
Run in parallel with the manual process for two to three weeks. This costs a little and prevents the category of failure that damages internal credibility permanently.
Document as you build. Configuration, decision logic, owner, escalation path. If this exists only in the implementer's head, you have created a dependency, not an asset.
Days 61 to 90: prove and extend
Measure against the baseline on your two chosen metrics. Report the result honestly, including what did not move.
Transfer operational ownership to the internal team while the implementation partner is still available to correct problems.
Decide the next two processes based on what you learned, not on the original plan. The first project always teaches you something that changes the ranking.
Set the maintenance cadence and put it in someone's calendar. Without this step, the value you just created starts eroding in month four.
Self assessment: is your company ready?
Answer yes or no. Each yes is one point.
- I can name the three highest volume recurring processes in the company.
- I know the annual cost of running at least one of them, from data rather than from memory.
- Those processes are documented somewhere other than in an individual's head.
- The input data for those processes is digital and accessible.
- I have a named owner who can dedicate at least one day per week to a pilot.
- That owner can make decisions within a defined budget without escalating.
- I have a baseline measurement from the last twelve months.
- I have chosen two metrics and know which system reports them.
- I have decided which processes are commodity and which are competitive differentiation.
- I have a plan for what the affected team does after the change.
- I have budgeted for ongoing maintenance, not only for implementation.
- I have defined what the system is allowed to do without human approval.
10 to 12 points. Start. Your probability of a measurable result is high.
6 to 9 points. You have two to four weeks of preparatory work. Doing it now is worth more than any discount a vendor will offer you.
Below 6 points. Automating now would produce a system built on assumptions nobody has tested. The highest return activity available to you is process discovery, and it costs a fraction of an implementation.
If the weakest area is point two, that you cannot state the annual cost of the process, that is the single most common gap and the one that makes every subsequent number a guess. Fixing it is a short, contained piece of work, and it is the conversation worth having before any platform is selected.
What changes over the next twenty four months
Three shifts are already visible and worth planning against.
The cost of the analysis layer is collapsing. Extracting, classifying and summarizing information used to be the expensive part of a process. It is becoming close to free. This moves the scarcity from information handling to judgment about what to do with it, and it changes which processes are worth automating: activities that were uneconomic to automate two years ago now clear the bar.
Integration is becoming the moat. As capability commoditizes, the differentiator is how cleanly your systems talk to each other. Companies with clean, accessible data will deploy in weeks what companies with fragmented systems deploy in quarters, using identical technology.
Governance moves from optional to structural. As systems begin to act rather than only recommend, the question of what they are permitted to do stops being a technical detail and becomes a board level matter, particularly in regulated sectors and in the European regulatory environment. The organizations building that discipline now will not have to retrofit it under pressure.
For companies further along the curve, the constraint stops being individual workflows and becomes coordination across them, a shift I addressed in the enterprise AI adoption framework.
The comparison that explains the adoption gap
I work across the United States and Italy, and the difference in how automation gets bought is instructive.
American mid market companies typically buy on expected value: what will this produce, over what period, against what alternative use of the money. The conversation starts from outcome and works backward to price. European companies more often buy on cost: what does the licence cost, how many days of implementation, what is the discount. The conversation starts from input and rarely reaches outcome.
This is not a competence difference, it is a framing difference, and it has one measurable consequence. Buying on cost systematically favors the cheapest tool for the narrowest problem, which is how companies accumulate eleven disconnected point solutions and no coherent process. Buying on expected value tolerates a higher price for a solution that covers the process end to end, which is usually cheaper in total.
The practical takeaway is simple. Before comparing vendors, write down what the process is worth per year. Every subsequent decision, including how much to pay and whether to build, becomes straightforward once that number exists, and impossible to make well without it. The broader version of that argument, applied to smaller companies with limited budgets, is in the guide to AI for small business.
The questions to ask yourself, not the vendor
Three questions no supplier will raise with you.
Am I automating this because it is valuable, or because it is visible? The most annoying process is rarely the most expensive one. Annoyance and cost correlate weakly.
Would this process survive if I eliminated it instead? A surprising number of recurring activities exist because of a system limitation that no longer applies, or a request from someone who left. Elimination beats automation on every financial measure.
Who owns this in eighteen months? Not who signs the contract, who maintains the workflow when the vendor's implementation team has moved on and the internal sponsor has been promoted. If the answer is nobody, you are buying a liability with a productivity label on it.
FAQ
What is business process automation and how is it different from AI?
Business process automation is the use of technology to execute a recurring sequence of business activities with minimal human intervention. It predates modern AI by decades and much of the value still comes from deterministic, rules based workflows: approval routing, data transfer between systems, document generation. AI is one of the capability layers inside a modern automation stack, specifically the layer that handles unstructured inputs and non deterministic decisions such as classifying an email, extracting fields from a non standard invoice, or planning a multi step task. Treating them as synonyms leads companies to buy AI for problems that a simple rules engine would have solved more cheaply and more reliably.
Which processes should a company automate first?
Score candidates on six dimensions: monthly volume, standardization, rule clarity, data availability, error cost and annual value at stake. The processes that consistently score highest sit in order to cash, procure to pay, customer service triage and reporting or reconciliation, because they combine high repetition with clear rules and digital inputs. Avoid starting with the process people complain about most, since irritation and financial value correlate weakly. Also avoid starting with anything that requires human judgment on the majority of instances, since that is a candidate for augmentation rather than automation and has a completely different cost profile.
How much does business process automation cost?
Software licences typically represent only 15 to 30 per cent of first year cost. Process discovery and design takes another 10 to 20 per cent, integration and data work 25 to 40 per cent depending on how old your systems are, and change management 10 to 20 per cent. Ongoing maintenance then runs at roughly 15 to 25 per cent of the initial cost every year, which is the line most budgets omit entirely. The useful control is proportional rather than absolute: total project cost should sit somewhere between 3 and 10 per cent of the annual cost of running the process being automated. Above 15 per cent the arithmetic rarely works.
Why do so many business process automation projects fail?
The dominant cause is process selection rather than technology. Gartner attributes the projected cancellation of more than 40 per cent of agentic AI projects by 2027 to escalating costs, unclear business value and inadequate risk controls, and MIT research on enterprise deployments found that organizations capturing value measured workflow change while the rest measured tool adoption. In practice the recurring failures are automating an undocumented process, designing for rare exceptions instead of common cases, selecting a platform before understanding the process, and running a project without an owner who holds both budget authority and operational credibility.
How long does it take to see results from automation?
For a narrow, well selected back office process with clean digital inputs, ninety days from start to measurable result is realistic: roughly thirty days of discovery and baselining, thirty days of build, and thirty days of parallel running and measurement. Processes tied to longer commercial cycles take proportionally longer to evaluate, and a business to business sales workflow with six month deal cycles cannot honestly be assessed in a quarter. The critical discipline is establishing the baseline before starting, because a company that has not measured the process beforehand will never be able to prove what the automation changed.
Should we build our own automation or buy a platform?
Buy when the process is standard across your industry, because a specialist vendor has already handled edge cases you have not encountered yet. Build when the process is the thing you compete on, since embedding proprietary logic in a generic platform both gives away the advantage and constrains it to the platform's assumptions. For everything in between, which is most processes, configure a low code platform and make sure someone owns and documents the configuration. Undocumented low code builds become the next generation of legacy systems within about three years and are harder to unwind than the code they replaced.
Does business process automation always reduce headcount?
Not usually, and framing it that way tends to make the project fail. In most implementations the effect is a shift in what roles do: less data movement and manual checking, more exception handling, customer contact and analysis. The teams that see the largest benefit are usually those under capacity pressure, where automation absorbs volume growth without proportional hiring rather than eliminating existing positions. Companies that announce automation as a cost cutting program face resistance from exactly the people whose process knowledge is needed to configure the system correctly, which is why those programs frequently produce the least accurate automations.