Most writing about RPA is about where it fits.<\/p>\n
Knowing where it does not is more useful<\/strong>, because that is where the money gets wasted \u2014 on projects that work in a demonstration and become a burden in production.<\/p>\n Here are the cases, with what to do instead.<\/p>\n The most common and most expensive mistake.<\/strong><\/p>\n Why it happens:<\/strong> RPA needs nobody’s permission. You can build it without asking the other system’s owner, without a project, without a conversation.<\/p>\n Why it costs:<\/strong> every vendor update risks breaking it, and you have signed up for maintenance you did not need.<\/p>\n What to do instead:<\/strong> check properly. Ask the vendor. Read the documentation. Look for an export function. Check whether the file has a direct URL<\/strong> \u2014 that alone removes most of the fragility from data-retrieval automations.<\/p>\n Ask this question first, every time.<\/strong> It saves more than anything else in this article.<\/p>\n RPA follows rules. It does not decide.<\/strong><\/p>\n Where people get caught:<\/strong> the task looks rule-based until you look closely. “Approve if the amount is under the limit” is a rule. “Approve if it seems reasonable” is not, and it is what people actually do.<\/p>\n Encoding judgement as rules works until reality produces a case the rules do not cover<\/strong> \u2014 and it will.<\/p>\n What to do instead:<\/strong> automate the gathering, leave the deciding. The robot prepares, a person decides.<\/strong> That captures most of the time saving with none of the risk.<\/p>\n FIGURE 1: WHERE IT LOOKS RIGHT AND IS NOT<\/p>\n Looks suitable<\/p>\n Actually suitable<\/p>\n Building and maintaining an automation has a fixed cost.<\/strong><\/p>\n Twice a month does not clear it.<\/strong> By the time you have documented the process, built it, tested it, and maintained it for a year, a person doing it by hand would have cost less.<\/p>\n A rough test:<\/strong> if the annual saving is not several times the annual cost, it is marginal. Marginal automations get abandoned<\/strong> when their author leaves.<\/p>\n What to do instead:<\/strong> leave it manual, or find the higher-volume task nearby.<\/p>\n Screen automation depends on screens staying the same.<\/strong><\/p>\n Some applications update frequently<\/strong>, particularly cloud ones where the vendor ships changes without asking.<\/p>\n You will spend more time repairing than the automation saves.<\/strong><\/p>\n What to do instead:<\/strong> check whether an API exists, or accept that this task stays manual.<\/p>\n A common misunderstanding.<\/strong><\/p>\n Invoices, receipts and forms arrive in thousands of layouts. RPA cannot read them<\/strong> \u2014 it can find an element on a screen, not extract meaning from a document it has not seen before.<\/p>\n What to do instead:<\/strong> that is a document AI problem. Different technology, and it works well.<\/p>\n Automating an undocumented process means automating your assumptions about it.<\/strong><\/p>\n What happens:<\/strong> halfway through the build, you discover the process is not what anyone described. Two people do it differently. There is an exception nobody mentioned.<\/p>\n What to do instead:<\/strong> document it first. Watch it being done, several times, by more than one person. That document is worth more than the automation.<\/strong><\/p>\n The one that catches everyone.<\/strong><\/p>\n If the process has unnecessary steps, duplicated work, or produces a report nobody reads, automating it means doing the wrong thing faster and cheaper.<\/strong><\/p>\n Ask before building: should this task exist at all?<\/strong><\/p>\n Sometimes three of the eight steps are pointless. Removing them saves more than automating all eight would have \u2014 and costs nothing to maintain.<\/p>\n FIGURE 2: SEVEN REASONS NOT TO<\/p>\n An API exists<\/p>\n It needs judgement<\/p>\n Low volume<\/p>\n The process is wrong<\/p>\n Every automation needs an owner<\/strong> who receives the alerts and fixes it when something changes.<\/p>\n If the honest answer is that nobody will do this, do not start.<\/strong><\/p>\n An unmaintained automation does not simply stop being useful. It fails silently while everyone assumes it is working<\/strong>, which is worse than never having had it.<\/p>\n Related, and worth stating separately.<\/p>\n If you cannot arrange for failures to reach a person<\/strong>, do not automate anything that matters.<\/p>\n A silent gap in your data is more expensive than the manual work you avoided.<\/strong><\/p>\n Read back through and something is consistent.<\/p>\n RPA is wrong when a better tool exists, when the task is not really mechanical, or when nobody will look after it.<\/strong><\/p>\n None of those are technology problems.<\/strong> They are questions you can answer before spending anything.<\/p>\n Six questions. A “no” on any of the first four is usually a stop.<\/strong><\/p>\n Does an API, an export or a direct URL exist?<\/strong> If yes \u2014 use that.<\/p>\n Is this genuinely rule-based?<\/strong> If it needs judgement, automate part of it.<\/p>\n Is the volume high enough?<\/strong> Weekly at minimum, ideally daily.<\/p>\n Is the interface stable?<\/strong> Frequently changing systems are not worth it.<\/p>\n Who will own it?<\/strong> Name the person.<\/p>\n How will we know if it fails?<\/strong> If you cannot answer, fix that first.<\/p>\n FIGURE 3: THE DECISION<\/p>\n API or direct URL?<\/p>\n Genuinely rule-based?<\/p>\n High enough volume?<\/p>\n An owner and alerting?<\/p>\n A setting in your existing system.<\/strong> Most business systems do more than people realise. Check first.<\/p>\n An API integration.<\/strong> More reliable, cheaper to maintain.<\/p>\n A workflow tool.<\/strong> Faster to build than code, readable by a colleague.<\/p>\n Document AI.<\/strong> For varying documents.<\/p>\n Fixing the process.<\/strong> Sometimes the answer is fewer steps rather than faster ones.<\/p>\n Leaving it manual.<\/strong> A legitimate outcome for low-volume work.<\/p>\n Do not use RPA when an API exists<\/strong>, when the task needs judgement, when the volume is low, when the interface changes constantly, when the documents vary, when the process is undocumented, or when nobody will maintain it.<\/p>\n And do not automate a process nobody has questioned.<\/strong> Making the wrong thing faster is not an improvement.<\/p>\n The best automation decisions include the ones not to build.<\/p>\n Not sure whether a task is worth automating?<\/p>\n Get in touch. We will tell you honestly when the answer is no \u2014 and quite often it is a setting or a process change instead.<\/p>\n<\/div>","protected":false},"excerpt":{"rendered":" Why this article exists Most writing about RPA is about where it fits. Knowing where it does not is more useful, because that is where the money gets wasted \u2014 on projects that work in a demonstration and become a burden in production. Here are the cases, with what to do instead. 1. When an […]<\/p>\n","protected":false},"author":3,"featured_media":9383,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[23],"tags":[],"class_list":["post-9382","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-robotic-process-automation"],"yoast_head":"\n1. When an API exists<\/h2>\n
2. When the task needs judgement<\/h2>\n
\n
\n
3. When the volume is low<\/h2>\n
4. When the interface changes constantly<\/h2>\n
5. When the documents vary<\/h2>\n
6. When the process is not documented<\/h2>\n
7. When the process is wrong<\/h2>\n
\n
\n
\n
\n
8. When nobody will maintain it<\/h2>\n
9. When you cannot see failures<\/h2>\n
The pattern<\/h2>\n
What to ask before starting<\/h2>\n
\n
\n
\n
\n
The alternatives, briefly<\/h2>\n
The short version<\/h2>\n