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 scale
01Process captureWeek 1We 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.
02Bot buildWeeks 2–4We record it in RPA Builder and write the exception paths deliberately, instead of discovering them in production.
03Attended or unattendedWeeks 5–6Attended runs beside a person for the judgement calls; unattended runs on a schedule. Most processes want one of each, split at the decision point.
04Wired into AnypointWeek 7Bots triggered by, and reporting into, the same integration layer — so a bot failure raises the same alert everything else does.
05HandoverWeek 8Bot definitions in your own tenancy, an exception runbook, and the process documentation the capture produced.
Drawn at the long end: eight weeks for one process. Two processes are not sixteen weeks — the capture and the Anypoint wiring are done once — but they are not eight either. The scope is one process at a time, and so is the price.

What a bot engagement covers.

Four areas

Four 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.

  1. The bot definitionsRecorded steps, selectors and schedules, versioned, in your own RPA Manager tenancy.
  2. The exception runbookEvery path the bot can fail down, what it does when it does, and who it tells.
  3. The process documentationWhat the capture found: the process as it actually runs, including the parts nobody had written down.
  4. The Anypoint wiringTriggers and alerts on the same platform as your integrations, so a bot failure raises the alarm everything else does.