What breaks during a Blue Prism RPA pilot
A Blue Prism RPA pilot almost always looks convincing: the robot completes the main scenario on prepared data and handles routine faster than a human operator.
Then the process goes into a live stream, and what was not reproduced in the demo breaks there: a changed UI element, a pop-up window, an ambiguous value in a field, an unavailable service.
The first typical failure is the lack of exception handling. The scenario assumes a successful run, so when there is a deviation the robot either crashes or hangs waiting, and the task queue piles up.
Cases are closed by an operator bypassing the robot, and the share of such manual completions is not recorded anywhere: in the report the process looks healthy, although part of the work happens outside it.
The second is the fragility of the scenario: binding to coordinates, to the exact text of a label, to row order in a table.
An update of the accounting system breaks such a scenario entirely, and each fix costs more than relying on stable element attributes and explicit checks of the result of a step.
The third is reruns and duplicate protection.
If the robot failed after partially posting an operation, a rerun without checking generates duplicate records, and without tracing for each case it is unclear at which step the result was lost — support turns into manual reconciliation.
In sum, robot failures make the pilot indistinguishable from manual work: the cycle time is shorter, but the human remains in the loop, and RPA implementation does not move into operation.
We break down how this is closed — by designing exception handling, stable selectors, and metrics that show the process runs on its own.
What industrial operation of robots provides
Industrial mode is not running the robot on a larger number of cases, but controllability: queue, retries, failure isolation, observability. In a pilot, the process relies on manual restart; in operation, it relies on rules that themselves decide the fate of a stuck task.
Blue Prism carries the execution layer, while routing and control are built above it. This gives process resilience and a predictable task flow.
Task flow processing speed
Tasks are processed in batches and in parallel: several executors pick up the queue, not one robot sequentially. The bottleneck moves to the external system — this is visible in metrics: waiting in queue, share of tasks closed on the first attempt, number of retries per task.
Peaks are absorbed by adding executors, not by manual intervention, and batch processing time becomes predictable: load is planned by schedule, not as it happens.
Eliminated failure classes
Some failures go away not because of operator care, but because of architecture: session break, lost response from an external system, duplicates on resend, hanging on a UI element.
Each class has its own rule — timeout, retry with an idempotency key, a separate queue for human review.
Robot monitoring works not as a log for the sake of a log, but as a signal: at which step the task stopped, which attempt this is, what managed to go to the external system.
This gives a clear recovery time, no "silent" failures, and a metric that shows the result: the share of tasks reaching the end without manual review.
Comparison of approaches to integrating robots and models
The scheme is chosen based on where decision-making logic lives and how to change it without stopping the robots.
In Blue Prism and neighboring environments, three options are compared in practice: enhancing existing robots, a separate environment for models, and a unified platform with orchestration.
| Option | When it fits | Limitations |
|---|---|---|
| Enhancing existing robots | One stable process, the model solves a narrow task: classification, field extraction | Logic spreads across processes, there is no common policy for versions and rollbacks; support becomes more expensive with each new task |
| Separate environment for models | Load isolation and separate access policies are needed, training must not affect robots | A second control center: queues, retries, and statuses are synchronized manually |
| Unified platform with orchestration | Multiple processes, shared queues, end-to-end audit, a single release point for changes | Preliminary design is needed: roles, exchange rules, observability |
When a separate environment is justified, and when it gets in the way
A separate environment is justified when the model is trained on a data stream that cannot be mixed with production, or when access requirements for robots and for the model service differ.
It is also appropriate as a transitional step: the pilot checks solution quality and does not touch production processes.
It gets in the way when queues and statuses begin to duplicate: the robot waits for the model's response, while the trace of the operation is lost between two systems, and failure analysis turns into log reconciliation.
If a decision is made from several sources and requires manual approval, splitting logic across two environments is more expensive than designing a common integration scheme once.
Implementation stages: from process audit to handover
The order of work is the same for any process: first we understand how the task is performed today, then we move it to a robot, and only then do we take it into industrial operation.
Each stage ends with an artifact the customer can verify — without it we do not move to the next step.
Process audit and exception map
We look at the process in the real system, not in the description: which steps repeat, where a human decision is required, which data arrives incomplete.
The exception map — typical failures, rollback branches, rare scenarios — determines how much attention the robot will require in operation.
- Process audit: interviews with executors, timekeeping, log analysis, candidate selection by frequency and stability of input data.
- Exception map: list of failures, rules for handling them, escalation points to an operator.
- Solution design: composition of robots, order of steps, integration with accounting systems, target metrics.
- Robot setup: assembling the process on Blue Prism, working with interfaces and documents, retries, logging.
- Acceptance checks: run on prepared data sets, comparison of results with manual work.
- Handover to support: regulations, monitoring, training of the customer's team, change procedure.
Testing on a real task flow
Before industrial launch, the robot runs on the production flow in parallel with an employee: we compare results line by line, calculate the share of discrepancies and the processing time of one request. We increase volume gradually — first part of the flow, then the full flow.
Rollback at any step means returning tasks to a human without stopping the process, and the frequency of failure classes is included in the acceptance report so that operations knows what to respond to.
Documentation package, access policies, and regulations
All artifacts are assembled during the work, not written before handover: each process has an owner and a version, each change has a record of what changed and why. Below is what remains with your team after the Blue Prism environment goes into industrial operation.
Access policies and roles for robot accounts
- Process diagrams: step map, branching points, exception handling, and retries — a new engineer uses them to enter the logic without digging through source code.
- Configurations: connections, queues, schedules, and dependencies are separated from process code, so changing a system address or credentials does not require reassembly.
- Credential access policies: a separate account for each robot, minimum necessary rights, secrets in a secure vault, and scheduled password rotation.
- Role matrix: who can start, stop, change a process, and read logs — with separation of duties between operations and development.
- Support regulations: failure response procedure, responsibility areas, response times, escalation, and maintenance windows.
- Automation documentation: process purpose, input and output data, dependent systems, and known limitations.
- Versioning and rollback: where previous versions of the process are stored and how to return to them in one operation.
The package is checked at acceptance: we run a failure and recovery scenario according to the regulations together with your operations service.
If the work cannot be restored from the document without contacting the process author, the package is not ready — this is a handover criterion, not a wish.
How the process moved from pilot to industrial operation
The process is application processing for connection: intake from the queue, verification of details, billing setup, customer notification.
In the pilot, the robot on Blue Prism handled only intake and verification, the rest remained with operators — and that is where delays accumulated.
What measurements before launch showed
The baseline was taken over several shifts at the same points: the share of manual operations in the application route — 68%, average processing time for one application — about 40 minutes, of which approximately 25 were spent switching between systems and re-entering the same data.
Failures caused by operator error — on average 7 per shift, and about half of applications after them returned for reprocessing.
What changed after moving to operation
The process was moved to industrial operation after measurements under real load matched the calculated ones. The robot took over verification, billing setup, and notifications; the operator kept only exceptions — incomplete data, discrepancies in details, manual approvals.
The share of manual operations decreased to 18%, application processing time — to 12 minutes, number of failures per shift — to 1-2, and almost all of them come from incomplete customer data rather than input errors.
We take post-launch metrics in the same ways as at the input, so the comparison remains correct, not "by eye."
How does an RPA pilot differ from industrial operation?
A pilot answers one question: is the process reproducible at all. The robot goes through the scenario on prepared data, exceptions are handled by an engineer nearby, and the result is checked visually.
Industrial operation checks something else — whether the same process withstands volume, heterogeneous data, and failures without a human at the screen, and these are already differences of mode, not cosmetics.
| What we compare | Pilot | Operation |
|---|---|---|
| Load | dozens of runs, some manual | schedule, thousands of runs, peak windows |
| Data | prepared data set | stream from systems, incomplete data and duplicates |
| Exceptions | handled by an engineer | automatic branches and retry queue |
| Control | logs reviewed after the fact | monitoring, alerts, run metrics |
| Failure | demo stopped, fixed manually | recovery regulations and downtime |
Load tests provide what a demo does not: how many robots run in parallel, how target systems handle the peak, what happens when they are unavailable, and whether duplicates appear on rerun after a crash.
Operational requirements are also closed here — service accounts instead of personal ones, password rotation, log retention period, and the on-call notification scheme.
Moving to operation is a mode change, not acceptance: no one reviews the robot's work on Blue Prism line by line, so we fix the criteria before the pilot.
These are the share of successful runs on the real flow, recovery time after a failure, and the share of cases that still require manual review.
Common technical questions before project start
Before start, the customer's engineers ask the same questions — not about model quality, but about compatibility with already running robots, access, and updates of external systems. Below are short answers that remove most doubts.
What will happen to already running robots?
We do not rewrite them. The AI layer is added as a separate step; the rest of the Blue Prism logic does not change. Rollback means disabling one call, without stopping the process.
What access will the robot receive?
A separate service account with the minimum necessary rights, without manual login. Secrets are in a secure vault with scheduled rotation; we agree on the set of rights before start.
What happens when an external system is updated?
We move call points and selectors into configuration, not code: when the interface changes, one file is edited and the same set of checks is run. Critical steps are backed up by result validation.
How to scale to other departments?
We move department parameters — details, reference data, schedules — into settings. A new branch is connected by an entry in the reference data, not by a second project.
Who supports the robots after launch?
We configure queue monitoring, logs, and failure alerts immediately; we train your team to handle typical failures and hand over the regulations.
Let's discuss the task and come back with an estimate and plan
To come back with an estimate and work plan, rather than a broad range "from and to", we need initial data on the process. A ready-made technical specification is not required — what you already have is enough: descriptions, access to test environments, request logs. The more specific the inputs, the fewer assumptions in the implementation estimate.
What helps calculate the scope accurately:
- Process description — steps, participants, decision points, where exactly time is lost.
- Blue Prism robot fleet — how many there are, what they automate, how often they fail, and who restarts them.
- List of systems — accounting, banking, portals, file exchanges; note where there is a software interface and where only screen input exists.
- Operation frequency — runs per day and per month, peak windows, response time requirements.
- Access requirements — service accounts, rights, separation of test and production environments.
- Constraints — maintenance windows, security rules, prohibition on moving data outside the perimeter.
If some data is missing, we will start with what is available and separately record what needs to be clarified. Describe the task or send an automation request in free form — we will come back with an estimate, work plan, and a list of what will be required from your side.
