Why the step exists
Ask why a step exists and the honest answer is often historical: a system could not do something in 2014, so a person did it, and the person is still doing it in 2026. The system was replaced twice in between.
Automating that step encodes a decade-old constraint into software that will outlive everyone who remembers the reason.
The three questions we ask before automating anything
What decision does this step actually change? What happens if we simply stop doing it? And who would notice — with a name, not a department.
A surprising number of steps fail all three. Those get removed, and the removal delivers more value than any automation would have.
- What decision does this step change?
- What breaks if we stop doing it entirely?
- Who specifically would notice, by name?
Redesign, then automate
We build a redesign phase into every automation engagement precisely so this happens before code. It typically removes 15–25% of the steps, which reduces build cost, reduces ongoing maintenance, and makes the remaining automation dramatically simpler to reason about.
Working on this yourself?
We run ninety-minute working sessions with no charge and no pitch. Bring the process that keeps breaking and whatever numbers you have.
Book a session