Intelligent Automation Readiness: What Operations Leaders Need Before the First Bot

Published · Wendy Kinney

Intelligent Automation Readiness: What Operations Leaders Need Before the First Bot, Summit Trails

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.

What Is Intelligent 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.

Why the “Intelligent” Part Changes the Readiness Question

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 Platforms Agree That Discovery Comes First

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.

What Intelligent Automation Readiness Takes in Operations

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.

1. You can say where the hours go, by activity

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.

2. You know how much of the work is reading and deciding

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.”

3. You can see the handoffs, not only the tasks

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.

4. You know who is affected, and by how much

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.

Picking Targets Off an Org Chart, and the Order That Works

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:

  1. Measure the work in the teams in scope, at the activity level, long enough to see a normal cycle rather than one unusual week.
  2. Map the measured hours to the layers in the table above, so rekeying, reading, waiting, and genuine human work are separated.
  3. Size the effect on people by role, before anyone writes a business case.
  4. Choose the targets, applying the criteria for deciding what to automate. Our guide on how to know what to automate in operations sets those out. If you need to rank several candidate processes against each other, a workforce automation analysis turns that into a score.
  5. Choose the platform, using the measured baseline as the yardstick for its business case and, later, for what it actually delivered.

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.

What Summit Trails Does Here, and What It Leaves to Others

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.

Frequently Asked Questions

What is intelligent automation?

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.

Is intelligent automation the same as AI?

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.

What is the difference between intelligent automation and RPA?

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.

What is an example of intelligent automation in operations?

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.

What does intelligent automation readiness mean for an operations team?

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.

Should we choose an intelligent automation platform before measuring the 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.

Before the Platform Shortlist

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.

Mail Signup Section

Ready to Help Your Team Reach the Peak? See us in Action.