Service 02
Process automation
Taking off your hands the repetitive work that today depends on someone remembering to do it.
Context
Almost every company has a process that works because one specific person runs a sequence of steps every day. Copying data from one system to another, checking a spreadsheet, sending a notice, generating a report. It works until that person takes a holiday.
The work here is to map that process as it actually happens — not as the manual describes it — and rebuild it as code that runs on its own, with a record of what was done and an alert when something falls outside the expected.
Signs this is your case
- Someone on the team spends hours a week moving data between systems
- A mistake is only found when the customer complains
- The process stalls when one specific person is away
- There's a spreadsheet nobody may touch because it breaks everything
What you're left with
- A map of the current process, with the points where it fails today
- Automation running in production, with an execution log
- Active alerting when a run fails — silence is not a sign of success
- Operational documentation for whoever will live with it
What it isn't
- A robot that clicks on screen and breaks when the layout changes
- Automating a process that hasn't been decided yet
A workflow in practice
A document arrives and the process moves on
An illustrative workflow, not a client case study or a promised result.
See the monthly retainerReceive
A document arrives through the agreed channel. The workflow records its source and detects what has already been processed.
Check
Required fields and rules are validated. Incomplete documents go to a review queue with a reason.
Route
The record reaches the destination system. Your team can see successes, failures and what needs correcting.
Where I start
We pick one repetitive process. I follow a manual run and define how to verify the output before automating it.
What continues every month
Document formats, rules and systems change. The retainer covers adapting to those changes, fixing failures and prioritising the next workflow.
Questions about this front
Is automation the same as a robot clicking the screen?
No, and the difference matters: a screen-clicking robot depends on the layout staying identical and breaks on the first change. What I build talks to the system through the way it was meant to be accessed — API, database, file — and survives interface changes.
How do I know the automation ran?
Through an execution log and active alerting when a run fails. Silence is not a sign of success: automation without alerting is the kind that breaks in January and gets noticed in March.