Apply five n8n workflow tips to client work: plan with three discovery questions, log every input, agent decision, and action, test against real client tickets, deliver in weekly chunks, and document every node. Automation builder Bart Slodyczka shared this five-step process in a November 2025 walkthrough of how he delivers client projects in n8n, the source-available workflow automation tool.
How do you plan an n8n workflow before building it?
Ask three discovery questions before opening the n8n canvas: what happens before the workflow, what the client's existing process is, and what happens after it. Clients describe what they want at a high level, such as an AI agent that monitors a Gmail inbox, and a literal build of that request usually misses their real expectations.
A quick build would chain a Gmail trigger into an AI agent that drafts replies back into the thread. The client then discovers it mishandles their actual cases, and you rebuild from scratch. Discovery replaces that loop. In the plumbing-business example from the video, one question ('why do customers email you?') revealed two sender types, customers and suppliers, and four request types: new quotes, job status, delivery updates, and payment chases.
From those answers, map the requirements in a spreadsheet. One tab lists the variables and request types; a second tab records the process for each type, such as logging the interaction in a CRM, pulling prices from a Google Sheets price list, or falling back to a human when the CRM field is empty. You can also hand the client the sheet and ask them to list everything the system should do, link their process to each item, and state what the system will not handle, such as tax queries.
This sheet does double duty. It becomes the scope of work and the pricing basis, because you now know how many systems you integrate with and roughly how long each piece takes. If the client has standard operating procedures or team members who run the process today, ask for those too. You are translating an existing process into n8n, not redesigning their business.
What should you log in an n8n workflow?
Log three key stages: the input data, the agent's decision, and the action taken. A manager checks a team's output on a leaderboard; a spreadsheet log gives the client the same view of their automation, so they can see what came in, what the system decided, and what it did without opening Gmail.
In the demo workflow the three stages map directly to nodes:
| Stage | Node | What to record |
|---|---|---|
| Input | Gmail trigger | Email subject and body |
| Decision | AI agent node | Generated response or category |
| Action | Gmail send node | Reply actually sent, or a failure marker |
Implement the log by inserting append-row nodes into a Google Sheets sheet; the same pattern works with Airtable or Supabase. Log the raw email right after the trigger, the agent's output after the agent step, and the sent reply after the Gmail action. Separating the three logs lets you and the client spot exactly which stage misbehaved instead of guessing from one combined row.
The presenter adds two workflow patterns worth copying. First, he runs a Claude Code step after each agent to parse its output into variables, defined in the prompt itself rather than through a structured-output parser, which keeps the LLM node count down. Second, he keeps agents read-only: the agent brings information into context, but outward actions like sending email live in separate nodes outside the agent step. Both make the log cleaner and the workflow easier to debug.
How do you add failure routes and alerts to an n8n workflow?
Give each risky stage a failure route that writes an obvious error marker to the log and notifies someone. An agent step can fail when API tokens run out or OpenAI has an outage, and a Gmail node can fail when credentials expire or the account that authenticated the connection is deleted. Either failure silently stops every reply, and a client missing a week of quote requests will notice before you do.
Use n8n's error-continuation setting on the agent and Gmail nodes. On failure, write a static message like 'agent step failed' into the sheet, optionally in a success/failure column, and then fire a notification through a Slack message or an SMS via Twilio. Who receives the alert depends on your role: if you manage many client workflows, route failures to yourself first so you can fix small issues before the client ever sees them.
The presenter skips logging on the Gmail trigger itself because it is an authenticated third-party node, but notes that a webhook trigger deserves payload and sender validation with its own fail route. The result is a workflow with a success path and a failure path for each critical stage, which is what turns a three-node prototype into a production system and justifies a higher price, because you did the failure thinking for the client.
How do you test an n8n workflow against real client cases?
Ask the client for about five example tickets per request type, then replay them through a built-in test station in the workflow. Real examples, copied Gmail threads or an exported mailbox, show you the process as it actually happens and often reveal efficiencies the client cannot see.
Sending a live test email, waiting for the trigger to fire, and inspecting the result is slow and pollutes the client's account. Instead, separate the trigger from the logic: keep the production Gmail trigger, but place a manual 'execute when clicked' trigger with an Edit Fields (Set) node at the start of the workflow, holding sample ticket subject and body values. The agent and every downstream node reference that Edit Fields node, so switching between test and production requires no rewiring; only the trigger changes.
Duplicate the test node once per example, one each for new quotes, job status, delivery info, and payment requests in the demo, and paste the real ticket text from the planning sheet into each. Run the workflow manually on each case, check the output against the client's described process, and mark each case green when it passes. Recording the execution IDs gives you an audit trail. n8n also offers evaluation features for automated testing, but this manual station is fast and uses exactly the cases the client cares about.
Why deliver an n8n project in stages instead of all at once?
Deliver in chunks so the client gets something usable every week and you get feedback before the design drifts. The presenter learned the hard way that waiting to ship everything at the end of an eight-week project leaves the client disengaged and you uncalibrated.
Add delivery-date columns to the planning sheet, pick a quick win such as the customer-facing agent, and hand it over with its test cases. The client tries it in their real Gmail, then reports which responses work and which need a process update. You fold that feedback into the next stage, in this example the supplier agent, before building more on top of a wrong foundation.
Staged delivery also writes your proposal for you: the sheet already lists deliverables, dates, and full scope. Each weekly handoff keeps the client engaged, confirms you are building the right thing, and surfaces scope changes while they are still cheap to absorb.
How do you hand over an n8n workflow so someone else can run it?
Document the workflow so a stranger, the client or their next technical hire, can take over without you. The test is simple: assume you will never touch this workflow again, and make sure the next person can diagnose a failure from the canvas alone.
Use n8n's node notes and workflow description. Label the workflow's purpose, mark which trigger is for testing and which is for production, and name each Google Sheets node by what it actually does, such as 'logs email contents' versus 'checks customer type'. When you trace an execution, the green path turns red at the failing node, and a labeled canvas lets you zoom straight to 'agent error, API call failed' instead of reverse-engineering a wall of anonymous nodes.
The presenter calls this leaving breadcrumbs, the same habit as commenting code, and keeps a visible test section so the client can drop notes next to the cases they checked. If failures are logged, alerts are routed, and every node explains itself, the handover is a folder of documentation rather than a phone call.
Frequently asked questions
- Do I need all three discovery questions for every n8n client project? No. Any combination of the three, before, current process, and after, usually unblocks enough detail. The goal is to gather the client's real process, not to redesign their business around what is easiest to automate.
- Why use Google Sheets for logging instead of a database? Sheets keeps the log visible and editable for non-technical clients, and the append-row pattern transfers directly to Airtable Supabase. Choose the tool the client will actually open when they want to review what the agent did.
- Why keep AI agents read-only in n8n? A read-only agent can only bring data into context, so every external write lives in its own logged node. That separation gives you a distinct log per stage and makes failures easier to isolate and explain to the client.
- How many example tickets should I request for testing? About five per request type is enough to cover the main cases, such as new quotes, job status, delivery updates, and payments. Real past tickets beat invented ones because they carry the messy wording your agent will actually see.
- What is the fastest way to switch an n8n workflow between testing and production? Reference a single Edit Fields node fed by both a manual trigger and the production trigger. Downstream nodes never change; you only pick which trigger supplies the sample data.
Turn your own process walkthroughs into written guides
The five steps above work because they were written down somewhere a builder could follow them, week by week. If you explain processes like these in YouTube videos, that knowledge stays locked in a timeline most readers will never scrub through. Related community resources include Crazystack Typescript, the Bootcamp do Dev Doido by Gustavo Dev Doido, and Skalablog.
Skalablog converts an existing video into a structured article: paste the YouTube URL at Skala Blog, the video is transcribed, and the transcript becomes a publishable draft you review. Your delivery process, like the one in this article, can reach readers who prefer text without you writing a word from scratch.
Fork this article
Start a new branch from the same video, shaped your way. You keep the credit; the original keeps the attribution.
A fork in another language is filed as a translation of this article, so the two pages point at each other. You can unlink it later from the editor.
0/240
You are creating
- Format
- For
- Language
- Source
- Your angle
You will be asked to sign in before it is generated.
Buy credits