RPA maintenance: the work, outsourcing costs, and the team

An RPA robot’s maintenance starts the day it goes live. By morning, a robot has stopped. A customer’s screen changes and it needs fixing. The steps of the work change, and someone asks for the robot to follow. A product upgrade arrives. As this piles up, change requests wait in a queue and payments to an outside maintenance vendor go out every month.

This article splits RPA maintenance and operation into the six things they actually involve, then covers fixing in-house versus outsourcing, the prices outside maintenance services publish, how to set up the team, and how to shrink the load. It applies to WinActor, UiPath, BizRobo!, and Power Automate Desktop alike; the prices are for Japan. For how to total licenses and fixing effort, see what RPA costs to keep running.

Key points

• RPA maintenance and operation means six things: handling stops, fixing after screen changes, handling change requests, upgrades, license management, and keeping the robot ledger
• Product support and robot maintenance are different things. Fixing a stopped robot falls to your own staff or a maintenance vendor
• Few maintenance services publish prices. Those that do sell tickets, a flat monthly fee, or consulting. Check in the contract whether fixes for screen changes are included
• For the team, name who manages the whole, an owner and operators for each robot, and who fixes. Even if you outsource, keep the ledger and the owners in-house

What RPA maintenance and operation are

Operating RPA means running robots every day, checking the results, and responding when they stop. Maintaining it means fixing robots, changing them, and keeping the environment they run in working. In practice, the same people usually do both.

The RPA guidebook for local governments from Japan’s Ministry of Internal Affairs and Communications (July 2025) says that keeping RPA in use means reworking scenarios continually, for stops and malfunctions, changes in regulations, and so on. It also says robots are unstable right after they go live, and even once stable they are affected whenever the systems they operate change, so stops and malfunctions should be treated as likely.

The six things are:

Task	What it involves	When it comes
Handling stops	Notice the stop, check how far it got, then cover by hand or fix it and run the rest	Without warning, often on busy days such as closing day
Fixing after screen changes	Find the robots whose screens changed, fix them, and check them	Each time the other system is updated; outside systems often give no notice
Change requests	Change a robot’s steps when the work, forms, customers, or regulations change	Whenever business teams ask; bunched around regulatory changes
Upgrades	Check that every robot still runs after updates to the RPA product, OS, browser, or Excel	On the product’s update cycle and support deadlines
License management	Know how many licenses you have, when they renew, which PCs use them, and which sit unused	At the yearly renewal, and when PCs or robots come and go
Robot ledger	Keep the list of what each robot does and who is responsible for it current with every change	When a robot is built or changed, or its owner changes

1. Handling stops

When a robot stops, work through these steps:

1. Notice: send failure notifications to a team, not to one person
2. Check how far it got: use the error message and the log to see which items finished and where it stopped
3. Keep the work going: decide whether to wait for a fix or do the work by hand. If closing day is near, do it by hand first
4. Fix it and run the rest: rerun without the items already done, so nothing is entered twice
5. Record it: the date, the cause, the fix, and the time it took

The guidebook calls it most important to build safeguards in from the start: when unexpected data arrives, or the system being operated stops or slows down, either halt the automatic processing and add a step where a person decides, or skip the item so a person can check it later. A robot that keeps going and does the wrong thing does more damage than one that stops.

Why robots stop, and how to build ones that stop less, is covered in why RPA robots stop when screens change.

2. Fixing after screen changes

For robots that operate outside web systems, this is most of the maintenance work. A button moves slightly, or fields change order, and the robot can’t find what to act on and stops.

Fixing means finding the affected robots, fixing them, checking them with test data, and putting them back into production. If the ledger’s “connected systems” column is filled in, you can find every robot that operates the changed system at once. The guidebook likewise says to use the ledger to assess the impact on robots whenever a system is updated or an outside system’s specification changes.

For internal systems, a rule that update plans reach the RPA team in advance lets you fix robots before they stop.

3. Change requests

When the work changes, the robot’s steps have to change too: a new customer, an extra column on a form, a different approval flow, a regulatory change. When few people can fix robots, this is where requests pile up.

The guidebook describes local governments that stopped using RPA because, in work with frequent regulatory changes, scenario fixes could not keep up.

To keep requests from piling up, take them in through one channel, set priorities by impact such as closing day, and let business staff make small changes themselves.

4. Upgrades

RPA products set a support deadline for each version. Once a version is past it, you get no product support even when something breaks. The rules for the main products, as of October 2026:

Product	Versions and support
WinActor	When a new minor version comes out, sales and support of the previous latest version end one year after the new release. Versions not on the list are outside the maker’s support. Support for Ver.7.6.1 runs until August 31, 2027
UiPath (on-premises)	One long-term support release a year, typically in October. Mainstream support runs 24 months from release, then extended support for 12 months (some contracts add a further year of limited support). Versions past support receive no support of any kind
Power Automate Desktop	A new version almost every month (2610 on October 15, 2026). A flow created or edited in a newer version may not work correctly in an older one. Rolling back to a previous version is not supported

