Loading…
Loading…
One workflow at a time, proved on your own documents
Six phases from working out whether a workflow is worth automating at all, through building it on your own documents, to running it beside the existing process before anything depends on it. It is written down so you can see what happens next, and where you can stop.
Each phase ends in something you can look at, and any of them can end the engagement. The order exists so the expensive decisions come after the cheap evidence, rather than the other way round.
Find where the day actually snags
I sit with the work as it is actually done: which jobs go wrong, how often, and what it costs when they do. That means your documents, your systems and the people using them, not a questionnaire.
Small enough to finish, specific enough to test
I design the smallest system that addresses the workflow we picked, against your real formats and the software you already run. You get the design, the measure of success, and an honest read on what it will not do.
See it hold up, or fail, before you commit
I build it on your own documents before you commission a build, so feasibility is demonstrated rather than asserted. If it does not hold up on your material, this is the cheap place to find out.
Into the real workflow, not beside it
I build the production version and integrate it with the systems you already run. Anything the system is unsure of surfaces to a person rather than being guessed at, and every automated decision leaves a record.
A window where a wrong answer costs nothing
It runs beside the existing process first, and its output is compared against what your people produce. Nothing depends on it until that comparison holds. Your team is trained on it and the handover is written down.
It will not stay working on its own
I stay on to keep it working. Upstream formats drift and APIs change, and an unattended workflow degrades within months -- that is what the monthly retainer is for, not for keeping you dependent.
Each phase exists to make the next decision cheaper to reverse. The order is the argument: nothing is built before it has been tried on your own documents, and nothing carries weight before it has run beside the process it replaces.
The prototype runs on your documents before the build is commissioned, so the decision to carry on is made on evidence rather than on a proposal.
If the prototype does not hold up on your material, you stop there having paid for an assessment rather than a build.
Workflows are ranked by the effort to build against what they actually save, and the ones not worth touching yet are named as such.
Your people are trained on what was built and the handover is documented. You should be able to run it without me.
How an engagement runs, what happens at each phase, and where it can stop.
Tell me which job goes wrong and how often. I will walk you through what the first phase would look like on your own documents, and say plainly if it is not worth doing yet.