Robotic Process Automation (RPA) - Simply Explained

0:00 Welcome to the M365 FM podcast, where we explore the people, ideas and technologies shaping the future of work. What robotic process automation actually does. Every Monday, someone in finance retypes the same numbers into a fifth screen and nobody checks the result. Software can do that job now one click at a time, and it doesn't need a developer to set it up. Analysts who track this say most automation programs stall before their tenth robot, and the software is rarely the reason. Welcome to the M365 FM podcast, where we explore the people, ideas and technologies shaping the future of work. By the end, you'll know which of your weekly tasks a robot can take and which ones it will make worse. The job itself is smaller than the name suggests, so let's start there.

0:40 Robotic process automation is software that does the copying a person would otherwise do, driving the same screens and the same keystrokes in the same order. Every time your colleague opens an email, reads a number, types it into a spreadsheet, and then types it again into an accounting system. A bot does exactly that all day long without ever getting bored. Nothing underneath those systems had to change for this to work, and that detail is the single most important thing to understand about the whole topic. The bot walks in through the front door instead of rewiring the building. You might think a bot means a machine on a factory floor or a chat window that answers customer questions on a website. In this world, a bot is nothing more than a script that opens windows, clicks, buttons, types, text, and reads back whatever appears on the screen. It has no body, no personality, and no opinions about your business.

1:22 The word robotic is doing a lot of misleading work in that name. It was never about hardware. It described software that copies a human routine so faithfully that the routine survives the handover. The name stuck, even though the thing it describes sits much closer to a very obedient macro than to anything you would find on a production line. Robotic process automation isn't artificial intelligence, and that gap matters more than the shared word robot suggests. A bot follows the steps a person wrote down for it, and it repeats those steps the same way every single time. Even when the situation around it has clearly changed, it cannot recognize a pattern. Nobody taught it. It cannot make a judgment call either, and it cannot learn from its own mistakes. Artificial intelligence works the other way around because it studies a pile of examples, finds the patterns inside them, and improves as it sees more of them.

2:07 That's why AI handles the mess and the variation. A bot cannot touch. So a bot is small, literal, and cheap to point at a screen. That raises an obvious question about why so many companies started buying this kind of software at the same moment, and it's worth answering before we go further. Why this suddenly matters right now. Robotic process automation used to live quietly in the back office on a few laptops in finance. Now it shows up in budget conversations, and the researchers who track spending on this kind of software expect the market to keep growing for the rest of the decade. Treat any single figure with suspicion, because the firms that publish those numbers count things differently, and the numbers disagree with each other more than you would like. The direction is the useful part. The reason companies keep buying has very little to do with the technology being exciting.

2:49 Most large organizations run on a stack of systems that were never designed to talk to each other, and a human being ends up as the wire between them. Somebody opens one screen, reads a value, and types it into another. Multiply that across a few hundred people and a few thousand repetitions every month, and you end up with a number that a finance director notices. The work being automated is boring work, and that's exactly the point. That work is frequent, predictable, and easy to measure. So the payoff shows up on a spreadsheet instead of in a press release. There's a second reason this arrived when it did, and it has to do with who was allowed to build the thing. The tool stopped requiring a programmer. The builder became a drag and drop canvas that anyone could learn in an afternoon. That meant the people closest to the work could automate it themselves without filing a ticket and waiting a full quarter for someone else to help out.

3:31 Before we get to where this money actually goes wrong, it's worth watching a bot do its job one step at a time on a real screen. Once you see the mechanics, one limit becomes obvious. That limit explains why most automation programs never grow past a handful of bots. How a bot actually does the work. Building a bot starts with teaching it a sequence. Most tools give you two ways to do that, and the choice matters more than it looks. You can record yourself performing the task once, or you can drag and drop each action into a list by hand. Recording is faster to start and messier to maintain because the recorder captures everything you did, including the mis clicks and the detours you made by accident. Then the bot has to find things on the screen. It does that in one of three ways, and the three are not equally sturdy. It can search for a named interface element, or a picture of a button or a fixed spot on the screen.

4:15 Those three options get less reliable in that order, since a named element survives a full redesign. While a fixed pixel position does not survive much of anything, the range of software a bot can drive is wider than you might expect. A modern web app is easy, and so is a desktop application, an Excel file, a shared folder, and even a green screen terminal that predates the web. If a person can drive it with a keyboard and a mouse, a bot can usually learn to drive it, too. Once the bot has the data, it puts that data somewhere. It types into another application, writes a row into a spreadsheet, drops a file into a folder, or sends a message to whoever is waiting. The visible work is the clicking, and the actual output is a record that moved from one system to another without a person in the middle. There are two ways to let a bot run.

