(Business process automation)

Map the process first, automate the parts that deserve it

Business process automation goes wrong when the tool arrives before the map. We spend the first fortnight with the people doing the work, then build the workflows, approvals and integrations that actually shorten it.

Talk to an engineer What we deliver

(Order of operations)

Half of what a slow process costs is queueing, not typing. A request sits in an inbox for two days, then takes four minutes to approve. Automating the four minutes changes almost nothing; removing the two days changes everything. That is why the mapping comes first and the build comes second.

The map is drawn from observation rather than from the policy document, because the two rarely match. Where they differ, the version people actually follow is usually the one that works.

(What we deliver)

What business process automation covers

Most engagements run through the first two and then pick whichever of the rest the map justifies.

  1. Sessions with the people who run the process, a BPMN diagram of what really happens, and an exception log — the cases that break the happy path and how often they turn up. Cycle time and touch time are recorded separately, because they lead to different fixes.

  2. Long-running processes modelled as explicit state machines in Camunda or Temporal rather than a chain of scheduled scripts. Every instance has a visible position, a history and a timer, so a request stuck since Tuesday can be explained without reading logs.

  3. Routing rules, delegation when someone is on leave, escalation when an SLA is at risk, and an audit trail that records who approved what against which version of the request. This is where most home-grown workflow tools quietly fall over.

  4. Invoices, purchase orders, claims and forms read with OCR and document AI, validated against your master data, and posted automatically when confidence is high. Anything below the threshold goes to a person with the extracted fields already filled in.

  5. The steps between systems built as APIs, queues and webhooks: idempotent, retried, monitored. A nightly CSV that somebody re-runs by hand when it fails is not automation, it is a scheduled chore.

  6. Each automated process ships with a baseline and a dashboard: runs completed, exceptions raised, hours displaced, time from request to resolution. Without it you are guessing, and the next business case has nothing to stand on.

(What we build with)

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

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

  2. 02

    Design

    Flows, architecture and interfaces agreed before anyone writes production code.

  3. 03

    Build

    Two-week increments, a working environment you can open, and a demo at the end of each one.

  4. 04

    Testing

    Functional, performance, security and accessibility checks run through the build, not bolted on at the end.

  5. 05

    Launch

    Deployment, monitoring, documentation and the handover your team needs to run it.

  6. 06

    Support

    Fixes, updates and the next set of features, at an agreed monthly capacity.

(Why Team of Keys)

Why the mapping phase pays for itself

Clients sometimes ask to skip straight to the build. The ones who do usually come back to the mapping later, having paid for it twice.

  1. 01

    Steps get deleted, not encoded

    A typical map turns up two or three checks that exist because of an incident nobody present can date. Removing them is free and takes effect the same afternoon. Automating them is neither free nor immediate.

  2. 02

    Exceptions are priced before the build

    The happy path is a fortnight of work. The eleven exceptions behind it are the other three months, and they are what turns a confident estimate into an overrun. Counting them during the map is what makes a number hold.

  3. 03

    One rulebook, not four opinions

    Mapping forces finance, operations and the branch that does it differently to agree in a room. That agreement is worth more than the diagram it produces.

  4. 04

    The cheapest tool wins

    Some processes need a workflow engine. Some need a form and a shared mailbox rule. Deciding after the map rather than before it stops you paying platform licences for a problem a validation rule would have solved.

  5. 05

    Handover is built in

    Process models, decision tables and runbooks live in your repository in a readable format. Your own team can change a rule without raising a ticket with us.

(Related)

More in automation

All automation services

(FAQ)

Questions, answered

Mapping a single end-to-end process is a fixed, modest price and takes one to two weeks. The build depends on what the map finds: a straightforward approval flow with two integrations is a few weeks of work, while a claims process spanning four systems and a document pipeline is a phased project. You see both figures before committing to the second.

Business process automation redesigns the process and connects systems directly. RPA drives the user interface of a system you cannot change. They answer different questions, and a good project often uses both — the workflow engine orchestrates, and a bot handles the one step behind a portal with no API.

Mapping takes one to two weeks and frequently produces savings on its own through steps you can remove immediately. A first automated workflow generally runs in production within six to ten weeks of the map being signed off, and the dashboard shows displaced hours from the first week it is live.

Yes — that is the usual situation. Automation sits around SAP, Dynamics, Odoo, Tally, Salesforce and whatever the warehouse runs on, using supported APIs where they exist. Nothing is written into a vendor database directly, because that is how a support contract gets voided.

Rules that change often are kept out of code, in decision tables or configuration your team can edit. Structural changes come out of an agreed monthly capacity. Every automation also has an owner named at handover, so when a regulation shifts there is no argument about whose job it is.

(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)

Send us the process that eats the most hours

Tell us who touches it, how often it runs and where it stalls. You get a map, an exception count and a phased price.

START

Or write to info@teamofkeys.com · Noida, India