Process mapping and measurement
We measure what the manual process actually costs before automating it. Roughly half the time the answer changes what we automate, and occasionally it shows the automation is not worth building.
Service 03
Automation & Data Workflows
Software that removes work instead of adding another system to manage, starting with whichever manual process is costing you the most hours.
01You are probably here because
Symptoms
- “Someone spends a day a month assembling the same report.”
- “We re-key data between two systems every week.”
- “Our process works but only because one person remembers all the exceptions.”
02What we actually do
The work, described properly.
Workflow automation
The repetitive path runs unattended. The ambiguous cases are routed to a person with the context already assembled, which is usually a bigger saving than the automation itself.
Scheduled jobs and pipelines
Jobs that are idempotent, resumable and observable, so a failed run at 03:00 is a retry rather than an incident.
Reporting and internal dashboards
One place the numbers come from, with the definition of each number written next to it. Most reporting disputes are definition disputes.
Document and data extraction
Turning invoices, statements and exports into structured records, with a confidence threshold below which a human checks it.
03Our approach
How we approach it
How we approach it
Automation projects fail in a specific, predictable way: someone automates the process as described, then discovers the described process is not the real one. The real one has exceptions, undocumented judgement calls, and a person who quietly fixes things.
So we measure first. We sit with whoever does the work and count: how often, how long, how many exceptions, and what happens when it goes wrong.
The hard parts we take a position on
Automate the measured process, not the documented one. The gap between them is where automation projects die. Finding it costs a few days; discovering it after launch costs the project.
Do not automate a bad process. Making a broken workflow faster produces broken results more quickly. Sometimes the finding is that the process should change, and the software should be smaller than you expected.
Leave a person in the loop where the cost of being wrong is high. Full automation is a good goal for rules and a bad goal for judgement. A confidence threshold with human review above it is usually the right shape.
04Technology, and why
Defaults, not dogma.
- Scheduled workers
- Plain scheduled jobs are easier to reason about than an event mesh when the cadence is daily.
- SQL
- Reporting logic belongs close to the data, where it can be verified against the source.
05Related work
Where we have done this.
Reconciling three payment sources into one ledger
Three payment sources, three spreadsheets and a six-hour weekly reconciliation, replaced by a scheduled job that only asks for a human on exceptions.
FAQQuestions we get
Questions we get
How do you decide what to automate first?
Hours saved per month divided by build effort, with a bias toward whatever is also the most error-prone. The expensive manual step is not always the slow one.
What about the exceptions?
Most processes are eighty per cent routine. We automate that and route the rest to a person with the context pre-assembled, rather than trying to encode every rare case.
Will this need maintaining?
Yes, and we say so up front. Automation that touches a third party will break when they change. We build in monitoring so you find out immediately.
Often paired with
—Automation & Data Workflows
Discuss a automation project.
Tell us what is happening. We will reply with a real technical question, not a calendar link.
- 01
Send a short brief
Five minutes. What you are building, or what is broken.
- 02
We reply within one business day
From an engineer, with a real question or observation.
- 03
A 30-minute technical call
Free, no deck, no obligation.