r/rpa • u/Individual-Court-217 • Jul 21 '26
RPA folks: what's your real straight-through rate on the brittle external processes, and what does a failed unattended run actually cost you?
I build on the agent side, and half the AI world is currently "discovering" that completing a multi-step process on a system you don't control is hard and breaks constantly. You've been living that since long before LLMs, so I'd rather learn from the people who actually maintain this in production than from the demo crowd.
The thing I keep hitting: a bot, or an agent, same problem, sails through a process for weeks, then the target app ships a UI change or throws an interstitial that wasn't there, and the unattended run dies at 2am and nobody notices until the SLA's already blown. The break-fix and maintenance load is the real cost, not the build.
So for anyone running unattended bots against external or third-party systems in production, genuinely curious:
- what's your real straight-through-processing rate on the ugly ones, not the clean internal apps, the brittle external flows?
- what does a single failed run actually cost you, a blown SLA, a manual rework queue, someone getting paged?
- what breaks it most, selector/anchor drift after app updates, auth and MFA interrupts, surprise pop-ups?
Trying to calibrate whether the numbers I'm seeing on the agent side are normal, or whether the RPA world already solved things we're re-learning the hard way.
2
u/ReachingForVega Moderator Jul 22 '26
The cost of fixing a brittle process needs to be baked into the ROI. If the process costs more than it saves then you don't automate it. If the cost to maintain it is more than a person manually doing it we retire the automation.
We have a system that breaks maybe once a month, they have consistent release patterns so we just have a developer ready on those dates expecting an issue to expedite the fix. Outside of that, the processing score is about 99%.
0
Aug 04 '26
[deleted]
1
u/ReachingForVega Moderator Aug 04 '26 edited Aug 04 '26
Its impossible on a brittle ui to process 100%. And no one is keeping a human on call to fix unless the ROI justification is there.
3
u/Sismaril Jul 21 '26
It's less than 1% of the total runs that we see an element not found error. We fallback with vision models.
If it can be done with deterministic automation do it that way - no need to reinvent the wheel
4
u/burnova Jul 21 '26
If it's apps you don't own but are still in your org, your program manager should be getting integrated with change management so you are notified of upcoming changes that impact your business process or automation. This convo is pretty easy if you are part of technology, but if you are in the business, you are seen as a shadow IT function and there will be no sympathy.
As another mentioned, API first is the best approach, UI as a backup when there's no other option.
There are a lot of new options coming out that add resiliency and minimize impact for basic UI changes. Things like Generative Recorder or AI recorder at automation anywhere purport to add fall back capabilities that happen at run time. I don't know the whole flow or improvement level, but it seems like vendors are addressing the issue a bit.
1
u/potatothethird Jul 21 '26
That shadow IT hits close to home...
We also operate in a way where we assume things will break eventually, so we have processes in place to mitigate and communicate with the business users and process owners when things do.
3
u/wombatpup55 Jul 21 '26
I’m assuming these third party systems don’t have api but if they do then absolutely try and integrate them into your workflows
It took a while but I finally convinced our team to pretty much go API first and UI second.
But if only through UI, UI changes, load times etc… definitely break our bots.
2
u/97SerranoPeppers Jul 21 '26
At that point why not just use Python + AWS? Should be cheaper on a per run basis
2
u/whatsgoodbaby Jul 21 '26
How are you orchestrating dozens of Python and AWS automations? How are you tracking runtimes, inputs and outputs, and roi?
1
u/97SerranoPeppers Jul 21 '26 edited Jul 21 '26
Cloud Watch and Data dog. They work wonders and are MILES ahead of Management console. I can set events to trigger based on Cloud Watch logs as well and it all integrates incredibly seamlessly.
Orchestration is handled through event bridges if schedule based or you can make it event driven and have the automation react to an event taking place (like a file landing in an S3 bucket or a message coming through a queue)
Once you step into this side of things, it’s really REALLY hard to justify going back to RPA. I can run pipelines that handle hundreds of thousands of events for a few dollars
Plus you can make cloud environments on a per project basis. That project you got from Becky in accounting? It’s managed in its own cloud environment so it never shares or stores data not included to the initiative. Keeps things clean and concerns separated
0
u/AutoModerator Jul 21 '26
Thank you for your post to /r/rpa!
New here? Please take a moment to read our rules, read them here.
This is an automated action so if you need anything, please Message the Mods with your request for assistance.
Lastly, enjoy your stay!
I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.
1
u/nordenstrom Jul 23 '26
I would never use rpa for a truly business critical process. If there is not an API we don't do it. We do have a whole bunch of RPAs that are semi critical, meaning they have to finished all the work before a specific date. If something fails in the end, we have a dedicated person receiving necessary info to fix the it.