With every upgrade, check that every robot runs on the new version. Update a test PC first and run all the robots on it; if nothing breaks, update the production PCs. For products like Power Automate Desktop, where flows can stop working when the PC that builds them and the PC that runs them are on different versions, update them together. The guidebook also says to use the ledger to define the scope of work when applying patches or upgrading.

End of support for an OS, browser, or scripting language can bring rework across every robot. Internet Explorer’s end of support and the VBScript deprecation are summarized in what RPA costs to keep running.

5. License management

How you manage licenses depends on whether they are per PC or by concurrent use. A WinActor node-locked license, for example, allows one installation on one PC, while floating licenses use a management product and are sized to the number of PCs running at once.

Track how many licenses you have and when they renew, which PCs and accounts use them, and whether any sit unused. The guidebook lists recording license types, quantities, and the PCs they are installed on in the ledger, finding idle time from usage, and rebalancing licenses and PCs.

Retiring a robot does not shrink the license contract by itself. A few months before renewal, compare the ledger with actual use. Recent price revisions are summarized in what RPA costs to keep running.

6. The robot ledger

Each of the other five tasks goes faster with a ledger, because it tells you at once whom to contact and how to cover by hand when a robot stops, which robots operate a system whose screens changed, which robots an upgrade touches, and which PCs use the licenses.

The columns and update rules are covered in how to build a robot ledger for RPA, and there is an Excel template ready to use.

In-house or outsourced maintenance

The guidebook divides who builds and fixes robots three ways: outside contractors, the IT department, or business departments, and says combinations work too. Companies can think about it the same way.

	An outside maintenance vendor	IT or the DX team	Business departments
How fast a fix comes	Days, through request, quote, and work	Waits when requests bunch up	Fast
How you pay	Contract fees; even small fixes cost money	The team’s time	Business staff’s time
What stays in-house	Working robots; the vendor knows what is inside	Company-wide rules, and people who can fix	People who know the work and can fix
Weak spot	You keep depending on the vendor; work outside the contract costs extra	The fine details of the work are hard to see	Robots only their builder can fix, and rogue robots, appear easily
Suits companies that	Cannot put anyone in-house on fixing	Have many robots and want to manage them company-wide	Can name two people in the business department

The guidebook says that if you outsource every fix, you need to budget enough for maintenance, and if you can’t, you should arrange to make at least small changes in-house. Conversely, even when business departments fix their own robots, it recommends being able to get outside help when needed, such as answers to questions or on-site support capped at a set number of hours.

One more distinction: product support and robot maintenance are different things. WinActor’s support service, for example, answers questions about what the manuals say and about the product’s specifications (functions, specs, and limits), and covers the latest version. Fixing a robot that has stopped falls to your own staff or a maintenance vendor you contract separately.

The prices outside maintenance services publish

Most RPA maintenance services set prices by individual quote, and few publish them. These are the examples we could confirm in October 2026:

Provider and service	Type	Published price	Terms
Information Development, “ID-Cross RPA Remote Maintenance Service” (WinActor, UiPath)	Tickets	From ¥500,000 for 25 tickets, from ¥950,000 for 50, from ¥210,000 for 10 more (reference prices)	Handles spec changes, error fixes and investigation, license renewal, moving to a new runtime PC, and similar work. One ticket is up to half a person-day (about 4 hours). Contracts run in six-month units, with at most 20 tickets a month as a rule. Announced May 2022
CEC, “RPA Flat-Rate Support Service” (ROBOWARE)	Flat monthly fee	Maintenance plan ¥300,000 a month (build plan ¥600,000 a month)	Includes the ROBOWARE license. Maintains scenarios made under the build plan. Contracts in three-month units
ITSO, “RPA Subscription”	Flat monthly fee (building, monitoring, and fixing together)	¥100,000 a month (¥50,000 a month for each unit from the second)	Unlimited development. Includes updates to follow system changes, and troubleshooting. One-year minimum
Digital Vorn, “BizRobo! Online Support”	Consulting	Trial plan ¥40,000 a month before tax for up to four sessions; extra sessions ¥14,000 each	45-minute web meetings answering development and operations questions. Three-month contract. Reported September 2020

Only Digital Vorn states how tax is treated. ID-Cross’s reference prices come to about ¥20,000 per ticket, one piece of work of up to four hours.

What each type suits:

• Tickets or hourly: robots that stop rarely, with fixes that come irregularly. How many tickets a fix takes is decided after you ask
• Flat monthly fee: many robots, with fixes every month. Building and maintenance often come together, and only robots built under the service may be covered
• Consulting: you have someone in-house who fixes robots and want help only when they get stuck. The fixing itself stays in-house

How to compare outsourcing with build costs included is covered in what outsourcing automation costs.

What to check before signing a maintenance contract

1. Are fixes for screen changes included in the fee? What about fixes for changes in the work?
2. How long from request to fix? Does it cover stops on closing day or at night?
3. Is there a cap per month or per fix, and what does going over cost?
4. Do you receive a record of what was fixed and why?
5. When the contract ends, can the robots and their manuals be handed to your own staff or another vendor?
6. Is checking robots after a product upgrade included?

