(Robotic process automation)
Robotic process automation for systems that will never get an API
Robotic process automation earns its keep on the terminal emulator, the supplier portal and the desktop application nobody can change. Everywhere else, an integration is cheaper to build and far cheaper to keep alive.
(What a bot really is)
A bot is software pretending to be a person at a keyboard. That is its strength — no vendor has to agree to anything — and also its weakness, because a relocated button can stop it at three in the morning. Build one where the alternative is genuinely closed, and design it expecting the interface to move.
Roughly a third of the processes clients bring us as bot candidates turn out to have a supported API or a database view behind them. Those get built as integrations instead, and cost less to run.
(What we deliver)
What our RPA development covers
From judging whether a process should be a bot at all, through to the day the bot is retired because a real interface finally exists.
-
Each proposed process scored on volume, rule stability, interface volatility and how much of it is genuinely digital. The output is a shortlist and a rejected list, with the reason next to each — often that an API exists and nobody knew.
-
Reusable components, selectors written against stable attributes rather than screen positions, and configuration kept in a file instead of hard-coded. UiPath REFramework or the Blue Prism object layer, so the next developer recognises the shape immediately.
-
Work items go into an Orchestrator or Blue Prism queue with a unique reference, a status and a retry count. Runs are scheduled, throttled and traceable, and two bots can share a workload without processing the same invoice twice.
-
Business exceptions — a missing purchase order, a mismatched total — are routed to a person with context attached. System exceptions retry, then stop and alert. Nothing is quietly swallowed, and every failed item stays visible until someone closes it.
-
Unattended bots run on their own machines against a schedule and a credential vault. Attended automations sit on a user desktop and fire when a person asks, which suits contact centres and anything needing judgement mid-process. The licensing differs sharply, so the choice is made early.
-
Bots break because the world around them changes. Monitoring on success rate and run time, a monthly capacity for selector repairs, and a review each year asking whether an integration can now replace the bot entirely.
(Tools we work in)
- 01UiPath Studio and Orchestrator
- 02Blue Prism
- 03Power Automate Desktop
- 04C# and VB.NET custom activities
- 05Python for parsing and OCR
- 06UI selectors, OCR and computer vision
- 07CyberArk and Azure Key Vault for credentials
- 08SQL Server for queues and audit
- 09Windows Server and Azure runtimes
(How we work)
How the work runs
Every engagement is scoped in phases, priced per phase, and reviewed with you at the end of each one.
-
01
Discovery
We map the problem, the systems around it and what a good outcome looks like, then scope the work in phases you can stop after.
-
02
Design
Flows, architecture and interfaces agreed before anyone writes production code.
-
03
Build
Two-week increments, a working environment you can open, and a demo at the end of each one.
-
04
Testing
Functional, performance, security and accessibility checks run through the build, not bolted on at the end.
-
05
Launch
Deployment, monitoring, documentation and the handover your team needs to run it.
-
06
Support
Fixes, updates and the next set of features, at an agreed monthly capacity.
(Why Team of Keys)
How we keep bots from becoming the next legacy system
The common failure is not a bot that never worked. It is forty bots that worked once, each written differently, none monitored, all owned by someone who has left.
-
01
A bot is the second choice
Before anything is built we look for an API, a database view, a supported export or a vendor integration. If one exists, we say so — even though the bot would have been the larger piece of work for us.
-
02
Selectors built to survive
Anchors on element identifiers and labels rather than coordinates, with a fallback strategy and a clear failure when neither matches. Coordinate-based clicking looks quick in a demo and breaks on the next screen resolution.
-
03
Credentials never in the code
Bot accounts are named service accounts with their own least-privilege permissions, and secrets live in a vault. Shared logins make an audit trail meaningless and tend to fail an internal review.
-
04
Licence maths before the build
Unattended runtimes, Orchestrator tenants and Power Automate premium seats all cost money each year. You get the annual figure alongside the build estimate, because for small processes the licence alone can outweigh the saving.
-
05
Documented for your team
Process definition documents, solution design documents and a runbook per bot. If you later bring RPA in-house or move platform, there is something to hand over beyond the workflow file.
(Related)
More in automation
(FAQ)
Questions, answered
Two costs run in parallel. Development for a moderate process — one system, clear rules, a handful of exceptions — is typically three to six weeks. Platform licensing is separate and annual: unattended runtimes and orchestration are the usual line items. For a process consuming only a few hours a month, the licence often makes the case unviable, and we will tell you that before you buy it.
A simple data-entry bot against one stable application takes two to three weeks including testing. Anything crossing several systems, handling documents or carrying a long exception list runs longer, mostly because of exceptions rather than the happy path. Assessment and process definition add about a week before the build starts.
Unattended suits high-volume back-office work that runs to a schedule with no human in the loop — reconciliations, bulk uploads, overnight reporting. Attended suits work a person triggers during a conversation, such as pulling records together while a customer is on the line. Licensing and infrastructure differ, so the decision is made during assessment.
The bot fails, and monitoring tells you before the business does. Selector repairs usually take hours rather than days if the automation was built with stable anchors. Most clients keep a small monthly capacity for exactly this; vendor upgrade cycles for the target applications are worth knowing about in advance.
Yes. A common first engagement is a review of bots already in production: what still runs, what fails silently, what duplicates something the ERP now does natively. You get a list of bots worth keeping, repairing or retiring, and we can then work inside your existing Orchestrator rather than standing anything new up.
(Global presence)
Nine countries, one studio behind them.
Every project is designed, built and shipped from one studio.
Turn the globe, or pick a country to see what we deliver there.
NoidaDrag to turn
Studio · Noida, India · --:--
(Next step)
Tell us which screen your team retypes into
Name the application, the volume and the rules. You get an honest verdict on bot versus integration, with a price for whichever wins.
START