4:57 An attended bot sits next to a person and fires when they ask for it, so a support agent clicks one button and watches the details come back. An unattended bot runs on its own, on a schedule or on a trigger, with nobody in the room at all. The monthly report that used to eat someone's Tuesday morning can now run at two in the morning while everyone sleeps. Most bots in the world are the unattended kind. An analyst at four fifty one research told TechTarget that the vast majority of bots built today are designed to run unattended because the goal is to take the person out of the loop entirely. So the mechanics are simple. The two operating modes are easy to tell apart as well, which leaves the question that decides whether any of this works. And that question is which work deserves a bot? The jobs bots are genuinely good at.

5:37 Good automation. Work has a recognizable shape. It happens often. It follows the same rules every time. It deals with clean, structured data, and it needs no judgment at all. If a task changes shape depending on the customer or the wording of an email, a bot is the wrong tool and you will find out the hard way. Invoices are the obvious example. A supplier emails a document. Someone opens, it reads the amount and the reference number and types both into a finance system, one field after another. That's a perfect candidate. And it happens thousands of times a month in a mid-sized company. Onboarding and off boarding follow the same pattern. When someone joins a person, creates their account, adds them to the right groups, orders a laptop, and sends out a welcome note to the whole team. The sequence barely changes from one hire to the next. Offboarding is that job in reverse, and it's often the one that finally gets funded.

6:20 Reporting is the other big one. A weekly report that pulls numbers out of four different places into one slide is the kind of task that eats an afternoon and produces nothing anyone enjoys making. Hand the collection to a bot, and the human keeps the part that needs a brain, which is deciding what the numbers mean. Banking and finance lead the field by a wide margin. Analysts who study this put more than a third of all automation use cases in finance and accounting, followed by insurance, retail and healthcare. The patent isn't mysterious because finance work was already rule based and documented long before anyone called it automation, which made it unusually ready to hand over everything up to this point is the good news. The good news has a hard edge, because the qualities that make a task perfect for a bot are the same qualities that make it fragile in ways nobody plans for.

7:04 Where RPA breaks. The limit I mentioned earlier is worth naming now, and it isn't really about the software being badly written, because every bot assumes the work always looks the same. Real work almost never does. Start with the data a bot reads a field, a cell, or a labeled box on a screen, and it needs that structure to actually exist. Hand it a scanned invoice, a PDF with the total in a slightly different place, or an email where someone buried the amount inside a paragraph and it has nothing to grab anything arriving as free text, an image or handwriting tends to stop a bot dead. Then there are the exceptions. Every real process has edge cases, and a bot handles the standard path and only the standard path. No matter how many exceptions, show up every week when an order doesn't match the usual pattern.

7:45 The work doesn't slow down, it just stops and it usually stops silently. Brittleness is the third problem, and this one catches people off guard because a bot drives the surface of an application. A small change to that surface can break it. A button moves a field, gets renamed, a login screen adds a step, and the bot that ran perfectly for six months fails on a Monday morning. Scale is the fourth problem, and it's what ends most programs. The research on this is blunt and more than half of the customers surveyed say they struggle to grow their automation beyond the first few processes. Their yardstick for an advanced program is one hundred live bots, and most companies never get past ten. This is also where the confusion with AI agents creeps in. When a bot hits something it wasn't taught. Someone has to decide what happens next, and that decision is the part people keep hoping a smarter model will handle.

8:29 Sometimes a model really can. Often the honest answer is that the process itself was never defined well enough for any tool to follow it. Put those four limits together and. The conclusion is uncomfortable, but useful for anyone planning this work. This is not a way to fix a messy process. It's a way to copy a tidy one, and it stays reliable only for as long as the tidy version of that process holds up in practice. If the limits are this well documented, you would expect companies to steer around them. And yet plenty of companies walk straight into all four of them anyway. The reasons have almost nothing to do with technology the mistakes that sink automation projects. The first mistake is automating something that should have been deleted. A bad process that runs by hand is annoying and visible, while the same process behind a bot runs faster, fails more quietly, and becomes much harder to argue with.

9:15 Now it looks like a system instead of a bad habit. The second mistake is launching a bot and walking away. Someone has to own it because when a screen changes or the volume doubles, a person needs to notice and fix it. Programs that skip this step find out their bots are broken at month end, when the numbers no longer add up and nobody can explain the gap. The third mistake is leaving no path for the cases a bot can't handle. If the only options are a perfect run or a silent stop, then every unusual document becomes a lost invoice and the humans around the bot start working around it instead of with it. A five minute conversation about who handles the weird cases would have prevented the whole mess. The fourth mistake is measuring the wrong thing. Hours saved is a lovely number for a slide, and it says nothing about whether the work actually left somebody's desk at the end of the week.

