Process
Most automation work fails not in the implementation but in the framing. Before any code is written, I sit with the operations and find where automation pays back, and where the human has to remain.
Step
01
Bring the workflow you would describe to a new hire. Thirty minutes is enough to find where automation pays back. No preparation needed — describe the operation as it actually runs.
Step
02
After the conversation, I propose up to three automation candidates with the expected return and a rough implementation timeframe. We decide together which one to build first.
Step
03
The first deliverable is not code — it is the workflow design. Where humans stay in the loop and where automation takes over is drawn out and confirmed. This is also where I name what will not be built.
Step
04
I build it in n8n or as a custom implementation. Every AI output passes through one human approval queue. Learning a new admin screen is, as a rule, not required.
Step
05
Thirty days of free adjustment after handoff. The workflow is tuned to the actual operation. After that, you can choose either a maintenance contract or per-incident requests.
After Phase 1
Once the first system is running, the next move is yours.
Expand
Build on the running system to add the next automation. Workflows grow alongside how the operation actually changes.
Refine
Improve workflows already in production — error handling, processing speed, approval-flow refinements.
Maintain
Monthly maintenance: monitoring workflows, light refinements, keeping operating documentation current.
The first deliverable is the workflow design, not code. In thirty minutes I identify where automation pays back, and we decide together what to build first.
No sales calls. If we do not find the right starting point in thirty minutes, that is fine.