Setting up the team

The team decides who manages the whole, who owns each robot, and who fixes. The guidebook splits this into “governance,” which sets company-wide rules and checks that they are followed, and “management,” which names a manager and an operator for each robot and runs its building, fixing, and operation.

Role	What they do	Who, for example
Managing the whole	Sets the rules. Manages the ledger and licenses. Tallies stops and results, and decides what to retire	IT, the DX team
Robot owner	Sets the robot’s purpose and priority, and approves changes to its steps	A manager in the business department that uses it
Robot operators	Check results daily. Cover by hand when it stops. Request changes	Two people in the business department
Who fixes	Investigates and fixes stops. Handles change requests. Checks robots after upgrades	IT, business staff, or a maintenance vendor

Two operators means someone is still there to act when the robot stops, even after one of them moves on. Taking over robots whose builder has left is covered in taking over an RPA bot whose builder has left.

Rules to agree on

• The path when a robot stops: where notifications go, who looks first, and how to cover by hand
• How change requests come in: the channel, how priorities are set, and what business departments may change themselves
• Notice before systems change: plans to update or change internal systems reach the RPA team in advance
• Checks before production: test with test data, and run in production only after the owner approves
• Ledger updates: update the ledger as part of the same procedure as any change to a robot
• A yearly inventory: compare the ledger with the robots actually running, and with the licenses

What stays in-house even when you outsource

Even with a maintenance vendor, keep the ledger, an owner for each robot, the steps for covering by hand when a robot stops, and the records of fixes the vendor sends you. Without them, when you change vendors or review the contract, no one knows what the vendor was looking after.

How to shrink the maintenance load

1. Retire robots no one needs: when the work is gone, or the volume is small enough to do by hand, retire the robot and cut the license too
2. Replace screen work with official integrations: if the other system offers an API or CSV downloads, stop operating its screens. Screen changes can no longer stop the robot
3. Make the ledger answer impact questions at once: when screens change, when upgrades come, and when owners change, you find the affected robots right away
4. Record stops and start with the robots that stop most: keep, for each robot, how often it stopped and how long fixes took, and you will often find the effort concentrated in a few robots. How to turn that time into cost is covered in what RPA costs to keep running
5. Use robots that relearn when screens change: if a robot repeats the operations it recorded and relearns only those a changed screen no longer matches, small screen changes no longer need a fix each time

Move the robots that keep stopping to Kitewell

The robots that stop most can also be moved to Descarty’s Kitewell. After the move, maintenance work changes like this:

• When a screen changes: a workflow repeats what it learned in the same order every time, and AI relearns only the operations a changed screen no longer matches, so the work goes on. Which operations it relearned stays on record with screenshots. Steps that read PDFs or Excel files, or check a screen, use AI every run
• Change requests: the person in charge asks Kitewell in a chat to change the steps, and checks the change before it is applied
• When it stops: failures are sent to email, Slack, Microsoft Teams, and more. After a fix, the rest runs from the step that stopped
• The ledger: every workflow can be exported to Excel as a robot ledger
• Upgrades: automatic updates, so there is no upgrade work

Fixes can come from your own staff asking in a chat, or from maintenance support by Descarty or a partner; you choose.

Kitewell does not read robot files: you describe your current robot’s steps in words, and AI builds the workflow again on the real screens. Kitewell Team is ¥14,800 per computer a month, or ¥148,000 a year (excluding tax), the same for building and running computers. You can try Kitewell free for 14 days, or ask for a 30-minute demo. See RPA migration for how it works.

Summary

• RPA maintenance and operation means six things: handling stops, fixing after screen changes, change requests, upgrades, license management, and the robot ledger
• Product support and robot maintenance are different things; fixing a stopped robot falls to your own staff or a maintenance vendor
• Few maintenance services publish prices; those that do sell tickets, a flat monthly fee, or consulting. Check in the contract whether screen-change fixes are included, how long fixes take, and that you receive records and can hand the robots over
• For the team, name who manages the whole, an owner and two operators for each robot, and who fixes. Even if you outsource, keep the ledger and the owners in-house
• To shrink the load, cut the number of robots, replace screen work with official integrations, and start with the robots that stop most

Sources

• Ministry of Internal Affairs and Communications: RPA guidebook for local governments (July 2025; in Japanese)
• WinActor: Lifecycle policy (September 1, 2026; in Japanese), License prices (in Japanese)
• NTT DATA: WinActor support service terms (version of September 25, 2025; in Japanese)
• UiPath: Product lifecycle support terms, Release strategy (checked October 28, 2026)
• Microsoft: Released versions for Power Automate for desktop (October 16, 2026), Update or roll back Power Automate for desktop
• Information Development: Launch of the RPA remote maintenance service (May 31, 2022; in Japanese)
• CEC: RPA flat-rate support service (checked October 28, 2026; in Japanese)
• ITSO: RPA subscription (checked October 28, 2026; in Japanese)
• Cloud Watch: Digital Vorn’s online support for BizRobo! (September 18, 2020; in Japanese)