9:57 If the same person still spends Friday afternoon checking the bots output, then no time was saved. the time just moved somewhere else. The fifth mistake is treating access as an afterthought. A bot usually logs in as a real person or a shared account, so it inherits everything that account can see and do. When nobody tracks which bot holds which access, you end up with automation that reaches further than anyone intended and no clean way to explain who approved it. Notice what's missing from that list? Not one of those failures comes from a badly built bot. They are process failures. Ownership failures and measurement failures. Wearing a technology costume. And that is why buying newer software almost never fixes any of them. All of this matters more once you realize something simple. The tool is probably already sitting inside your Microsoft license, and it is waiting for someone in your team to point it at a task that deserves the effort.

10:44 Where RPA fits in Microsoft three hundred sixty five and Azure. If your company runs on Microsoft three hundred sixty five, the automation tool is already in the building, and it's called Power Automate. The RPA part has its own name, which is desktop flows. You build them by dragging actions into a sequence or by recording yourself doing the task once, which is the same approach every other RPA product takes power. Automate holds two kinds of flow, and the difference matters. Cloud flows run in Microsoft's cloud and connect services to each other, so a new form response can create a record, send a message, and update a list on its own desktop flows, run on a machine and drive the screen, which is what lets them handle software with no modern connection at all. Real automation usually uses both with a cloud flow starting the work and a desktop flow finishing it on an older system.

11:26 Here's what that looks like end to end. Someone submits an expense form, a cloud flow catches the response, and it checks the amount against the policy. If the amount looks normal, the cloud flow hands the record to a desktop flow, which logs into the finance system that has no modern connection and enters the claim. If anything looks off the flow, routes it to a person instead. Nobody watches the whole thing happen in real time, and the trail of what occurred stays in the run history. For anyone who wants to check under the hood, Power Automate is built on a service called Azure Logic Apps. The two look similar on the surface, and the difference is mostly about who they're for. Power automate is aimed at makers and everyday users inside Microsoft three hundred sixty five with per user licensing.

12:06 While Logic Apps is aimed at developers and IT teams working in Azure. If you're a beginner, you'll live in Power Automate and you can grow into logic apps later without starting over. The part everyone asks about is what it costs. Many Microsoft three hundred sixty five plans already include standard connectors, so basic cloud flows are often covered. Attended desktop flows sit in the premium plan, which lists at fifteen dollars per user per month when you pay yearly. Unattended bots are licensed per bot instead of per person, at one hundred and fifty dollars a month, and that price rises to two hundred and fifteen dollars if Microsoft hosts the machine for you on Azure. That per bot licensing is worth sitting with for a moment because it explains a decision you will see inside real companies. One bot can run one unattended task at a time, which means running five things at the same time turns into an invoice for five separate bots.

12:50 Starting is cheap, and scaling is where the invoice grows. Around all of that sits the wider story Microsoft keeps telling. Process mining finds the work worth automating by reading the trails your systems already leave behind, and copilot and agents add judgment where the rules run out. That's the direction of travel, and it deserves its own episode. Knowing the tool exists is easy. Knowing what to do with it on a Monday morning when nobody has told you which tasks are worth automating, is where most beginners stall out and stop. What this means for your career. The skill worth building here has nothing to do with building bots. It's the ability to spot bot shaped work and describe it clearly enough that someone else can take it and act on it without asking you a dozen questions. Here's a simple exercise you can run this week.

13:30 Pick one task you do every week that runs through the same steps in the same order, and write those steps down as if you were explaining them to a new colleague. If the list comes out clean, that task is a real candidate for a bot. If you keep stopping to write that, it depends. You found the part that would break it, and that's useful information to that. Exercise is also why this skill travels. The people who get real value from automation are the ones who can explain a process clearly enough that a machine and a colleague both follow it. That ability comes up in job interviews far more often than any specific certification. One honest note before you automate everything in sight, this is a useful edge and not a guaranteed promotion, and it doesn't replace knowing the business. A bot that saves four hours a week on a process nobody needed is still a wasted project, and the person who understands the business usually catches that first.

14:15 The short version and one question for you. The short version is simple. The software clicks and types the way a person does on the same screens with no AI involved. It's genuinely good at high volume, rule based work with tidy data, and it breaks the moment the work stops looking the same way twice. Getting started is cheap. The bot licensing only kicks in once you go unattended and the whole thing lives inside. Power Automate If your company already runs on Microsoft three hundred sixty five. Most programs stall for reasons that sit outside the bots entirely. Nobody owned the process around them, so nothing got fixed when the work changed and the bots took the blame for a problem they never caused. So here is the question I'll leave you with. Which single task in your own week would you hand to a bot tomorrow? And which part of it would you still want a human to check if this made the topic feel less intimidating?

14:59 Subscribe to M365 FM. To master the tools and the mindset shaping the future of work.