Most RPA programs stall in the same place. Someone picks a process that looks tedious, a developer builds a bot in a few weeks, it works in a demo, and then it sits in production quietly failing every time a vendor portal changes a button label. Nobody owns it. Nobody knows it broke. Six months later the finance team is back to doing the work manually and the automation budget is under review.
The build is rarely the hard part. Selection, documentation, exception handling, and ownership are the hard parts. Here is the sequence that works, in the order you should actually run it.
Step 1: Run process discovery before you commit to anything
Start by collecting candidates, not by picking one. Sit with two or three operational teams and ask a narrow question: what do you do every week that involves moving data between systems by hand?
You will get better answers by watching than by asking. Have someone screen record a full cycle of the task. You will see the workarounds people never mention in interviews: the spreadsheet they keep on the side, the second login they use because the first one lacks a permission, the step where they eyeball an invoice and make a judgment call.
Task mining and process mining tools can accelerate this if you already have them, but for a first wave, structured observation of five to fifteen candidate processes is enough. Write each one down with the system it touches, the volume per month, the average handling time, and the name of the person who currently owns the outcome.
That last field matters more than it looks. A process without a named owner is a process nobody will help you test, nobody will sign off on, and nobody will report as broken.
Step 2: Qualify candidates against hard criteria
Not every repetitive task is a good automation candidate. Run each one through the same filter, and be willing to disqualify things people are emotionally attached to.
Process qualification checklist
Answer yes or no to each. A candidate that collects more than two clear “no” answers should go back in the pipeline, not into your pilot.
- Is the process rules-based, with decisions that can be written as explicit if/then logic?
- Is it high volume or high frequency enough that saved effort is meaningful (daily or weekly, not twice a year)?
- Has the process been stable for at least six months, with no system migration or policy change scheduled in the next two quarters?
- Is the input data structured and consistent (fixed-format files, defined fields, predictable layouts)?
- Is the exception rate low, ideally under one in ten transactions requiring human judgment?
- Are the applications involved stable, and do you know who owns each one?
- Can a person perform the process end to end without accessing anything the bot cannot be credentialed for?
- Is the current process documented, or can it be documented accurately in under a week?
- Is there a named business owner who will sign off on test results?
- Is the process free of regulatory constraints that require a human decision-maker in the loop?
- Would you be comfortable running this process the same way for the next two years?
That final question is the one that catches broken processes. If the honest answer is that the process only exists because of a data quality problem upstream or a report someone stopped reading years ago, automating it just makes the waste faster and harder to see. Fix or retire it instead.
Step 3: Build the business case in effort, not headcount
Calculate expected savings the plain way. Take the number of transactions per month, multiply by average handling time, and you have current effort in hours. Estimate the share of that effort the bot will absorb, which is almost never one hundred percent because exceptions still route to a person. Subtract the effort of the exception queue and the effort of monitoring the bot.
Then subtract the cost side: platform licensing, development, infrastructure, and ongoing maintenance. Maintenance is the number teams get wrong. Bots are not set-and-forget software. They depend on applications they do not control, and every one of those applications will change.
Two framing choices make the business case more credible with a CFO. First, express the benefit as reclaimed capacity redirected to specific work, not as headcount reduction, unless headcount reduction is genuinely the plan. Second, present a payback period rather than a single ROI percentage. Payback forces you to be honest about when the maintenance cost starts.
Step 4: Choose a platform you can staff and support
The major enterprise platforms all handle the core work: UI automation, API calls, orchestration, credential management, and scheduling. UiPath, Automation Anywhere, SS&C Blue Prism, and Microsoft Power Automate each have mature offerings with attended and unattended execution models. The differences that actually affect your program are less about feature checklists and more about fit.
Ask these questions instead:
- What is already in your stack? If you are deep in Microsoft 365 and Azure with existing Power Platform governance, Power Automate removes a procurement cycle and a new admin surface.
- Who will build and maintain the bots? A platform your existing developers can learn, or one your implementation partner supports at depth, beats a marginally better tool nobody in the building knows.
- What does the licensing model do at scale? Per-bot, per-process, and per-machine models diverge sharply once you pass a handful of automations. Model your third-year state, not your pilot.
- How does it handle credentials, audit logging, and separation of duties? Your security team will ask, and the answer needs to exist before the pilot, not after.
- What does the vendor ecosystem look like locally? Access to people who have delivered on the platform matters. If you are shortlisting implementation help, it is worth reviewing RPA implementation partners alongside the tools themselves, because platform choice and delivery capability are the same decision in practice.
Get vendor trials and build the same small automation on two platforms before signing. Two weeks of hands-on work will tell you more than a month of demos.
Step 5: Scope the pilot deliberately small
Pick one process. Ideally the second-best candidate on your list, not the first. The best candidate usually has the highest visibility, and you do not want your learning curve happening in front of the executive sponsor.
Good pilot characteristics: one or two applications, a clear owner who has time, volume high enough to prove value within a quarter, and a failure mode that is annoying rather than catastrophic. Avoid anything that touches customer-facing commitments or regulated reporting on the first run.
Set a fixed timebox and define what “done” means before development starts. A pilot that keeps expanding scope is a pilot that never produces a verdict.
Step 6: Write the process definition document
The process definition document (PDD) is where most of the real work happens, and it is the artifact teams most often skip.
A usable PDD includes:
- The end-to-end process flow, step by step, at the level of individual clicks and field entries.
- Every input: file formats, sources, naming conventions, arrival schedule.
- Every decision point, with the exact rule, including the edge cases people apply from memory.
- Every known exception and what should happen to it.
- System access requirements: applications, roles, service accounts, and who provisions them.
- Expected outputs and how success is verified.
- Volume and timing data.
Have the business owner review and sign the PDD. When the bot behaves differently from what someone expected, the PDD is the thing you go back to. Without it, you get an argument.
Expect the documentation phase to surface variation you did not know existed. Two people doing the same process rarely do it identically. You have to pick one canonical path, and that is a business decision, not a developer decision.
Step 7: Set up environments before you build
You need at least development, test, and production environments, with the target applications available in a non-production form or with test data that does not touch live records. Service accounts should be dedicated to the bot, never a borrowed human login, and credentials should live in the platform’s vault rather than in the automation itself.
Decide early where bots run: dedicated virtual machines, a hosted option from the vendor, or existing infrastructure. Unattended bots need a machine that stays available, does not get patched out from under them at random, and does not lock the session in a way that breaks UI automation.
Build with reusable components from the first bot. Login routines, error logging, and email notification patterns should be shared libraries, not copy-pasted into each automation.
Step 8: Test the exceptions, not just the happy path
Happy-path testing proves almost nothing. The bot will hit conditions your PDD did not anticipate on its first production week.
Build a test set that includes: malformed inputs, missing fields, duplicate records, application timeouts, unexpected popups, session expiry, records that already exist, and empty result sets. For each, decide whether the bot retries, skips and logs, or halts and escalates. Write that decision down.
Every automation needs an exception handling plan with three parts: business exceptions (data the bot correctly identifies as needing a human), system exceptions (the application failed), and an escalation path with a named recipient. If there is no queue where failed transactions land and no person checking it, you have built a silent failure machine.
Run user acceptance testing with the people who currently do the work. They will spot wrong output faster than any test script.
Step 9: Deploy, then run hypercare
Go live on a subset first: a single region, a single client, or a percentage of volume. Run the bot in parallel with the manual process for at least one full cycle and reconcile the outputs.
Hypercare means two to four weeks of daily monitoring with the developer still assigned. Watch the exception queue, transaction logs, and run durations. A run time that creeps upward is usually the earliest signal that something changed in the target application.
Do not close the project until you have transitioned support to whoever owns it long term, with runbooks that explain what each failure code means and who to call.
Pre-launch readiness checklist
Before any bot goes to production, confirm every item:
- The PDD is signed by the business owner and matches what was built.
- Service accounts exist, are dedicated, and have documented permissions.
- Credentials are stored in the platform vault, not in code or config files.
- Exception queue exists and a named person monitors it daily.
- Escalation contacts and response expectations are documented.
- Logging captures enough detail to diagnose a failure without reproducing it.
- Rollback plan exists: you can revert to the manual process within one business day.
- Schedule and dependencies are confirmed with the application owners.
- Change notification is in place so app owners tell you before they release updates.
- Success metrics are defined and a baseline was captured before go-live.
- Support ownership is assigned by name, with a backup.
Step 10: Build the operating model that lets you scale
One bot is a project. Ten bots is an operation, and it needs structure.
A center of excellence, even a small one, gives you three things: a standing intake pipeline so new candidates get scored consistently, development standards so any developer can support any bot, and a maintenance function that owns the fleet.
Governance should cover naming conventions, code review, environment promotion, credential rotation, and a register of every bot with its owner, its dependencies, and its last change date. That register is what saves you when an application team announces an upgrade.
Maintenance deserves an explicit budget line. Plan for a standing share of your automation capacity dedicated to fixing bots rather than building new ones. Selector-based UI automation is inherently brittle, so prefer APIs where they exist, use stable element identifiers rather than screen coordinates, and build resilient selectors that do not depend on cosmetic attributes.
The single most valuable habit is a change notification relationship with the owners of every application your bots touch. Being on that distribution list turns a production outage into a scheduled fix.
Where processes involve semi-structured inputs like invoices or claims, intelligent document processing can extend the range of what qualifies, since it converts unstructured content into the structured data a bot needs. Treat it as an extension of the same pipeline, subject to the same qualification and exception rules.
If you are scoping a first wave and want a delivery team that has run this sequence before, comparing the best RPA companies is a reasonable next step before you commit to a platform or a pilot.
