Intelligent Automation Readiness: What Operations Leaders Need Before the First Bot
Published · Wendy Kinney
Published · Wendy Kinney
Intelligent automation is the combination of robotic process automation (RPA), artificial intelligence (AI), and workflow orchestration, used to automate work that rule-following bots could never reach on their own: reading documents, sorting cases, and making bounded decisions. Getting an operation ready for it often takes less software than programs assume and more evidence. Specifically, it takes a measured account of what your teams spend their hours on, before anyone picks a target.
That last part is the step programs most easily skip. The platform gets chosen, a center of excellence gets staffed, and the first targets come from whichever processes have a name, a queue, and a large headcount line. That is picking targets off an org chart.
Key Takeaways
- Intelligent automation combines RPA, AI, and workflow orchestration. IBM and AWS both define it as automation technologies working together, with AI handling unstructured inputs and decisions that plain bots cannot.
- Adding AI moves automation into reading and deciding, the work least visible on a process map or an org chart. In a 2022 Deloitte survey, 54% of organizations already implementing or scaling intelligent automation had not calculated what share of their workforce it affects.
- Measure the work, map it to the automation layers, and size the effect on people before choosing targets or a platform. UiPath and Automation Anywhere both put discovery first, and both describe it as the opening stage of building automation.
AWS defines intelligent automation as “the process of using artificial intelligence (AI) and robotic process automation (RPA) to create complex software automation.” IBM adds business process management (BPM) as a third component and says the three are used together “to streamline and scale decision-making across organizations.” IBM also notes the term is sometimes called cognitive automation.
In operations terms, it helps to think in layers rather than products.
| Layer | What it does | What it looks like in a back office |
|---|---|---|
| RPA | Software robots repeat fixed steps across screens and systems | Copying a customer’s change of address from a web portal into the policy administration system |
| AI (machine learning, language models, optical character recognition) | Reads unstructured inputs and makes bounded calls | Reading a scanned lien release and deciding which loan record it belongs to |
| Orchestration (BPM) | Moves each case between bots, systems, and people | Sending a work order that failed validation to the right planner with the document attached |
RPA on its own was always limited to the first row. AWS describes RPA as automating “repetitive, rule-based, and labor-intensive back-office workflows such as filling in forms, searching for information, or sorting invoices.” UiPath calls intelligent automation “an extension of the traditional RPA.” The extension is the second row, and it is the reason the term exists.
Where does AI end and the automation begin? AI is one component. A language model that summarizes a document is AI. A system that reads the document, updates three applications, and routes the exception to a person is intelligent automation.
When automation meant RPA, readiness was mostly a stability question. Are the steps fixed, and is the input structured the same way every time?
The candidates were easy to find because they already had names and written procedures.
The AI layer changes where automation can reach. It goes after the reading and sorting that sits between the named steps, and that work rarely has a name. It happens in fragments across many roles: a few minutes deciding what a document is, a few more checking it against a spreadsheet, another few drafting a reply. No procedure describes it, and the system of record usually logs only the result.
So the readiness question shifts. It is no longer only “is this process stable enough for a bot?” It becomes “do we know where the reading and deciding actually happens, and how much of it there is?” Many operations cannot answer that from the systems they already own.
Picture a regional utility (an illustrative composite, not a client result) starting an intelligent automation program. The steering group shortlists new service connection requests because the process has a documented procedure and a clear owner. Measured at the desk, the service coordinators spend much of their week on something nobody listed: chasing missing permit documents by email and reconciling each job against a contractor spreadsheet. The bot built for the named process works as designed, and the hours stay where they were.
The automation vendors themselves are candid about sequence. UiPath’s explainer puts it plainly: “Before automations are created or employed, you first need to figure out which processes can and should be automated.” Automation Anywhere is shorter: “You can’t automate what you don’t understand.”
Both are right. The question worth asking is what their discovery is built to find.
UiPath points to process mining and task mining to “discover the highest ROI opportunities,” as the first stage before automations are created, tested, and implemented. Automation Anywhere calls process discovery “a cornerstone of Intelligent Automation solutions” and says that, fully integrated, it feeds “directly into autopilot-led automation creation.” In both explainers, discovery is the opening stage of building automation: it looks for steps a bot can take and leads straight into building one. That is a sensible design for an automation vendor, and a narrower job than the one an operations leader has.
Your question is wider, and it comes earlier. What does the work across these teams actually consist of? Which share of it could any automation layer touch? What happens to the people who do it, and to the service levels they hold, if it goes?
Those answers should exist before a platform is chosen, and they should come from a measurement that does not depend on which platform wins.
Survey data suggests the people side of that question often goes unanswered. Deloitte’s 2022 Global Intelligent Automation survey of 479 executives across 35 countries found the top barriers were process fragmentation, lack of a clear vision, lack of IT readiness, and resistance to change, with fragmentation at the top of the list in each of Deloitte’s past four surveys. And among organizations already implementing or scaling intelligent automation, 54% had not calculated the proportion of their workforce it affects. Those organizations were past the pilot stage, and more than half had not yet put a number on whose work was changing.
Readiness is easier to judge one layer at a time. Each layer needs a different kind of evidence, and in each case teams tend to reach for a document that describes the work instead of a measurement of it.
| Layer | Evidence you need first | Where teams usually look instead |
|---|---|---|
| RPA | Where copying, rekeying, and lookups actually happen, across every application people use | The written procedure for the named process |
| AI | How much time goes into reading and interpreting inputs, and how often the resulting call is a repeat | Job titles and role descriptions |
| Orchestration | Where cases wait, and how often they come back to someone who already touched them | Reporting lines on the org chart |
| People | Who does the affected work, and what share of each person’s day it fills | Headcount by department |
Behind that table are four conditions.
Not by application. “Six hours in the core system” says nothing about whether those hours are data entry, research, or waiting on a screen. Rekeying work tends to live between systems, in email, spreadsheets, and portals, which is why a view of one system’s logs undercounts it. The RPA layer needs activity-level evidence, the kind described in our explainer on ground truth workforce data.
This is the AI layer’s territory. Almost every back-office role involves some judgment, so asking whether a role does tells you little. The more useful measure is how much time goes to interpreting inputs that vary in format but lead to the same few outcomes. A team that spends its mornings deciding which of four queues a document belongs to is doing work the AI layer is designed for, even if the job description says “specialist.”
Orchestration earns its value in the gaps. If a case passes through five people and waits two days between the second and third, automating any single task barely moves the cycle time. Readiness here means knowing where work queues up, where it bounces back, and which handoffs exist only because two systems do not talk to each other.
The Deloitte figure above measures a rougher version of this condition, and more than half of the organizations already implementing or scaling had not met even that. Before a business case is written, you should be able to name the roles whose day changes and roughly what share of each day that is. If a headcount mandate is attached to the program, this is the number the board will ask about, and it is much harder to reconstruct after the bots are live.
None of this replaces the technical side of readiness: data access, security review, IT capacity, and governance. That checklist is covered in our AI readiness assessment for operations. The four conditions above sit underneath it, because a well-governed program aimed at the wrong work still misses.
An org chart shows departments, reporting lines, and headcount. When a steering group builds an automation shortlist from it, the logic is usually reasonable on its face: go where the most people are, and start with whatever sounds most manual.
Picture a mid-size bank (again, an illustrative composite) handed a mandate to take cost out of operations. The steering group picks deposit operations because it is the largest team, and scopes the first build around account maintenance requests. Measured, a large block of that team’s week turns out to be researching exception items and answering branch emails, neither of which was in scope. Meanwhile the heaviest document-reading load sits in a six-person loan servicing intake team that never made the list, because on the chart it looked too small to matter.
Every decision in that program was defensible on the day it was made. What went wrong was the sequence, and a sequence that holds up looks like this:
Programs often start at step five. If a platform shortlist is already on your desk and nobody has done step one, that is worth half an hour. Book a 30-minute strategy call and we will look at what measuring first would change in your plan.
We do not sell intelligent automation, build bots, recommend an automation vendor, or run implementation and change management. A contact center is also better served by contact-center workforce management software. If you need a platform, the vendors above are the right conversation.
What we do is steps one to three, and we do them before the platform decision so the answer does not depend on which vendor wins.
The Ground Truth AI² Platform takes a small image of the screen region around each click, from 500 to 3,000 of them for every person in scope each day. Keystrokes and full screens are never recorded. Vision AI reads each capture and names the activity it shows, so the record says “matching a lien release to a loan record” rather than “in the servicing system,” and each activity carries an automation score. That is the capture, classify, and insight method, and it gives you, for everyone in scope, what an analyst would otherwise build by shadowing one desk at a time.
The engagement has a fixed scope of 90 days. An initial findings summary arrives around weeks three to four, and the Ground Truth AI² Report at the end carries the activity baseline, the AI replacement assessment, a prioritized deployment roadmap, and the staffing model analysis behind it. See what that output looks like.
Wendy Kinney leads the operational side. Her 20-plus years in workforce operations include engagements with AT&T, Boeing, AIG, Nationwide, Farmers, and the State of California. Measurements alone do not settle a mandate, so the findings are interpreted by someone who knows how operations actually run.
On data posture: the customer owns the data, it is encrypted with AES-256 at rest and TLS 1.3 in transit, and a self-hosted option is available. The platform page covers the privacy architecture.
You may not need us at all. If your program targets one well-understood process with stable volumes, and no workforce decision rides on the result, a platform’s own discovery tooling is likely enough. We are the right call when intelligent automation is tied to a headcount number, spans several teams, or has to be defended to a board.
Intelligent automation combines robotic process automation, artificial intelligence, and workflow orchestration so that software can handle work involving unstructured inputs and bounded decisions, not only fixed, rule-based steps. AWS describes it as using AI and RPA “to create complex software automation,” and IBM includes business process management as a third component.
No. AI is one part of it. AI on its own can read, classify, or predict. Intelligent automation connects that capability to bots and workflows, so the output of the AI step actually changes records, moves cases, and hands exceptions to people.
RPA repeats fixed steps across screens and needs structured, predictable inputs. Intelligent automation adds AI so the automation can handle documents, free text, and inputs that vary, and adds orchestration so work can pass between bots and people. UiPath describes intelligent automation as an extension of traditional RPA.
A loan servicing team receives scanned documents by email. An AI model reads each document and identifies its type and the loan it relates to. A bot updates the servicing system and the imaging archive, and anything the model is unsure about is routed to a person with the document attached. Each step alone is ordinary, but together they automate work that RPA could not.
It means having evidence about the work before automating it: where the hours go by activity, how much time is spent reading and deciding, where cases wait between people, and which roles would be affected and by how much. Technical readiness, such as data access and IT capacity, matters too, but it cannot tell you whether the program is aimed at the right work.
We would not. Vendor discovery is described as the first stage of building automation, so it is designed to find steps a bot can take, which is useful once targets are set. Measuring the work first, independently of any vendor, tells you where automation would matter and gives you a baseline to hold the chosen platform’s business case against.
The technology is a real step up from rule-following bots, and the vendors selling it are right that discovery comes first. What they cannot do is decide, on your behalf, which work in your operation deserves it and what that means for the people doing it.
That is a measurement you own. If an intelligent automation program or a headcount number is heading your way, book a strategy call. In 30 minutes we will look at the teams in scope and what you would need to know about their work before the first bot is built.
Ready to Help Your Team Reach the Peak? See us in Action.