How we work, written down
The method we use, the research behind it, and the places where the evidence is thin. Nothing to fill in, no email required.
Why this is a document and not a page
Most of what's written about process automation is either a vendor's brochure or somebody selling a course. This is the method we actually use, the reasoning behind each phase, and the research it leans on, including where that research doesn't say what we'd like it to.
It's ungated because you might need to forward it to whoever approves spending, and because a form standing between you and it would tell you something about us we'd rather not be true.
- 01
Immersion
One to two weeks, before anything gets built.
We sit with the people who do the work and time it. Not an estimate, a count. Owners are usually wrong about their own admin by a factor of two, in both directions. This number is the baseline everything afterwards gets measured against, and it's the one thing that can't be recovered later. - 02
Foundations
Short, on purpose.
We write down what the process actually does. The exceptions, the decisions, and why they were made. In a company without an engineering team, that knowledge lives in people rather than in documents, and getting it out is most of the job. - 03
Build
Four to six weeks.
Two engineers, on a fixed weekly rhythm that doesn't change depending on how the work is going. Something live at the end of it. - 04
Handover
Then somebody watches it who isn't you.
Nothing goes live without a runbook: how to tell it's broken, what to check first, who to call. Then we time the same process again against the Immersion baseline. If the number didn't move, we say so.
If you already have engineers and your systems are documented, the first two steps are much shorter and we'll tell you so rather than bill you for a fortnight of reading.
Ask us about any phase on the call. We'll tell you where it has held up and where it hasn't.