The written brief, a node-by-node runbook of every workflow, and a live environment you can submit a real request to and watch it route.
FieldOps Co. runs procurement approvals across eight business units. Requests arrive by email and form, get priced, and route to the right approver by amount. Today that is manual, and a request can sit for days with nobody sure where it stopped.
I built one business unit end to end in n8n, on a pattern that carries over to the other seven. The workflow prices each request itself against the approved vendor catalogs, and that price is what decides where it routes, so the requester's guess never drives the decision. Everything that changes between units lives in data tables the platform team edits, so onboarding the next unit is a few rows of config and the workflow logic stays the same.
The decision path has no model in it. Routing a spend approval should be auditable and repeatable, so correctness here is proven by a test suite that runs the same way every time. I only reach for AI where a plain rule cannot do the job.
Every request writes one audit row when it finishes. Cycle time, stall rate, off-contract rate, and rework rate are all queries against that row, so the measurement comes for free from running the workflow. A monitor watches every workflow and alerts on Slack and email the moment one fails.
The written deliverable: how I run pre-engagement discovery, the solution design, how value gets measured across the 90-day window, and how the whole build generalizes to the next customer.
Open the brief →The node-by-node operator runbook. Every zone, every node, what it does and what to change, with the config tables that drive it. The same reference the canvas sticky notes link into.
Open the runbook →The spine underneath it all: n8n orchestrates, the rules and catalogs live in data tables the platform team owns, the approval runs on a signed single-use link that holds even when Slack is down, and the notification channel is easy to swap: Slack here, but Teams, Google Chat, or any provider by changing the send node.
The team that maintains this is often deeply technical without being coders. Network engineers, database engineers, people who understand systems cold but do not write code every day. n8n is built on the low-code premise, and AI covers the rest of the gap. Someone who understands the concept of the workflow can read it, change a rule, and extend it with an assistant next to them.
That is what the config-in-tables design and the documentation are for. The whole doc set also ships as a single plain-text file, llms-full.txt: the maintaining team loads the entire system into their assistant in one file, so it can help them read and grow the build from day one. Understand the first principles of what a system does and you can run it, whether or not you write the code.
The pilot proves one unit end to end and the pattern to roll out the rest. It stops where the next decision belongs to FieldOps. Three things are left as roadmap on purpose, with the reason for each.