Automate the systems that never got an API.
Some systems cannot be integrated, only operated: a supplier portal with no API, a mainframe screen, a PDF somebody rekeys into Salesforce every morning. A bot drives those the way a person does, except at 3am and without transcription errors — and because it runs on Anypoint, it raises the same alert everything else does when it breaks.
- Shape
- Fixed-scope project
- Typical length
- 4–8 weeks per process
- Priced
- Per process automated
- Starts with
- A process capture
- You keep
- Bot definitions, exception runbook, process docs
Eight weeks, one process.
Per process, drawn to scaleWhat a bot engagement covers.
Four areasFour areas, and the fourth is the one nobody quotes for. A bot automates a process somebody else can change without telling you, so the caveat is written into the scope rather than discovered in month three.
Process capture first
We sit with whoever does the work today and record it. What looks like one process is usually three, and one of them should not exist at all. The capture produces the process documentation you keep, whether or not a bot is ever built.
Attended and unattended
Most processes want one of each, split at the decision point:
| Mode | Runs | Best for |
|---|---|---|
| Attended | Beside a person, on demand | Steps needing a judgement call — exceptions, approvals, anything with a “usually” in it |
| Unattended | On a schedule, on a server | High-volume repetition, overnight batches, anything that should have finished before the office opens |
What we build
- Bot definitions in RPA Builder — with the exception paths written deliberately, instead of discovered in production
- Document processing — reading the invoice or the statement rather than the person reading it
- Anypoint triggers — bots started by, and reporting into, the same integration layer, so a bot failure raises the same alert everything else does
- RPA Manager — scheduling, queues and run history in one place
The honest caveat
A bot breaks when somebody changes the screen it drives. That maintenance is real and it is ongoing — it belongs in a support retainer, not hidden inside a project price. We say so before the engagement starts rather than after.
You keep the bot definitions in your own tenancy, an exception runbook, and the process documentation the capture produced.
The handover
What you are left holding.
A bot you cannot change is a liability with a schedule. These four are what make it yours to change.
- The bot definitionsRecorded steps, selectors and schedules, versioned, in your own RPA Manager tenancy.
- The exception runbookEvery path the bot can fail down, what it does when it does, and who it tells.
- The process documentationWhat the capture found: the process as it actually runs, including the parts nobody had written down.
- The Anypoint wiringTriggers and alerts on the same platform as your integrations, so a bot failure raises the alarm everything else does.