AI ERP with agents inside the systems you run
AI phone and voice agents for real calls
LLM.coPrivate, self-hosted LLM deployments
Legal AI infrastructure for firms
AI RFP discovery and response drafting
Automatic.coBusiness process automation
CyberAttack.aiThreat detection and defense
Secure AI virtual data rooms
Senior only
Engineers on every build
Process mapping through bot maintenance
US-based
Team, start to finish
No unnamed subcontractor added mid-project
Day one
You own the code and the bots
Runs in your environment, from the first commit
10 biz days
To start
From a signed scope to the first sprint
Before you automate
RPA is the right tool for a narrower set of problems than it's sold for
Robotic process automation means scripting a computer to do what a person currently does by hand — reading a screen, moving data between systems, following the same rule every time. It's a genuinely strong fit for some work and a poor one for other work that gets sold the same way. Knowing which is which before you scope a bot saves the rebuild later.
RPA fits rules-based, repeatable work
Moving data between systems, filling in a form the same way every time, reconciling two reports against a fixed rule. If a person doing the task would never need to use judgment, a bot can do it reliably.
RPA is the wrong tool for judgment calls
Deciding whether an invoice looks fraudulent, classifying an ambiguous support ticket, or anything where a trained person would weigh context — that needs a machine learning layer on top of, or instead of, scripted RPA. Automating the judgment call with plain rules just moves the error rate somewhere less visible.
APIs beat screen-scraping every time one exists
A bot built against a documented API reads structured data and rarely breaks. A bot built by scripting clicks against a UI is reading pixels and coordinates, and it breaks the day that UI gets a redesign nobody told you about. Check for an API before accepting a screen-scraping scope.
Screen-scraping is sometimes the only option, not a shortcut
Legacy mainframes, some vendor portals, and systems with no public API leave no other path. That's a legitimate reason to screen-scrape — the problem is when it's chosen for convenience on a system that actually exposes an API nobody checked for.
Process mapping comes before automation, not after
Automating a broken or undocumented process just makes the broken process run faster and harder to change. Mapping every branch and exception first — including the ones nobody mentions until the bot hits them in production — is what keeps a bot from silently doing the wrong thing on the case nobody thought to describe.
A bot inherits every quirk of the process it copies
If the person doing the task today has an informal workaround for a known data-entry bug upstream, the bot needs that workaround explicitly designed in — it won't discover it the way a person would, and it won't flag that anything's unusual when it hits the case that needs one.
What it costs
RPA engagement types
Real ranges for the engagements we're actually asked to run. The variable that moves a quote is not the number of bots — it's how many source systems are undocumented, and how many exceptions the process actually has once you go looking.
| Engagement | Commitment | Timeline | What's included |
|---|---|---|---|
| Process assessment | Fixed scope | 1 – 3 weeks | Process mapping, an automation-fit rating for each candidate task, and a prioritized list ranked by return against effort. |
| Single-process bot build | Fixed scope | 3 – 6 weeks | One process automated end to end, including exception handling for the branches the mapping phase actually found. |
| Multi-process automation program | Fixed scope | 8 – 16 weeks | Several related bots built against a shared framework, with centralized logging and a single place to see what's running and what failed. |
| AI-assisted automation | Fixed scope | 6 – 12 weeks | A classification or extraction model layered onto rules-based RPA for the parts of the process that need judgment rather than a fixed rule. |
| Ongoing bot maintenance | Ongoing retainer | Ongoing | Monitoring, source-system change detection, and fixes when an upstream UI or schema changes underneath a running bot. |
Ranges assume US-based senior engineers and include exception-handling design, not just the happy path. A quote well under these bands is usually automating only the common case and leaving every edge case to fail silently in production, which shows up later as a support ticket nobody can explain.
Where bots break
RPA maintenance is the part every pitch underestimates
A bot that works perfectly on day one is not the same thing as a bot that's still working in month eight. Screen-based automation in particular is fragile in a specific, predictable way, and planning for that is cheaper than discovering it during an outage.
A UI redesign breaks a screen-scraping bot without warning
The vendor or internal team that owns the source system has no reason to know a bot depends on the exact position of a button, and no obligation to warn anyone before changing it. Monitoring that catches a failed run within hours, not days, is what keeps this from becoming an invisible backlog of unprocessed work.
An API version bump is gentler, but not free
API-based bots break less often than screen-scraping ones, but a deprecated endpoint or a changed response schema still needs someone watching for it. Version pinning and a deprecation-notice habit reduce surprise, they don't eliminate it.
Exception volume tends to grow, not shrink, after launch
The mapping phase finds the exceptions that happen often enough to notice. The rare ones surface over the following months, one at a time, and each one is a small design decision about whether the bot should handle it, flag it, or stop and wait for a person.
Centralized logging is what makes maintenance possible at all
A bot that fails silently in a script window nobody's watching is worse than no automation, because everyone assumes the work is getting done. A dashboard showing what ran, what failed, and why turns maintenance into a routine check instead of a surprise.
Bot sprawl is the long-term failure mode, not any single bot breaking
Dozens of small bots built by different people over a few years, with no shared framework or inventory, becomes its own undocumented legacy system — the exact problem RPA was supposed to fix, one layer up. An inventory of what's running and who owns it should exist from the second bot onward, not the fiftieth.
RPA and AI
Where RPA ends and machine learning actually starts
Modern automation projects increasingly combine both, and knowing which piece is doing which job keeps the design honest instead of over-promising what plain rules-based RPA can do on its own.
Structured data, fixed rules: RPA alone
Moving a number from one system to another, applying a fixed threshold, filling a form the same way every time. No model needed, and adding one here just adds cost and a new failure mode for no benefit.
Unstructured input, consistent categories: add classification
Sorting incoming documents or tickets into a known, fixed set of categories is a good fit for a classification model feeding into an RPA workflow that then acts on the result.
Extracting data from documents: add OCR and extraction
Pulling structured fields out of invoices, forms, or scanned documents that vary in layout is squarely a document-intelligence problem, not something a scripted bot can do reliably on its own.
Genuine judgment calls: keep a person in the loop
Anything with real ambiguity or business risk in the decision — approving an exception, flagging likely fraud — should route to a person with the AI's assessment as input, not silently auto-decide. The point of adding AI here is better-informed humans, not fewer of them making the call.
The AI layer needs the same maintenance discipline as the bot
A classification model trained on last year's document formats drifts as those formats change, the same way a screen-scraping bot drifts when a UI changes. Budget for retraining and accuracy monitoring, not just the initial build.
Start with RPA, add AI where the mapping shows you need it
Building the AI layer before mapping the process usually means guessing at what needs judgment instead of knowing. The assessment phase should tell you exactly which steps are rules and which are calls, before either gets built.
How an engagement runs
From process map to a bot your team can operate
The sequence below exists so a bot ships with documentation and monitoring attached, not as a script only its author understands.
Business process mapping
Breaking the process into discrete, actionable steps and documenting every branch and exception, not just the common path — this is the work that determines whether automation will actually hold up in production.
Automation-fit assessment
Rating each candidate step for whether it's a fixed rule, a judgment call, or something in between, and sequencing the build around the highest-return, lowest-risk steps first.
Design and build
Building against an API wherever one exists, with exception handling designed in from the branches the mapping phase found — not added after the bot hits one in production.
Testing against real cases, not just the happy path
Running the bot against historical data that includes the known exceptions, and deliberately including the messy, rare cases rather than only the clean examples used in the demo.
Deployment with monitoring attached
Shipping with logging and alerting in place from day one, so a failed run surfaces within hours instead of showing up as a pile of unprocessed work weeks later.
Ongoing support
Watching for source-system changes, fixing what breaks, and extending the bot as the process it automates inevitably changes too.
Related
Related services
What RPA projects usually need alongside the bots themselves.
Questions
RPA questions we get before scoping a build
What teams ask before a first call.
RPA is software that performs a rules-based, repeatable task the way a person currently does it by hand — moving data between systems, filling in a form, reconciling two reports against a fixed rule. It works best on tasks a trained person would do the exact same way every single time.
It is not a general problem-solver. Tasks that genuinely need judgment or handle unpredictable input need a machine learning layer added on top, or a person kept in the loop, rather than more elaborate rules bolted onto a scripted bot.
RPA follows a fixed, explicit rule every time — if this, then that. AI and machine learning make probabilistic judgment calls on input that varies, like classifying a document or flagging likely fraud.
Many real automation programs use both: RPA moves and processes structured data reliably, while an AI layer handles the classification or extraction step that a fixed rule can't. Knowing which piece of a workflow is which, before either gets built, keeps the project honest about what a bot alone can and can't do.
Anything rules-based and repeatable: data entry between systems that don't talk to each other natively, reconciliation against a fixed rule, and repetitive form-filling are the classic cases. A quick way to check fit — if a well-trained person would do the task the exact same way every time with no judgment calls, it's a strong candidate.
Work that requires weighing context or exercising judgment is a poor fit for RPA alone, whatever a sales deck says about it. Those steps need an AI layer or a human decision point, not a more complicated rule set.
Screen-scraping bots break when the source system's user interface changes, because the bot is reading pixels and coordinates rather than structured data — a redesign the vendor never announced to you is enough to stop it cold. API-based bots are sturdier but not immune; a deprecated endpoint or a changed response schema can still break them.
This is why maintenance and monitoring should be part of the scope from day one, not an afterthought. A bot that fails silently for weeks is worse than doing the task by hand, because everyone assumes the work is happening.
Not yet. Automating a broken process just makes the broken process run faster and harder to change, and an undocumented one usually has exceptions nobody remembers to mention until the bot hits one in production and does the wrong thing.
Map and document the process first, fix anything that's clearly broken, and automate what's left. The mapping phase is also where you find out whether a step is actually a fixed rule or a judgment call in disguise — the distinction that decides whether plain RPA is even the right tool.
Both are legitimate, and the right choice depends on how many processes you're automating and who maintains them afterward. A commercial RPA platform gives you a visual builder and a large community, which suits a team that wants business analysts building and maintaining simple bots themselves.
A custom-built solution is often the better fit when the automation needs to integrate tightly with existing infrastructure, handle a volume the platform's pricing model punishes, or avoid vendor lock-in on a process that's core to the business. We'll tell you which one your actual volume and team structure calls for before recommending either.
You do. Bots should run in your own environment, on your own infrastructure or RPA platform license, with the source code and configuration in a repository you own from the first commit.
If an automation only runs on a vendor's hosted infrastructure under their account, that is a switching cost you're deferring, not avoiding — confirm ownership and portability before signing, not after you try to leave.