DEV Community: vlotstroom

How to price n8n client work: build hours, a monthly retainer and cost pass-through

vlotstroom — Sat, 07 Nov 2026 13:47:08 +0000

"How much should I charge for this n8n build?" shows up in r/n8n almost every month. I went back through two years of those threads, read the substantive answers, and turned the repeated advice into a quoting model. This post is that model, with the numbers I would defend to a client.

Price the whole job, not the workflow

A client does not buy 14 nodes. They buy a working thing that keeps working. My quote starts from five blocks:

Discovery. What the process actually does today, who answers when it fails. I default to 3 hours.
Build hours by complexity. Simple workflow, one trigger and one or two actions: 4 hours. Medium, several branches, error paths, a sheet or database in the loop: 8 hours. Complex, multiple systems, retries, custom code: 16 hours.
Migration. Moving existing logic into n8n. I default to 6 hours, because there is always an ugly spreadsheet.
Hand-over. Accounts in the client's name, credentials rotated, a short runbook. 3 hours.
Testing buffer. 25 percent on top, stated as its own line. If I do not need it I say so afterwards. That line builds more trust than a discount.

Worked example with those defaults, one simple and one medium workflow:

Block	Hours
Build (1 simple + 1 medium)	12
Discovery	3
Migration	6
Hand-over	3
Buffer (25%)	6
Total	30

At $50 per hour that is a $1,500 project price. Change the rate and the hours for your own market. The point is the shape: the workflow itself is less than half the job.

The retainer is a separate product

Every seasoned answer in those threads separates the build from the month after. Practitioner consensus from the most substantive thread on running costs:

Maintenance is 1 to 2 hours per client per month on a mature setup, more in the first 90 days. I default to 1.5 hours. At $50 per hour that is $75 per month before hosting.
Hosting is cheap and should not be your margin. A $6-12 VPS carries 5-10 small clients, so about $1.33 per client per month on an $8 box shared across six. A dedicated instance for one client is around $24 per month.
The client owns the instance and the billing once you hand over. The top-scored advice is blunt: you never get paid once and then keep paying for the client's compute out of your own pocket.
A flat $50-150 per month per client for reliability and maintenance is a common working pattern. You are charging for the pager, not the hours.

Variable costs go on the client's account, with a cap

AI calls, OCR, SMS, enrichment APIs. These compound. One practitioner in that same thread reports teams that budget $30 per month and hit $300 in month two when per-call volume grows. Two rules from the threads handle this:

Run the workflow on the client's own API accounts. Estimate their token use from real traffic, not from your demo data.
Split fixed costs (hosting, monitoring, support time) from variable costs, and set a monthly usage cap per workflow. Over the cap means a conversation, not a surprise invoice.

The same discipline applies to AI features specifically: measure what the workflow consumes before you quote the retainer. I wrote a separate piece on measuring what n8n AI workflows cost with a ledger pattern for exactly that.

What the quote must say

From the pricing thread where this is spelled out best:

What maintenance includes: fixes, monitoring, updates, and how many hours.
What it excludes: new features are a new project, priced separately.
A hosting pattern people recognize: 3 months free, then a fixed amount per month per workflow.
Contract length: 6-12 months is normal, longer is better for both sides.
Hand-over terms: everything created in the client's name, so leaving is clean.

An ambiguous quote is a future argument. One page, includes, excludes, cap, term.

The calculator

I turned this model into a free tool: the n8n client price calculator. Every default you see above is an editable field, the totals use only the numbers on the page, and it runs entirely in your browser. It also builds the include/exclude checklist for the quote. It is the same stance as my other calculators: honest arithmetic, no signup, nothing sent anywhere.

If you deliver automation to clients for a living and want a head start, I sell a ready-made client-delivery kit: seven production-shaped n8n workflows with demo data, import checks and validation transcripts, for EUR 29. You charge the client; the kit saves you the build hours. Details on the Vlotstroom hub and the store page.

All practitioner figures in this post come from public r/n8n threads, linked above. The hours and rates are defaults, not truths. Edit them until they match your market, then defend the shape.

Stop re-reading the whole sheet: a push-sync design for Google Sheets and n8n

vlotstroom — Thu, 22 Oct 2026 04:55:02 +0000

A cron workflow that reads a Google Sheet on every run pays the same tax every time: the full download. The Sheets node reads a range, and the v4 read behind it (spreadsheets.values.get) takes render options, not query conditions, so narrowing columns in the node narrows the result after the transfer, not the transfer itself. At 50,000 rows that read is slow and heavy, and every strategy that starts with "read the sheet, then decide" repeats it on every run.

There is a server-side exception worth knowing. The Visualization query endpoint (gviz/tq) accepts SQL-ish SELECT ... WHERE and returns JSON, documented in Google's query language reference, and you can hit it from an HTTP Request node. It answers queries, which makes it the right tool for one job in this design: reading a single column cheaply. It is not a sync mechanism.

The design that survives a sheet edited by humans all day inverts the flow: the sheet pushes, n8n keeps a projection, and a nightly reconcile heals drift. Three pieces.

Piece 1: the sheet pushes edited rows

In the Sheet, open Extensions > Apps Script and write the function below. Then add an installable trigger for it (Triggers > Add trigger, event source "From spreadsheet", type "On edit"). Installable, not a simple trigger: simple triggers cannot call services that need authorization, and UrlFetchApp does. The edit event carries a range pointing at the edited cells (trigger guide). The function reads the edited row and POSTs it:

function onEditPush(e) {
  if (!e.range) return;
  const sheet = e.range.getSheet();
  if (sheet.getName() !== 'Appointments') return;
  const first = e.range.getRow();
  const last = e.range.getLastRow();
  const values = sheet.getRange(first, 1, last - first + 1, sheet.getLastColumn()).getValues();
  for (let i = 0; i < values.length; i++) {
    UrlFetchApp.fetch('https://YOUR-N8N/webhook/sheet-row', {
      method: 'post',
      contentType: 'application/json',
      payload: JSON.stringify({ sheet: sheet.getName(), row_number: first + i, values: values[i] }),
      muteHttpExceptions: true
    });
  }
}

One edit event can cover many rows: pasting a block or dragging the fill handle fires a single event whose range spans every touched row, and reading only getRow() would push just the top one while the rest wait for the reconcile. So the function reads the whole block with one getValues call and pushes every row in it.

The installable trigger needs a one-time authorization by someone who can own the sheet. For a shared scheduling sheet that is a feature: the manager authorizes their own sheet, and no service account of yours ever holds it.

Note what the payload carries for diagnostics only: the row number. Row numbers shift the moment anyone sorts, inserts, or deletes. Identity lives elsewhere.

Piece 2: n8n upserts keyed on a stable ID

On the n8n side: a Webhook node (POST, response mode "Using Respond to Webhook node"), a code node that zips the values array against a known header and upserts into workflow static data, keyed on the ID column:

const HEADER = ['appointment_id', 'starts_at', 'status', 'revenue_eur', 'source'];
const payload = $json.body || $json;
if (!Array.isArray(payload.values)) {
  return [{ json: { invalid: true, reason: 'expected values array' } }];
}
const row = {};
HEADER.forEach((h, i) => { row[h] = payload.values[i]; });
if (!row.appointment_id) {
  return [{ json: { invalid: true, reason: 'appointment_id missing, sheet row ' + payload.row_number } }];
}
const store = $getWorkflowStaticData('global');
store.rows = store.rows || {};
store.rows[row.appointment_id] = { ...row, pushed_at: new Date().toISOString() };
return [{ json: { upserted: row.appointment_id, store_size: Object.keys(store.rows).length } }];

An IF on invalid routes to the pattern every workflow in my pack uses: write the row to an error log with the reason, answer 422 through a Respond to Webhook node. The caller here is a script with muteHttpExceptions, so its failures are silent by construction, which is exactly why the rejected-request log on the n8n side matters.

The upsert is idempotent. Two rapid edits to the same row fire two POSTs, the second overwrites the first, and that matches the sheet's own last-write-wins editing behavior. No conflict machinery needed.

Piece 3: a nightly reconcile heals drift

Pushes get lost. Someone edits while the webhook is down. A row is deleted, and deleting a row fires no onEdit at all; structural changes fire the onChange trigger instead. So once a night, read only the key column through the gviz endpoint with SELECT A, flatten the gviz envelope (its rows sit under table.rows, not at the top level) into {key} items, and compare:

const sheetKeys = $input.all()
  .map((i) => String(i.json.key))
  .filter((k) => k && k !== 'undefined');
const sheetSet = new Set(sheetKeys);
const store = $getWorkflowStaticData('global');
const storeKeys = Object.keys(store.rows || {});
const removed = storeKeys.filter((k) => !sheetSet.has(k));
for (const k of removed) delete store.rows[k];
const neverPushed = sheetKeys.filter((k) => !store.rows[k]);
return [{ json: {
  sheet_rows: sheetKeys.length, store_rows: Object.keys(store.rows).length,
  removed_missing_from_sheet: removed.length, never_pushed: neverPushed.length
} }];

Two details keep the compare honest at the 50,000-row scale. Membership checks go through a Set built once, because includes inside a filter is quadratic and both sides can be large. And empty keys are filtered out before anything else: a sheet with trailing blank rows returns them as empty strings, and without the filter every blank line counts as never_pushed forever, which reads as drift when it is just whitespace.

never_pushed is the drift signal. If it sits above zero night after night, the push trigger is missing edits, and you want to know that instead of absorbing it.

Night after night is the operative phrase, and it needs the keys, not just the count. The reconcile keeps a health row beside the keyed writes: today's date, the counts, and yesterday's never_pushed key list. The alarm is the intersection, so a row that lands after the push stays quiet on its first night while a trigger that stopped firing pages on the second:

const today = new Date().toISOString().slice(0, 10);
const last = (store.health && store.health.never_pushed) || [];
store.health = { date: today, sheet_rows: sheetKeys.length,
  never_pushed: neverPushed };
const lastSet = new Set(last);
const pageNow = neverPushed.filter((k) => lastSet.has(k));
// page only when pageNow.length > 0

The date in that row carries its own signal: a missing date means the nightly job did not run at all, while a present date with never_pushed: 0 means it ran and the sheet and the store agreed. In Apps Script the same list fits in a script property or one hidden sheet row.

onChange tells you what, not where

Google also offers an installable onChange trigger whose event carries a changeType like INSERT_ROW, REMOVE_ROW or INSERT_COLUMN (event reference). It tells you what kind of change happened, not where it happened, so it cannot drive an upsert. Its correct job is firing the reconcile early: someone inserting or deleting rows is exactly when the store is most likely to drift.

Why not two-way sync

Two-way sync needs conflict resolution: two writers, one row, no natural winner without timestamps you trust and rules for who breaks ties. Last-write-wins on both sides loses data quietly. The push design keeps the sheet as the single source of truth and n8n as a projection you can rebuild at any time: delete the static data, run the reconcile, and the store comes back from the sheet. A projection you can rebuild beats a replica you have to repair.

Where this ships

The appointment pack I sell (€29, Afspraakpack for n8n) reads appointment rows on schedules and webhooks, and treats its source with the same discipline: validation with field-level reasons, keyed writes into static data, error logs, 422 responders. All seven workflows run on demo data out of the box, and the README names the Sheet nodes you replace with your own source. The reminder flagship is here, the silent-failure patterns that pair with this design are here, and the weekly digest that reads a week of rows into one report is here. The free calculators for the scheduling side live at no-show cost, waitlist fill-rate and AI workflow cost.

The sheet is edited by humans all day. Let it tell you what changed instead of asking it everything on every run.

Make your n8n workflows prove they did their job: six patterns for silent failures

vlotstroom — Wed, 21 Oct 2026 12:46:42 +0000

A green execution in n8n means the nodes ran. It does not mean any work happened. Three failure shapes stay perfectly green: the source returned zero rows, every row got filtered out somewhere in the middle, or the workflow fired twice and sent the same message twice. Nobody clicks anything in a scheduled workflow, so nobody notices until a customer does.

I maintain a pack of seven n8n workflows for salons and clinics. Reminder bands, waitlist backfill, fee recovery, a weekly KPI digest. Six of them message a real customer's phone on a schedule, so a silent failure is not an inconvenience, it is a missed appointment or a double message. These are the six patterns that came out of hardening them. They are small, they cost nothing, and each one turns one silent failure into a visible row.

1. Validate rows where they enter, and carry the reason

The first Code node in most of my workflows does not transform anything. It validates. Every row gets two extra fields, row_valid and row_error, and the error says exactly what is wrong:

const items = $input.all();
const out = [];
for (const item of items) {
  const r = item.json;
  let rowError = null;
  if (!r.appointment_id) rowError = 'appointment_id missing';
  else if (!r.starts_at || isNaN(new Date(r.starts_at).getTime())) rowError = 'starts_at not parseable';
  else if (r.revenue_eur !== undefined && isNaN(Number(r.revenue_eur))) rowError = 'revenue_eur not numeric';
  out.push({ json: { ...r, row_valid: !rowError, row_error: rowError } });
}
return out;

The next node is an IF on row_valid. Valid rows continue. Invalid rows go to a dedicated log node that emits {error, appointment_id, reason, seen_at} and, in production, writes to an errors sheet. The point is the reason. "6 rows rejected" teaches you nothing at 2 AM. "starts_at not parseable on APT-2002" fixes itself.

2. Zero items stops an IF chain without telling you

An IF node evaluates per item. If the node before it returns zero items, there is nothing to evaluate, and the flow just stops there. Green. No branch taken, no error, no output. If your source is a sheet somebody renamed, this is how your automation dies for a week.

The fix is a sentinel. My digest workflow's prepare node ends with:

if (out.length === 0) {
  out.push({ json: { empty_week: true, row_valid: true } });
}
return out;

Now the empty case is a real item that flows into real branches instead of evaporating.

3. "Nothing this week" is a message, not an absence

Once the sentinel exists, give it its own branch. My weekly digest has a Digest: empty week node that skips the aggregation entirely and sends the owner one honest line: no completed appointments found this week, check that the source is filled. No ratios are computed, so no division by zero, and the owner learns the pipeline is alive precisely because it said "nothing".

That is the heartbeat idea. A weekly report that only exists when there is data teaches you nothing about the weeks when the data quietly stopped. A report that always arrives, even to say "empty", proves the whole chain ran. The same workflow guards this with a once-per-week send log, so the heartbeat itself cannot double-fire.

4. A send log in staticData, keyed by the thing you want once

Double sends come from double triggers: a manual rerun, a webhook retry, two overlapping schedules. The guard is a log in workflow staticData, keyed by a natural key, checked before anything is sent:

// Once-per-key send log, in workflow staticData.
const staticData = $getWorkflowStaticData('global');
staticData.sendLog = staticData.sendLog || {};
const KEEP_MS = 8 * 7 * 24 * 3600 * 1000; // keep 8 weeks of keys
const out = [];
for (const item of $input.all()) {
  const key = item.json.appointment_id + ':' + item.json.stage;
  const alreadySent = staticData.sendLog[key] !== undefined;
  if (!alreadySent) staticData.sendLog[key] = Date.now();
  out.push({ json: { ...item.json, send_key: key, already_sent: alreadySent } });
}
for (const k of Object.keys(staticData.sendLog)) {
  if (Date.now() - staticData.sendLog[k] > KEEP_MS) delete staticData.sendLog[k];
}
return out;

Then an IF on already_sent splits fresh from repeated. Two details matter. Key it on the natural identity, appointment_id plus stage in my reminders, the plain week in the digest, the normalized phone number in booking intake, never the row position. And prune it, or the log grows forever. My intake workflow uses the same pattern as a 30-minute duplicate guard: a repeated POST from a double-clicked form gets the same 200 answer as the first one, marked duplicate_ignored, instead of a second booking.

5. Skip arms write rows too

Every filter branch deserves a terminal that says what happened. Rows outside the send window in my rescue workflow land in a Skip (not due) node that emits {skipped: true, appointment_id, minutes_until, skipped_at}. In production that feeds a log, so at any moment you can count how many rows flowed, how many were skipped and why, and how many were sent. The failure mode this kills is specific and common: a window gate that is too narrow silently filters everything, the workflow stays green, and the only symptom is that nobody got messaged. With skip rows, that condition shows up as a one-glance count.

6. Reply with the right status code

If a webhook workflow answers errors with HTTP 200 and an error message in the body, every caller learns to ignore failures. My intake and reply workflows each carry a Respond invalid node wired to a real 422, with the field-level reasons in the body. The caller's own monitoring sees the failure. The errors also land in a rejected-request log first, so a form that keeps sending one broken field is visible on my side too, not just the caller's.

Test the gates both ways

The last pattern is a test habit, not a node. Gate logic fails in the direction your tests never look at. The worst bug my first harness missed: a send-window IF built by cloning an existing condition, so both bounds ended up gte. gte 20 and gte 30 together let everything through, and every row escalated. The harness fed hours_ago directly, so it never exercised the arithmetic or the operators. The fix in my builders and tests:

push one real timestamp, three hours old, through the prepare node and assert the result is about 3.0
assert window operators literally, gte on the low bound and lte on the high
leak checks both ways: the row that must be filtered never appears past the gate, and the row that must pass does

Feed gates real time values, never precomputed ones, or the test skips exactly the line that converts them.

Where these ship

All six patterns run in every workflow of the appointment pack I sell (€29, Afspraakpack for n8n): validation gates with Dutch error logs, empty-week heartbeats, keyed send logs, skip arms, 422 responders, and the test harnesses that leak-check both directions. The reminders flagship is here, the weekly digest that puts the heartbeat idea into a Monday report is here, and the companion piece on measuring what your AI workflows cost, with its ledger pattern, is here. The push-sync design that keeps a live-edited Google Sheet fresh without re-downloading it every run is here. The free calculators for the scheduling side live at no-show cost, waitlist fill-rate and AI workflow cost.

A green run is a claim. These patterns are how the workflow backs it up.

Measure what your n8n AI workflows cost: arithmetic, a ledger pattern, and a free calculator

vlotstroom — Wed, 21 Oct 2026 04:47:32 +0000

Scheduled workflows are the quiet ones. Nobody clicks anything, so nobody watches them, and every day they make a few model calls with prices attached. The bill lands a month later and the only question left is "which of these did that?". This post answers it with arithmetic you can check, a small ledger pattern for per-workflow attribution, and a free calculator that runs the math in your browser.

I maintain a pack of n8n workflows for salons and clinics, and the same confusion keeps showing up in automation threads: people see AI spend going up and start guessing at the cause. Measure first. Here is the full method.

Two meters run at once

Before any math, split your spend in two, because they have different fixes:

Build-time spend. The in-app assistant you use while wiring nodes. It runs when you debug, not when the workflow runs. A subscription caps this one.
Runtime spend. The AI nodes inside scheduled or webhook-triggered workflows. This one scales with executions, and no subscription changes it.

If most of your bill is meter 1, buy the cap. If it is meter 2, the rest of this article is for you.

The arithmetic

Per run, one AI call costs:

(prompt tokens x price in + completion tokens x price out) / 1,000,000

So for a whole workflow:

cost per run   = AI calls per run x the line above + other metered cost per run
cost per month = runs per day x 30 x cost per run

Three multipliers decide the outcome: how often the workflow fires, how many tokens each call moves, and which model you picked. Rough public list prices per 1M tokens, the same defaults my calculator ships with (edit them to what you actually pay):

Model	Price in	Price out
GPT-4o	$2.50	$10.00
GPT-4o mini	$0.15	$0.60
Claude Sonnet	$3.00	$15.00
Gemini Flash	$0.10	$0.40

Example A: a daily digest

Three AI calls per run (summarize, classify, format), one run per day, 2,000 prompt tokens and 500 completion tokens per call.

Model	Per run	Per month	Per year
GPT-4o	$0.0300	$0.90	$10.80
GPT-4o mini	$0.0018	$0.05	$0.65

Same workload, 16.7x the price, because the model multiplier compounds across every call. A dollar a month is not a problem. This example exists as the baseline.

Example B: reply triage every 15 minutes

One AI call per run, 800 prompt tokens, 120 completion tokens, 96 runs per day. This is the shape that surprises people.

Model	Per run	Per day	Per month	Per year
Claude Sonnet	$0.0042	$0.40	$12.10	$145.15
GPT-4o mini	$0.000192	$0.0184	$0.55	$6.64
Gemini Flash	$0.000128	$0.0123	$0.37	$4.42

The per-run numbers look like pocket lint: $0.0042, less than half a cent. The schedule turns them into $145 per year, and the same triage on a small model costs $6.64. That 21.9x gap (32.8x against Flash) is the entire business case for per-workflow cost attribution: you cannot right-size what you never measured.

Where the numbers come from

You do not have to estimate token counts. The response carries them. On OpenAI-compatible APIs, the chat completion includes a usage object with prompt_tokens, completion_tokens and total_tokens (this is in OpenAI's published API spec, and the other vendors mirror the shape). Most model nodes in n8n surface that usage in the item's output when you use raw or JSON output mode. Check one execution of your own node before wiring anything below.

The nine-line ledger

Put this Code node after each AI step. It turns every response into a priced ledger row:

// Cost ledger: one row per AI item. Prices are USD per 1M tokens.
const PRICES = {
  'gpt-4o': [2.50, 10.00],
  'gpt-4o-mini': [0.15, 0.60],
};
const out = [];
for (const item of $input.all()) {
  const u = item.json.usage ?? {};
  const model = String(item.json.model ?? 'unknown');
  const [pin, pout] = PRICES[model] ?? [0, 0];
  out.push({ json: {
    workflow: $workflow.name,
    model,
    prompt_tokens: u.prompt_tokens ?? 0,
    completion_tokens: u.completion_tokens ?? 0,
    cost_usd: Number((((u.prompt_tokens ?? 0) * pin
      + (u.completion_tokens ?? 0) * pout) / 1e6).toFixed(6)),
    day: new Date().toISOString().slice(0, 10),
  }});
}
return out;

Feed the rows into a Google Sheets node or Postgres and after one day you know which workflow eats the budget, down to the step. If you do not want an external store, keep a running total in workflow staticData instead; getWorkflowStaticData('global') persists between production executions, which is the same mechanism my own workflows use for their send logs and dedup guards.

The classic silent multipliers this ledger will surface:

a retry loop re-running a large prompt on every failure
context bloat from re-sending the whole conversation each turn
a frontier model doing classification a small model does fine

The fix for the last one is boring: route one repeated step to a smaller model for a day and compare the rows.

The calculator

If you want the totals before building the ledger, I made a free tool for exactly this: the n8n AI workflow cost calculator. You list your workflows (calls per run, tokens, model, runs per day, any other metered cost), edit the model prices to your real ones, and it shows cost per run, per month and per year for each workflow plus a total, an AI-versus-other split, and the biggest spender. It runs entirely in your browser, has an English and a Dutch mode, and sends nothing anywhere.

I also have a no-show cost calculator and a waitlist fill-rate calculator for the scheduling side of the same house.

What to do with the numbers

Right-size per step, not per stack. Classification and routing almost never need the big model. Keep the frontier model where the output quality is the product, and put the small model on the high-frequency steps.
Cap the retries. An unbounded retry loop multiplies the cost of a failing step until it succeeds or you notice. Bound it and log the failures.
Trim what you re-send. If each turn re-sends the full history, the prompt grows linearly with the conversation. Send the summary, not the transcript, unless the step truly needs it.

One honest note from my own shop: the workflow pack I sell (€29, Afspraakpack for n8n) deliberately ships without AI nodes, so it adds zero runtime model spend. The cost methods above are for the AI workflows you build yourself. The reminders article that covers the pack's flagship is here, and the weekly KPI digest pattern that gives you a per-workflow measurement habit every Monday is here.

Measure, then switch. The other order just moves the surprise to next month's invoice.

The sibling question is whether the workflows did their job at all: Make your n8n workflows prove they did their job covers validation gates, empty-input sentinels and keyed send logs. Once the cost side is measured, the revenue side has its own post: How to price n8n client work turns two years of practitioner answers into build hours, a monthly retainer and pass-through rules.

Pipedream Workflows shuts down in March 2027: a migration map to n8n

vlotstroom — Sun, 18 Oct 2026 04:49:10 +0000

Pipedream is shutting down Workflows, and String with it, on March 31, 2027. Existing
workflows keep running until that date, but the product is in maintenance mode: no new
signups, no new subscriptions, no new features. After April 30, 2027 the data is gone,
including the tokens for your connected accounts. Those dates come from Pipedream's own
shutdown page, and they set the real deadline: you need to rebuild somewhere, and the
export you will want to work from stops existing five months after the lights go out.

I build customer-operations automations in n8n for small salons and clinics. This post
is the migration map I would want if my workflows lived in Pipedream today: what the
export actually gives you, which Pipedream concept maps to which n8n one, and three
tested n8n starting points for the patterns most business workflows boil down to.

What the export actually gives you

The n8n community has a thread worth reading first: Moving off Pipedream Workflows
before 31 March 2027. Its author went through 103
public Pipedream workflows to see what the move involves. Two findings matter:

The export is a JSON record per workflow. Nothing imports it directly, n8n included.
An open-source converter exists: davobene/migrateflows. It takes a project export or a GitHub Sync folder and outputs n8n workflow JSON plus a checklist per workflow.

That covers triggers and app steps reasonably well. The parts a converter cannot finish
for you are the same parts that break in production: code steps that read credentials,
and any logic that depends on saved state. Those need your judgment, so here is the map.

The concept map

Pipedream	n8n	What to watch out for
HTTP trigger (webhook URL)	Webhook node	The production URL registers when you activate the workflow. If the caller needs an answer, the flow has to end in a reachable Respond to Webhook node, or the caller hangs until timeout.
Cron / timer trigger	Schedule Trigger	Set odd minutes. If a dozen workflows all fire at :00, they will fight for the same database rows and API rate limits on every run.
Code steps reading `this.<app>.$auth`	HTTP Request node with stored credentials	Keep tokens out of code. The community thread flags exactly this case: code steps that pull the OAuth token or API key and pass it to axios are the ones that need a manual rewrite.
Step state (`$checkpoint`)	`getWorkflowStaticData()`	Fine for simple keys. It is last-write-wins across concurrent executions, so it breaks precisely when runs overlap. For anything that deduplicates, use a database with a unique constraint.
Early return (`$end()`)	IF node, respond node	Split the flow and give every arm an explicit ending. Dead ends are invisible until a caller times out.

The state row deserves the most respect, because it fails silently. n8n schedule
triggers do not wait for the previous execution to finish. A slow API call plus a tight
poll interval stacks executions, and two runs can both read the same window, both
conclude they are first, and both send. If double-sending matters, make the insert the
lock: a unique index on your incident or message key, insert with on-conflict-do-nothing,
and only fire the notification when the insert actually returned a row. I wrote more
about that pattern in part 1 of this series,
where the reminder workflow keeps a send log keyed by appointment and stage for exactly
this reason.

Don't port node for node

A migration is cheaper when you port patterns instead of nodes. Most Pipedream business
workflows I have seen reduce to three customer-ops patterns, and tested n8n versions of
all three are free in the official template library. Full disclosure: I maintain them.
Each one ships with demo data, runs without credentials, and marks the nodes you replace
with your own accounts.

1. Reminder blasts become staged reminders with reply handling

If your Pipedream workflow was a cron trigger, a sheet read, and a send step, the n8n
upgrade is Cut appointment no-shows with staged reminders, reply triage and waitlist
backfill.
Every six hours it picks the right reminder stage per appointment instead of blasting
everyone the same message. A send log prevents repeats. A reply webhook classifies
answers: confirmations update the row, cancellations rank the waitlist for the freed
slot and offer it to the top candidates automatically. The step I always had to hand-build
in Pipedream, deciding what a customer meant by their one-word SMS answer, is a single
classify node here.

2. Fee chasing becomes an escalation ladder with a stop condition

Chasing a missed payment is a schedule, some history, and a send step, until it re-sends
forever and the customer stops reading. The n8n version is Recover no-show appointment
fees with an automated WhatsApp or SMS
ladder.
It runs every 12 hours, validates each row first (broken rows land in a log instead of
the send queue), only escalates inside a time window, picks the tone by payment history,
and a payment reply webhook classifies confirmations and disputes. A confirmation or a
dispute closes the ladder. The stop condition is the entire value of the pattern; without
it you have built a nuisance machine.

3. Waitlist handling becomes ranked offers with a claim guard

The third pattern: something cancels, someone on a list wants the slot. The n8n version
is Fill cancelled booking slots from a ranked waitlist using webhooks and
SMS/WhatsApp.
A cancellation webhook normalizes the event, ranks the waitlist, and offers the slot to
the top candidates at once. The first TAKE reply wins, enforced by a claim guard, and a
sweeper runs every 30 minutes to re-offer slots whose offers expired without an answer.
Over-offering on purpose plus a hard claim guard is much faster than offering one person
at a time and waiting a day for silence.

The cutover checklist

Export everything now. The shutdown page promises six months to migrate, and the data deletion follows on April 30, 2027. Export while the tokens for connected accounts still exist; you will want them for reference when you rebuild authentications on the n8n side.
Put your own domain in front of the new webhooks. Every caller has to be updated anyway, so point them at hooks.yourdomain.com and proxy that to n8n. The next time you move platforms, it is a DNS change instead of another hunt through every caller.
Inventory credential-reading code steps. Anything pulling this.<app>.$auth into an axios call becomes an HTTP Request node with stored credentials. Do this while the old workflow is still running, so you can compare responses side by side.
Replace step state deliberately. Simple flags go to workflow static data. Anything that deduplicates goes to a database with a unique constraint, for the concurrency reason above.
Stagger the schedules. Odd minutes, and spread your workflows across them.
Dual-run for a week. Keep the Pipedream version sending to a test destination and the n8n version sending to another, compare the logs per day, then cut over one workflow at a time. Migrating all of them in one evening is how a subtle timezone bug reaches every customer on day one.
Turn on error notifications before you need them. The failure mode that hurts after a migration is the silent one: a token expires in week two and the workflow errors on every run while nobody looks. Point an error workflow at something you read daily.

Why do this now instead of in March

Every other Pipedream Workflows user is on the same clock, and the ones who build for
a living will book their capacity early. The quiet weeks you have now are the cheap
weeks. The export takes minutes, the converter takes an afternoon, and the dual-run
week is mostly waiting. Starting in February converts all of that into a crunch with
a hard deadline attached.

If you migrate one of the three patterns above, the library templates are the fastest
starting point I know of, because the fiddly parts (send logs, reply classification,
claim guards, windows) are already wired and tested. My earlier posts walk through the
same loop pattern by pattern: reminders,
waitlist backfill,
fee recovery,
follow-ups,
and a weekly KPI digest.

Disclosure: I maintain the three free library templates linked above, and I sell a
paid pack of seven workflows for salons and
clinics that extends the same patterns. If you want the numbers first, there are free
calculators for no-show cost,
waitlist fill rate and
AI workflow cost, with the full arithmetic in
Measure what your n8n AI workflows cost.

Summarize weekly appointment KPIs into a Monday digest: an n8n workflow (JSON included)

vlotstroom — Mon, 05 Oct 2026 04:54:24 +0000

I build n8n automations for small salons and clinics. The series so far
covered preventing no-shows, refilling cancelled slots, recovering fees,
and turning finished visits into reviews and rebookings. This build is
the one that tells you whether any of that worked: a Monday morning
digest with last week's real numbers, one message, no dashboard. Complete
workflow JSON at the end, runs on n8n alone.

The loop nobody measures

Here is the honest failure mode of automation projects: the reminders
ship, the waitlist fires, everyone feels busier, and nobody can say
whether the no-show rate moved. The numbers live in a booking tool
behind four clicks, so nobody looks. Six weeks later the workflows are
still running on faith.

The fix costs one message a week. Every Monday at 08:00, before the
first customer walks in, the owner reads: how many appointments, what
share showed up, no-show rate, cancellations, revenue, and which booking
source brought in the most completed visits. Ten seconds of reading,
and every other workflow in the loop becomes measurable.

What the digest says

One text block, built for a phone screen:

Week of 2026-09-28: 4/6 kept (67%, up 4 pts vs last week), 1 no-shows
(17%), revenue EUR 230 (EUR +40 vs last week). Top source: repeat (3).

The deltas are the part that does the work. A raw number needs a
baseline to mean anything; "up 4 pts" is an answer, "67%" is a lookup.
The workflow computes both weeks from the same rows, so the comparison
is always apples to apples.

Bad rows must not skew the numbers

A KPI digest that divides by garbage is worse than no digest, because
it looks authoritative. The workflow validates every row before it
counts: starts_at must parse, status must be one of
completed, no_show, cancelled, revenue_eur must be numeric.
Rows that fail carry an exact reason (unknown status: noshow) and
route to an error log branch instead of the aggregation. In production
that branch writes to a kpi_errors sheet; you fix the source once and
the digest self-corrects.

The empty-week trap

The subtle one. n8n IF nodes evaluate per item. If the source returns
zero rows one Monday (sheet moved, filter too narrow), an IF downstream
never fires and the flow stops silently. No digest, no error, nothing.
You would discover it weeks later.

The validation node handles this with a sentinel: when zero items come
in, it emits one { empty_week: true } item. The empty-week branch then
sends an honest line instead of silence:

No completed appointment data found for this week. Check that the
source sheet filled correctly.

Silent failure converted into a self-reporting failure. That is the
whole trick, and it applies to any scheduled n8n workflow you run.

The aggregation code

Both weeks from one pass over the rows:

const items = $input.all();
const weekMs = 7 * 24 * 3600 * 1000;
const now = Date.now();
function agg(rows) {
  const total = rows.length;
  const completed = rows.filter((i) => i.json.status === 'completed').length;
  const noShow = rows.filter((i) => i.json.status === 'no_show').length;
  const cancelled = rows.filter((i) => i.json.status === 'cancelled').length;
  const revenue = rows.reduce((sum, i) => sum + (i.json.revenue_eur || 0), 0);
  const sources = {};
  for (const i of rows) {
    if (i.json.status !== 'completed') continue;
    sources[i.json.source || 'unknown'] = (sources[i.json.source || 'unknown'] || 0) + 1;
  }
  const top = Object.entries(sources).sort((a, b) => b[1] - a[1])[0];
  return {
    total: total, completed: completed, no_shows: noShow, cancelled: cancelled,
    revenue_eur: revenue,
    show_up_rate_pct: total ? Math.round((completed / total) * 100) : 0,
    no_show_rate_pct: total ? Math.round((noShow / total) * 100) : 0,
    top_source: top ? top[0] + ' (' + top[1] + ')' : 'none'
  };
}
const thisWeek = agg(items.filter((i) => i.json.starts_ts > now - weekMs));
const lastWeek = agg(items.filter((i) => i.json.starts_ts <= now - weekMs && i.json.starts_ts > now - 2 * weekMs));
return [{ json: { week_of: new Date(now - weekMs).toISOString().slice(0, 10), ...thisWeek, prev: lastWeek } }];

Two details worth copying. The top-source ranking counts only completed
visits, because a source that books customers who never show up should
not win the ranking. And the previous week comes from the same rows,
split by timestamp, so you never need a second source or a stored
snapshot to say "vs last week".

Test it without sending anything

The JSON below has demo rows wired in. Import it into n8n, open the
demo source node, execute, and read the digest text in the send node's
output. No message leaves: the send node is a placeholder by design,
stamped delivered: 'demo'.

The complete workflow JSON

Import into n8n (Workflows, Import from File), disable the demo node,
and point the first code node at your Google Sheet of appointment rows.
Required columns: appointment_id, starts_at (ISO), status
(completed, no_show, or cancelled), revenue_eur, source. Put
your delivery node (Gmail, WhatsApp to yourself, Slack) in place of the
placeholder:

{
  "name": "Summarize weekly appointment KPIs into a Monday digest",
  "nodes": [
    {
      "parameters": {
        "rule": {
          "interval": [
            {
              "field": "weeks",
              "weeksInterval": 1,
              "triggerAtDay": [
                1
              ],
              "triggerAtHour": 8
            }
          ]
        }
      },
      "id": "91000000-0000-4000-8000-000000000001",
      "name": "Mondays 08:00",
      "type": "n8n-nodes-base.scheduleTrigger",
      "typeVersion": 1.2,
      "position": [
        -280,
        0
      ]
    },
    {
      "parameters": {
        "jsCode": "// DEMO SOURCE so the template runs immediately. For production,\n// disable this node and read last week's rows from Google Sheets.\n// Required columns: appointment_id, starts_at (ISO), status\n// (completed|no_show|cancelled), revenue_eur, source\nconst demoRows = [\n  { appointment_id: 'APT-5001', starts_at: new Date(Date.now() - 2 * 24 * 3600 * 1000).toISOString(), status: 'completed', revenue_eur: 65, source: 'repeat' },\n  { appointment_id: 'APT-5002', starts_at: new Date(Date.now() - 3 * 24 * 3600 * 1000).toISOString(), status: 'no_show', revenue_eur: 0, source: 'walkin' },\n  { appointment_id: 'APT-5003', starts_at: new Date(Date.now() - 4 * 24 * 3600 * 1000).toISOString(), status: 'completed', revenue_eur: 120, source: 'instagram' },\n  { appointment_id: 'APT-5004', starts_at: new Date(Date.now() - 5 * 24 * 3600 * 1000).toISOString(), status: 'cancelled', revenue_eur: 0, source: 'repeat' },\n  { appointment_id: 'APT-5005', starts_at: new Date(Date.now() - 6 * 24 * 3600 * 1000).toISOString(), status: 'completed', revenue_eur: 45, source: 'repeat' },\n  { appointment_id: 'APT-5006', starts_at: new Date(Date.now() - 6 * 24 * 3600 * 1000).toISOString(), status: 'completed', revenue_eur: 85, source: 'waitlist' }\n];\nreturn demoRows.map((row) => ({ json: row }));"
      },
      "id": "91000000-0000-4000-8000-000000000002",
      "name": "Last week's rows (demo data)",
      "type": "n8n-nodes-base.code",
      "typeVersion": 2,
      "position": [
        -60,
        0
      ]
    },
    {
      "parameters": {
        "jsCode": "// Validate each row before aggregation: a broken status or a non-numeric\n// revenue would silently skew the KPIs. Exact reasons are attached and bad\n// rows are routed to the error log. If the source returns nothing at all,\n// one sentinel item is emitted so the empty-week branch can fire (an IF\n// node evaluates per item, and zero items would stop the flow silently).\nconst items = $input.all();\nconst out = [];\nconst STATUSES = ['completed', 'no_show', 'cancelled'];\nfor (const item of items) {\n  const r = item.json;\n  const t = r.starts_at ? new Date(r.starts_at).getTime() : NaN;\n  let rowError = null;\n  if (!r.appointment_id) rowError = 'missing appointment_id';\n  else if (isNaN(t)) rowError = 'starts_at not parseable';\n  else if (r.status && !STATUSES.includes(r.status)) rowError = 'unknown status: ' + r.status;\n  else if (r.revenue_eur !== undefined && isNaN(Number(r.revenue_eur))) rowError = 'revenue_eur not numeric';\n  out.push({\n    json: {\n      ...r,\n      revenue_eur: r.revenue_eur === undefined ? undefined : Number(r.revenue_eur),\n      starts_ts: isNaN(t) ? null : t,\n      row_valid: !rowError,\n      row_error: rowError\n    }\n  });\n}\nif (out.length === 0) {\n  out.push({ json: { empty_week: true, row_valid: true } });\n}\nreturn out;"
      },
      "id": "dddd0000-0000-4000-8000-000000000201",
      "name": "Prepare + validate rows",
      "type": "n8n-nodes-base.code",
      "typeVersion": 2,
      "position": [
        140,
        0
      ]
    },
    {
      "parameters": {
        "conditions": {
          "options": {
            "caseSensitive": true,
            "leftValue": "",
            "typeValidation": "strict",
            "version": 2
          },
          "conditions": [
            {
              "id": "c1",
              "leftValue": "={{ $json.row_valid }}",
              "rightValue": true,
              "operator": {
                "type": "boolean",
                "operation": "true"
              }
            }
          ],
          "combinator": "and"
        },
        "options": {}
      },
      "id": "dddd0000-0000-4000-8000-000000000202",
      "name": "Row valid?",
      "type": "n8n-nodes-base.if",
      "typeVersion": 2.2,
      "position": [
        360,
        0
      ]
    },
    {
      "parameters": {
        "jsCode": "// Error path for source-data problems: exact reason per row. In production,\n// write to a 'kpi_errors' sheet; the digest then runs on clean rows only.\nconst items = $input.all();\nreturn items.map((item) => ({\n  json: {\n    error: 'invalid KPI row',\n    appointment_id: item.json.appointment_id || null,\n    reason: item.json.row_error || 'unknown',\n    seen_at: new Date().toISOString()\n  }\n}));"
      },
      "id": "dddd0000-0000-4000-8000-000000000203",
      "name": "Log invalid rows",
      "type": "n8n-nodes-base.code",
      "typeVersion": 2,
      "position": [
        360,
        220
      ]
    },
    {
      "parameters": {
        "conditions": {
          "options": {
            "caseSensitive": true,
            "leftValue": "",
            "typeValidation": "strict",
            "version": 2
          },
          "conditions": [
            {
              "id": "e1",
              "leftValue": "={{ $json.empty_week }}",
              "rightValue": false,
              "operator": {
                "type": "boolean",
                "operation": "false"
              }
            }
          ],
          "combinator": "and"
        },
        "options": {}
      },
      "id": "dddd0000-0000-4000-8000-000000000205",
      "name": "Any rows?",
      "type": "n8n-nodes-base.if",
      "typeVersion": 2.2,
      "position": [
        580,
        0
      ]
    },
    {
      "parameters": {
        "jsCode": "// Quiet-week branch: no valid rows made it through, so no ratios are\n// computed (no divide-by-zero) and the owner still gets one honest line.\nreturn [{ json: {\n  week_of: new Date(Date.now() - 7 * 24 * 3600 * 1000).toISOString().slice(0, 10),\n  digest: 'No completed appointment data found for this week. Check that the source sheet filled correctly.'\n} }];"
      },
      "id": "dddd0000-0000-4000-8000-000000000206",
      "name": "Digest: empty week",
      "type": "n8n-nodes-base.code",
      "typeVersion": 2,
      "position": [
        800,
        -100
      ]
    },
    {
      "parameters": {
        "jsCode": "// Compare this week against last week so the digest says something useful\n// on quiet weeks too: deltas on show-up rate and revenue.\nconst w = $input.first().json;\nconst p = w.prev || {};\nconst dShow = w.show_up_rate_pct - (p.show_up_rate_pct || 0);\nconst dRev = w.revenue_eur - (p.revenue_eur || 0);\nconst dir = dShow >= 0 ? 'up' : 'down';\nconst digest = 'Week of ' + w.week_of + ': ' + w.completed + '/' + w.total + ' kept (' + w.show_up_rate_pct + '%, ' + dir + ' ' + Math.abs(dShow) + ' pts vs last week), ' + w.no_shows + ' no-shows (' + w.no_show_rate_pct + '%), revenue EUR ' + w.revenue_eur + ' (EUR ' + (dRev >= 0 ? '+' : '') + dRev + ' vs last week). Top source: ' + w.top_source + '.';\nreturn [{ json: { ...w, delta_show_up_pts: dShow, delta_revenue_eur: dRev, digest } }];"
      },
      "id": "dddd0000-0000-4000-8000-000000000204",
      "name": "Trend vs last week",
      "type": "n8n-nodes-base.code",
      "typeVersion": 2,
      "position": [
        1020,
        -100
      ]
    },
    {
      "parameters": {
        "jsCode": "// Aggregate the clean rows into the numbers an owner reads: show-up rate,\n// no-show rate, revenue, top booking source. Also computes the same numbers\n// for the previous week (rows carry starts_ts, so weeks are split by date).\nconst items = $input.all();\nconst weekMs = 7 * 24 * 3600 * 1000;\nconst now = Date.now();\nfunction agg(rows) {\n  const total = rows.length;\n  const completed = rows.filter((i) => i.json.status === 'completed').length;\n  const noShow = rows.filter((i) => i.json.status === 'no_show').length;\n  const cancelled = rows.filter((i) => i.json.status === 'cancelled').length;\n  const revenue = rows.reduce((sum, i) => sum + (i.json.revenue_eur || 0), 0);\n  const sources = {};\n  for (const i of rows) {\n    if (i.json.status !== 'completed') continue;\n    sources[i.json.source || 'unknown'] = (sources[i.json.source || 'unknown'] || 0) + 1;\n  }\n  const top = Object.entries(sources).sort((a, b) => b[1] - a[1])[0];\n  return {\n    total: total, completed: completed, no_shows: noShow, cancelled: cancelled,\n    revenue_eur: revenue,\n    show_up_rate_pct: total ? Math.round((completed / total) * 100) : 0,\n    no_show_rate_pct: total ? Math.round((noShow / total) * 100) : 0,\n    top_source: top ? top[0] + ' (' + top[1] + ')' : 'none'\n  };\n}\nconst thisWeek = agg(items.filter((i) => i.json.starts_ts > now - weekMs));\nconst lastWeek = agg(items.filter((i) => i.json.starts_ts <= now - weekMs && i.json.starts_ts > now - 2 * weekMs));\nreturn [{ json: { week_of: new Date(now - weekMs).toISOString().slice(0, 10), ...thisWeek, prev: lastWeek } }];"
      },
      "id": "91000000-0000-4000-8000-000000000003",
      "name": "Aggregate week",
      "type": "n8n-nodes-base.code",
      "typeVersion": 2,
      "position": [
        800,
        100
      ]
    },
    {
      "parameters": {
        "jsCode": "// Placeholder for the delivery node (Gmail / WhatsApp to the owner /\n// Slack). The digest text is in .digest; the numbers are fields.\nconst item = $input.first().json;\nreturn [{ json: { ...item, delivered: 'demo', digest_subject: 'Weekly numbers - ' + item.week_of } }];"
      },
      "id": "91000000-0000-4000-8000-000000000004",
      "name": "Send digest (replace me)",
      "type": "n8n-nodes-base.code",
      "typeVersion": 2,
      "position": [
        1240,
        -100
      ]
    },
    {
      "parameters": {
        "content": "## Summarize weekly appointment KPIs into a Monday digest\n\n### How it works\n\nEvery Monday at 08:00 the workflow reads last week's appointment rows and aggregates them into the numbers an owner actually reads: total appointments, kept rate, no-show rate, cancellations, revenue, and the booking source that brought in most completed visits. One text block is built for delivery, so a single WhatsApp message, email, or Slack post is enough. Demo data is included, so it runs immediately.\n\n### Setup steps\n\n- Disable the demo node and connect your Google Sheets source. Required columns are listed in that node.\n- Put your delivery node (Gmail, WhatsApp, or Slack) in place of the placeholder send node.\n- Activate the workflow.\n\n### Requirements\n\n- A sheet or other source with one row per appointment: starts_at, status (completed, no_show, or cancelled), revenue, and source.\n\n### Customization\n\nChange the trigger day and hour, the digest text, or the source filter (currently only completed visits count toward the top-source ranking).",
        "width": 600,
        "height": 700
      },
      "id": "cccc0000-0000-4000-8000-0000000000f1",
      "name": "Sticky Note 00f1",
      "type": "n8n-nodes-base.stickyNote",
      "typeVersion": 1,
      "position": [
        -960,
        -200
      ]
    },
    {
      "parameters": {
        "content": "## 1. Read + validate\nMonday 08:00. Demo source stands in for your sheet; a code node parses dates and checks statuses, and an IF gate routes bad rows to an error log.",
        "color": 7,
        "width": 785,
        "height": 560
      },
      "id": "cccc0000-0000-4000-8000-0000000000f2",
      "name": "Sticky Note 00f2",
      "type": "n8n-nodes-base.stickyNote",
      "typeVersion": 1,
      "position": [
        -320,
        -200
      ]
    },
    {
      "parameters": {
        "content": "## 2. Aggregate + trend + send\nValid rows become show-up rate, no-show rate, revenue and top source, compared against the previous week. An empty week skips the ratios; the placeholder send node ships the digest text as-is.",
        "color": 7,
        "width": 965,
        "height": 560
      },
      "id": "cccc0000-0000-4000-8000-0000000000f3",
      "name": "Sticky Note 00f3",
      "type": "n8n-nodes-base.stickyNote",
      "typeVersion": 1,
      "position": [
        505,
        -200
      ]
    }
  ],
  "connections": {
    "Mondays 08:00": {
      "main": [
        [
          {
            "node": "Last week's rows (demo data)",
            "type": "main",
            "index": 0
          }
        ]
      ]
    },
    "Last week's rows (demo data)": {
      "main": [
        [
          {
            "node": "Prepare + validate rows",
            "type": "main",
            "index": 0
          }
        ]
      ]
    },
    "Prepare + validate rows": {
      "main": [
        [
          {
            "node": "Row valid?",
            "type": "main",
            "index": 0
          }
        ]
      ]
    },
    "Row valid?": {
      "main": [
        [
          {
            "node": "Any rows?",
            "type": "main",
            "index": 0
          }
        ],
        [
          {
            "node": "Log invalid rows",
            "type": "main",
            "index": 0
          }
        ]
      ]
    },
    "Any rows?": {
      "main": [
        [
          {
            "node": "Aggregate week",
            "type": "main",
            "index": 0
          }
        ],
        [
          {
            "node": "Digest: empty week",
            "type": "main",
            "index": 0
          }
        ]
      ]
    },
    "Digest: empty week": {
      "main": [
        [
          {
            "node": "Send digest (replace me)",
            "type": "main",
            "index": 0
          }
        ]
      ]
    },
    "Aggregate week": {
      "main": [
        [
          {
            "node": "Trend vs last week",
            "type": "main",
            "index": 0
          }
        ]
      ]
    },
    "Trend vs last week": {
      "main": [
        [
          {
            "node": "Send digest (replace me)",
            "type": "main",
            "index": 0
          }
        ]
      ]
    }
  }
}

Where this fits

This is the fifth full build in the series.
Appointment reminders with a no-double-send guard,
waitlist backfill that fills cancelled slots automatically,
fee recovery with a polite escalation ladder,
and post-visit follow-up for reviews and rebookings
came before. This one closes the loop: prevent, refill, recover, grow,
measure. The Dutch-language versions plus the surrounding pack (booking
intake, no-show rescue) are in one download:
https://vlotstream.gumroad.com/l/rhmxw

Free companion tools

Want the numbers before the workflow? I put the math in free
calculators (EN/NL, no signup, run in your browser):
no-show cost calculator,
waitlist fill-rate calculator and
AI workflow cost calculator. The per-workflow
cost arithmetic and a ledger pattern are in
Measure what your n8n AI workflows cost. The same pack's failure-visibility patterns, from empty-input sentinels to keyed send logs, are in Make your n8n workflows prove they did their job. The design for keeping a live-edited Google Sheet in sync without re-reading it on every run is here.

Turn finished visits into reviews and rebookings: an n8n follow-up workflow, JSON included

vlotstroom — Sun, 04 Oct 2026 04:57:28 +0000

I build n8n automations for small salons and clinics. The series so far
covered preventing no-shows, refilling cancelled slots, and recovering
fees. This build covers what happens after a visit goes well: the
follow-up that turns a good visit into a review or a next booking. It is
the cheapest automation in the whole loop, because every customer it
messages already likes you. Complete workflow JSON at the end, runs on
n8n alone.

The follow-up that never gets sent

Every salon owner knows the playbook: message the customer the day after,
ask a first-timer for a review, nudge a regular to rebook. In practice
the counter is busy, the list lives in someone's head, and the message
goes out for two weeks and then never again. The customers most likely
to come back simply age out of attention.

The fix is boring and effective: a workflow that runs every 12 hours,
picks the visits that ended 20 to 30 hours ago, and sends exactly one
message. First-timers get the review ask. Regulars get a rebooking
nudge with a date computed from their treatment.

Why 20 to 30 hours

Same reasoning as the fee ladder in part three, opposite emotion. A
message the same evening reads as pushy sales. A message a week later
reads as a newsletter. The next morning, roughly 20 to 30 hours after
the visit, the visit is still a fresh good memory and the customer has
a minute to answer. That window is where review replies and BOOK replies
actually happen.

The window also does the usual double duty: it guarantees one message
per visit and keeps each run tiny.

Two messages, one flow

The split is one field: first_visit.

First visit: a short review ask with your review link. One sentence of thanks, one ask, done.
Regular: a rebooking nudge that already contains the suggested date. "Your next haircut is due in about 5 weeks (Friday 13 November). Want to reserve a spot now? Reply BOOK."

The date is the part that does the work. A nudge with a concrete date
is a booking; a nudge without one is a brochure.

The interval map is the real product

The workflow needs to know how often each treatment comes back. That
knowledge usually lives with the senior stylist and nowhere else. The
build puts it in one plain object at the top of the code node:

const INTERVAL_WEEKS = {
  'Hair treatment': 12,
  'Color touch-up': 6,
  'Haircut': 5,
  'Check-up': 6,
  'Default': 8
};

Edit the treatments and weeks to match your own list. Clinics translate
this trivially: check-up intervals and recall periods are exactly this
map. When a treatment is missing, the Default entry catches it, so no
customer silently drops out.

What the workflow does

Seven nodes, one schedule trigger:

Every 12 hours, a trigger fires.
Completed visits are read. Demo rows in the JSON below; swap in your Google Sheet of completed visits.
One code node picks the 20-30 hour window, picks review-ask versus rebook-nudge, computes the date, and builds the message.
A placeholder send node stands in for WhatsApp Business Cloud, SMS, or email.
An If node splits the two kinds.
Two log nodes stamp the outcome: review_sent and rebook_sent, ready to wire into a sheet.

The columns the source needs:

appointment_id, customer_name, phone, visited_at (ISO), treatment, practitioner, first_visit
APT-3001, Anna Voorbeeld, +316****5678, 2026-10-01T09:00:00Z, Hair treatment, Stylist A, false
APT-3002, Tom Voorbeeld, +316****5432, 2026-10-03T08:00:00Z, Haircut, Stylist B, true

The code node that matters

Window, kind, date, and message in one pass:

const items = $input.all();
const now = Date.now();
const out = [];
const INTERVAL_WEEKS = { 'Hair treatment': 12, 'Color touch-up': 6, 'Haircut': 5, 'Check-up': 6, 'Default': 8 };
for (const item of items) {
  const r = item.json;
  const hoursAgo = (now - new Date(r.visited_at).getTime()) / 3600000;
  if (hoursAgo < 20 || hoursAgo > 30) continue;
  const weeks = INTERVAL_WEEKS[r.treatment] || INTERVAL_WEEKS['Default'];
  const rebookDate = new Date(now + weeks * 7 * 24 * 3600 * 1000);
  const rebookStr = rebookDate.toLocaleDateString('en-GB', { weekday: 'long', day: 'numeric', month: 'long' });
  let message;
  if (r.first_visit) {
    message = 'Hi ' + r.customer_name + ', thanks for your first visit! How was it? A review helps us a lot: REVIEWLINK. It takes 1 minute.';
  } else {
    message = 'Hi ' + r.customer_name + ', great to see you again! Your next ' + r.treatment + ' is due in about ' + weeks + ' weeks (' + rebookStr + '). Want to reserve a spot now? Reply BOOK.';
  }
  out.push({
    json: {
      appointment_id: r.appointment_id,
      customer_name: r.customer_name,
      to: r.phone,
      channel: 'whatsapp',
      kind: r.first_visit ? 'review_ask' : 'rebook_nudge',
      rebook_weeks: weeks,
      rebook_date: rebookDate.toISOString(),
      message: message
    }
  });
}
return out;

The continue on the window check keeps every run idempotent: rows
outside the window drop out before a message exists, and rows older
than 30 hours are gone forever, which is correct. You had one morning
to catch that customer and the workflow used it.

Close the loop on BOOK replies

The rebook log node is where the series connects. When a customer
replies BOOK, that reply should land in a booking intake flow with the
suggested slot prefilled, not in an inbox. My booking intake build
(validated webhook, field checks, instant structured responses) is in
the pack linked below; wiring the BOOK reply into its webhook is two
nodes.

Test it without sending anything

The JSON below has demo data wired in. Import it into n8n, open the
demo visits node, and shift visited_at to roughly 26 hours ago (the
demo rows already sit there relative to now). Execute and watch the If
node split the first-timer from the regular. No message leaves: the
send node is a placeholder by design.

The complete workflow JSON

Import into n8n (Workflows, Import from File), replace the demo source
with your completed-visits sheet, and put a real send node in the
middle. Point REVIEWLINK at your review page:

{
  "name": "Send post-visit review asks and rebooking nudges",
  "nodes": [
    {
      "parameters": {
        "rule": {
          "interval": [
            {
              "field": "hours",
              "hoursInterval": 12
            }
          ]
        }
      },
      "id": "d1000000-0000-4000-8000-000000000001",
      "name": "Every 12 hours",
      "type": "n8n-nodes-base.scheduleTrigger",
      "typeVersion": 1.2,
      "position": [
        -200,
        0
      ]
    },
    {
      "parameters": {
        "jsCode": "// DEMO SOURCE. Replace with your Google Sheet of completed visits.\n// Columns: appointment_id, customer_name, phone, visited_at (ISO), treatment, practitioner, first_visit\nconst demoRows = [\n  {\n    appointment_id: 'APT-3001',\n    customer_name: 'Anna Voorbeeld',\n    phone: '+316****5678',\n    visited_at: new Date(Date.now() - 26 * 3600 * 1000).toISOString(),\n    treatment: 'Hair treatment',\n    practitioner: 'Stylist A',\n    first_visit: false\n  },\n  {\n    appointment_id: 'APT-3002',\n    customer_name: 'Tom Voorbeeld',\n    phone: '+316****5432',\n    visited_at: new Date(Date.now() - 3 * 3600 * 1000).toISOString(),\n    treatment: 'Haircut',\n    practitioner: 'Stylist B',\n    first_visit: true\n  }\n];\nreturn demoRows.map((row) => ({ json: row }));"
      },
      "id": "d1000000-0000-4000-8000-000000000002",
      "name": "Completed visits (demo data)",
      "type": "n8n-nodes-base.code",
      "typeVersion": 2,
      "position": [
        20,
        0
      ]
    },
    {
      "parameters": {
        "jsCode": "// Pick visits that ended 20..30 hours ago (the sweet spot: next morning).\n// First-time customers get the review ask; regulars get a rebooking nudge\n// with their usual interval.\nconst items = $input.all();\nconst now = Date.now();\nconst out = [];\nconst INTERVAL_WEEKS = { 'Hair treatment': 12, 'Color touch-up': 6, 'Haircut': 5, 'Check-up': 6, 'Default': 8 };\nfor (const item of items) {\n  const r = item.json;\n  const hoursAgo = (now - new Date(r.visited_at).getTime()) / 3600000;\n  if (hoursAgo < 20 || hoursAgo > 30) continue;\n  const weeks = INTERVAL_WEEKS[r.treatment] || INTERVAL_WEEKS['Default'];\n  const rebookDate = new Date(now + weeks * 7 * 24 * 3600 * 1000);\n  const rebookStr = rebookDate.toLocaleDateString('en-GB', { weekday: 'long', day: 'numeric', month: 'long' });\n  let message;\n  if (r.first_visit) {\n    message = 'Hi ' + r.customer_name + ', thanks for your first visit! How was it? A review helps us a lot: REVIEWLINK. It takes 1 minute.';\n  } else {\n    message = 'Hi ' + r.customer_name + ', great to see you again! Your next ' + r.treatment + ' is due in about ' + weeks + ' weeks (' + rebookStr + '). Want to reserve a spot now? Reply BOOK.';\n  }\n  out.push({\n    json: {\n      appointment_id: r.appointment_id,\n      customer_name: r.customer_name,\n      to: r.phone,\n      channel: 'whatsapp',\n      kind: r.first_visit ? 'review_ask' : 'rebook_nudge',\n      rebook_weeks: weeks,\n      rebook_date: rebookDate.toISOString(),\n      message: message\n    }\n  });\n}\nreturn out;"
      },
      "id": "d1000000-0000-4000-8000-000000000003",
      "name": "Pick window + build message",
      "type": "n8n-nodes-base.code",
      "typeVersion": 2,
      "position": [
        240,
        0
      ]
    },
    {
      "parameters": {
        "jsCode": "// Placeholder for the send node (WhatsApp Business Cloud / SMS / email).\nconst items = $input.all();\nreturn items.map((item) => ({\n    json: { ...item.json, sent_at: new Date().toISOString(), transport: 'demo' }\n}));"
      },
      "id": "d1000000-0000-4000-8000-000000000004",
      "name": "Send follow-up (replace me)",
      "type": "n8n-nodes-base.code",
      "typeVersion": 2,
      "position": [
        460,
        0
      ]
    },
    {
      "parameters": {
        "conditions": {
          "options": {
            "caseSensitive": true,
            "leftValue": "",
            "typeValidation": "strict",
            "version": 2
          },
          "conditions": [
            {
              "id": "c1",
              "leftValue": "={{ $json.kind }}",
              "rightValue": "review_ask",
              "operator": {
                "type": "string",
                "operation": "equals"
              }
            }
          ],
          "combinator": "and"
        },
        "options": {}
      },
      "id": "d1000000-0000-4000-8000-000000000005",
      "name": "Review ask?",
      "type": "n8n-nodes-base.if",
      "typeVersion": 2.2,
      "position": [
        680,
        0
      ]
    },
    {
      "parameters": {
        "jsCode": "// Review-ask outcomes: log which channel converted (wire a Sheet write here).\nconst items = $input.all();\nreturn items.map((item) => ({ json: { ...item.json, logged_as: 'review_sent' } }));"
      },
      "id": "d1000000-0000-4000-8000-000000000006",
      "name": "Log review ask",
      "type": "n8n-nodes-base.code",
      "typeVersion": 2,
      "position": [
        900,
        -100
      ]
    },
    {
      "parameters": {
        "jsCode": "// Rebook-nudge outcomes: a BOOK reply should trigger your booking intake\n// workflow with the suggested slot prefilled.\nconst items = $input.all();\nreturn items.map((item) => ({ json: { ...item.json, logged_as: 'rebook_sent' } }));"
      },
      "id": "d1000000-0000-4000-8000-000000000007",
      "name": "Log rebook nudge",
      "type": "n8n-nodes-base.code",
      "typeVersion": 2,
      "position": [
        900,
        100
      ]
    },
    {
      "parameters": {
        "content": "## Send post-visit review asks and rebooking nudges\n\n### How it works\n\nEvery 12 hours the workflow reads completed visits and picks the ones that ended 20 to 30 hours ago: next-morning timing, high response rates. First-time customers get a review ask. Regulars get a rebooking nudge with the interval their treatment usually needs. Each message is built with the customer name, the treatment, and the suggested rebooking date, then handed to your WhatsApp, SMS, or email send node.\n\n### Setup steps\n\n- Replace the demo visits node with your Google Sheets source of completed visits.\n- Replace the send placeholder with a WhatsApp Business Cloud, SMS, or email node.\n- Point REVIEWLINK in the review message at your review page.\n\n### Customization\n\nTreatment intervals live in the INTERVAL_WEEKS map in the window-picker node. The 20-30 hour window and the 12-hour schedule fit most salons and clinics; shift them for your own rhythm.\n\n### Requirements\n\nn8n on any plan. The demo data runs without credentials. For production you need a Google Sheets credential and a WhatsApp Business Cloud, SMS, or email send credential.",
        "width": 600,
        "height": 820
      },
      "id": "cccc0000-0000-4000-8000-0000000000f1",
      "name": "Sticky Note 00f1",
      "type": "n8n-nodes-base.stickyNote",
      "typeVersion": 1,
      "position": [
        -960,
        -300
      ]
    },
    {
      "parameters": {
        "content": "## 1. Read visits\nDemo rows stand in for your Sheet of completed visits. Swap the node, keep the columns.",
        "color": 7,
        "width": 455,
        "height": 420
      },
      "id": "cccc0000-0000-4000-8000-0000000000f2",
      "name": "Sticky Note 00f2",
      "type": "n8n-nodes-base.stickyNote",
      "typeVersion": 1,
      "position": [
        -320,
        -200
      ]
    },
    {
      "parameters": {
        "content": "## 2. Pick window + build message\n20-30 hours after the visit. First visit: review ask. Regular: rebooking nudge with treatment interval.",
        "color": 7,
        "width": 400,
        "height": 420
      },
      "id": "cccc0000-0000-4000-8000-0000000000f3",
      "name": "Sticky Note 00f3",
      "type": "n8n-nodes-base.stickyNote",
      "typeVersion": 1,
      "position": [
        175,
        -200
      ]
    },
    {
      "parameters": {
        "content": "## 3. Send + log\nReplace the placeholder with your real send node. Both branches log what went out.",
        "color": 7,
        "width": 515,
        "height": 580
      },
      "id": "cccc0000-0000-4000-8000-0000000000f4",
      "name": "Sticky Note 00f4",
      "type": "n8n-nodes-base.stickyNote",
      "typeVersion": 1,
      "position": [
        615,
        -200
      ]
    }
  ],
  "connections": {
    "Every 12 hours": {
      "main": [
        [
          {
            "node": "Completed visits (demo data)",
            "type": "main",
            "index": 0
          }
        ]
      ]
    },
    "Completed visits (demo data)": {
      "main": [
        [
          {
            "node": "Pick window + build message",
            "type": "main",
            "index": 0
          }
        ]
      ]
    },
    "Pick window + build message": {
      "main": [
        [
          {
            "node": "Send follow-up (replace me)",
            "type": "main",
            "index": 0
          }
        ]
      ]
    },
    "Send follow-up (replace me)": {
      "main": [
        [
          {
            "node": "Review ask?",
            "type": "main",
            "index": 0
          }
        ]
      ]
    },
    "Review ask?": {
      "main": [
        [
          {
            "node": "Log review ask",
            "type": "main",
            "index": 0
          }
        ],
        [
          {
            "node": "Log rebook nudge",
            "type": "main",
            "index": 0
          }
        ]
      ]
    }
  }
}

Where this fits

This is the fourth full build in the series. Appointment reminders
with a no-double-send
guard,
waitlist backfill that fills cancelled slots
automatically,
and fee recovery with a polite escalation
ladder
came before. The series now also has a closing part: a weekly KPI digest
that tells you whether any of it worked. This one grows the good side of
the ledger: reviews and rebookings instead of losses. If you want the Dutch-language versions
plus the surrounding pack (booking intake, KPI digest) in one download,
it is here: https://vlotstream.gumroad.com/l/rhmxw

Free companion tool

Want the number before the workflow? I put the no-show math in a small
free calculator (EN/NL, no signup, runs in your browser): no-show cost
calculator

Recover no-show fees without the awkward conversation: an n8n escalation ladder, JSON included

vlotstroom — Thu, 01 Oct 2026 12:50:13 +0000

I build n8n automations for small salons and clinics. Reminders cut
no-shows and waitlist backfill refills the empty slots, but one question
stays: the fee. Most salons have a no-show fee policy on paper and almost
none of them ever charge it, because charging means an awkward
conversation at the counter. Here is the full build: a workflow that
runs every 12 hours, finds the appointments missed about a day ago, and
sends a fee request that stays polite on purpose. Complete workflow JSON
at the end, runs on n8n alone.

Why "about a day ago" is the whole trick

Timing is what makes a fee message feel fair or feel like a shake-down.
Send it the same evening and the customer is still annoyed about whatever
made them miss the visit. Send it two weeks later and it reads as a
surprise fine. The window that works for my customers is 20 to 30 hours
after the missed appointment: late enough that it is clearly not an
accusation in the heat of the moment, early enough that the slot and the
fee still feel connected.

So the workflow does not process "all no-shows". It processes the ones
in that window, once, and then never touches them again. That single
filter does three jobs: it enforces politeness, it prevents double
sending, and it keeps the message queue tiny.

First offense versus repeat

The second design decision is that not every no-show gets the same
message:

First miss: a short, friendly invoice. The fee, a payment link, and an easy way to book again. No lecture.
Repeat miss (two or more priors): the same fee, plus a deposit request for future bookings. Still no lecture, but the terms change.

The reasoning is money, not morals. A recovered customer is worth more
than a fee, so the first message is built to end with "reply NEW to book
again" rather than a wall. But a pattern of no-shows is a real cost, so
the repeat path quietly moves that customer to prepaid. Both messages
are written to be screenshot-safe: if the customer posts the message
publicly, the salon looks reasonable.

What the workflow does

Nine nodes, one schedule trigger:

Every 12 hours, a trigger fires.
The no-show log is read. Demo rows in the JSON below; swap in your Google Sheet or booking export.
A Code node filters to the 20-30 hour window and builds the message per tier.
A placeholder send node stands in for WhatsApp Business Cloud or SMS.
A tracker node marks each fee as awaiting payment, ready to wire to your sheet.

The columns the log needs:

appointment_id, customer_name, phone, missed_at (ISO), treatment, fee_eur, prior_no_shows
APT-4001, Kevin Smits, +316****5631, 2026-10-01T09:00:00Z, Haircut, 25, 0
APT-4002, Bram van Dijk, +316****5632, 2026-10-01T07:00:00Z, Balayage, 45, 2

The two code nodes that matter

The window filter and tier picker. One node does the timing, the
tiering and the message:

const items = $input.all();
const now = Date.now();
const out = [];
for (const item of items) {
  const r = item.json;
  const hoursAgo = (now - new Date(r.missed_at).getTime()) / 3600000;
  if (hoursAgo < 20 || hoursAgo > 30) continue;
  const repeat = (r.prior_no_shows || 0) >= 2;
  let message;
  if (repeat) {
    message = 'Hi ' + r.customer_name + ', we missed you at your last appointment. Your no-show fee of EUR ' + r.fee_eur + ' is ready to pay: PAYMENTLINK. For new bookings we now ask a small deposit to hold the time. We would love to see you again.';
  } else {
    message = 'Hi ' + r.customer_name + ', we missed you. No problem, it happens. We do charge EUR ' + r.fee_eur + ' for the reserved time block: PAYMENTLINK. Want to pick a new time? Reply NEW.';
  }
  out.push({
    json: {
      appointment_id: r.appointment_id,
      customer_name: r.customer_name,
      to: r.phone,
      channel: 'whatsapp',
      tier: repeat ? 'repeat_offender' : 'first_offense',
      fee_eur: r.fee_eur,
      message: message
    }
  });
}
return out;

The continue on the window check is what makes the flow safe to run
every 12 hours: rows outside the window drop out before any message
exists.

The recovery tracker. The last node stamps every send with
awaiting_payment. From there, wire two things: a payment webhook that
flips it to recovered, and a 14-day check that writes off the rest.
Salons I work with recover a third to a half of the fees they never
dared charge before, and the ones they do not recover become the deposit
list, which costs nothing to keep.

Test it without sending anything

The workflow JSON below has demo data wired in. Import it into n8n,
open the no-show node, and shift missed_at to roughly 24 hours ago
(the demo rows already sit there relative to now). Execute the workflow
and watch the tier picker split first offense from repeat. No message
leaves, because the send node is a placeholder by design.

One lesson from running this in production

Write the payment link into the message, not into the policy. The first
version of this flow sent "please transfer to NL..." and recovery was
poor, because paying took effort and shame. With a payment link the
customer handles it in thirty seconds at arm's length, which is exactly
the emotional distance a fee needs. The message copy is the product
here, the workflow just delivers it at the right hour.

The complete workflow JSON

Import into n8n (Workflows, Import from File), replace the demo source
with your no-show log, and put a real send node in the middle:

{
  "name": "Recover no-show fees with a polite escalation ladder",
  "nodes": [
    {
      "parameters": {
        "rule": {
          "interval": [
            {
              "field": "hours",
              "hoursInterval": 12
            }
          ]
        }
      },
      "id": "e1000000-0000-4000-8000-000000000001",
      "name": "Every 12 hours",
      "type": "n8n-nodes-base.scheduleTrigger",
      "typeVersion": 1.2,
      "position": [
        -200,
        0
      ]
    },
    {
      "parameters": {
        "jsCode": "// DEMO SOURCE. Replace with your no-show log (Google Sheet).\n// Columns: appointment_id, customer_name, phone, missed_at (ISO), treatment, fee_eur, prior_no_shows\nconst demoRows = [\n  {\n    appointment_id: 'APT-4001',\n    customer_name: 'Kevin Smits',\n    phone: '+316****5631',\n    missed_at: new Date(Date.now() - 24 * 3600 * 1000).toISOString(),\n    treatment: 'Haircut',\n    fee_eur: 25,\n    prior_no_shows: 0\n  },\n  {\n    appointment_id: 'APT-4002',\n    customer_name: 'Bram van Dijk',\n    phone: '+316****5632',\n    missed_at: new Date(Date.now() - 26 * 3600 * 1000).toISOString(),\n    treatment: 'Balayage',\n    fee_eur: 45,\n    prior_no_shows: 2\n  }\n];\nreturn demoRows.map((row) => ({ json: row }));"
      },
      "id": "e1000000-0000-4000-8000-000000000002",
      "name": "No-shows (demo data)",
      "type": "n8n-nodes-base.code",
      "typeVersion": 2,
      "position": [
        20,
        0
      ]
    },
    {
      "parameters": {
        "jsCode": "// Escalation ladder 24h after a missed visit:\n//   first no-show  -> friendly invoice with fee, easy online payment link\n//   repeat (2+)    -> fee + prepay requirement for future bookings\n// Both messages stay polite; the goal is revenue recovery, not punishment.\nconst items = $input.all();\nconst now = Date.now();\nconst out = [];\nfor (const item of items) {\n  const r = item.json;\n  const hoursAgo = (now - new Date(r.missed_at).getTime()) / 3600000;\n  if (hoursAgo < 20 || hoursAgo > 30) continue;\n  const repeat = (r.prior_no_shows || 0) >= 2;\n  let message;\n  if (repeat) {\n    message = 'Hi ' + r.customer_name + ', we missed you at your last appointment. Your no-show fee of EUR ' + r.fee_eur + ' is ready to pay: PAYMENTLINK. For new bookings we now ask a small deposit to hold the time. We would love to see you again.';\n  } else {\n    message = 'Hi ' + r.customer_name + ', we missed you. No problem, it happens. We do charge EUR ' + r.fee_eur + ' for the reserved time block: PAYMENTLINK. Want to pick a new time? Reply NEW.';\n  }\n  out.push({\n    json: {\n      appointment_id: r.appointment_id,\n      customer_name: r.customer_name,\n      to: r.phone,\n      channel: 'whatsapp',\n      tier: repeat ? 'repeat_offender' : 'first_offense',\n      fee_eur: r.fee_eur,\n      message: message\n    }\n  });\n}\nreturn out;"
      },
      "id": "e1000000-0000-4000-8000-000000000003",
      "name": "Escalate by history",
      "type": "n8n-nodes-base.code",
      "typeVersion": 2,
      "position": [
        240,
        0
      ]
    },
    {
      "parameters": {
        "jsCode": "// Placeholder for the send node (WhatsApp Business Cloud / SMS).\nconst items = $input.all();\nreturn items.map((item) => ({\n    json: { ...item.json, sent_at: new Date().toISOString(), transport: 'demo' }\n}));"
      },
      "id": "e1000000-0000-4000-8000-000000000004",
      "name": "Send dunning (replace me)",
      "type": "n8n-nodes-base.code",
      "typeVersion": 2,
      "position": [
        460,
        0
      ]
    },
    {
      "parameters": {
        "jsCode": "// Track fee recovery. Wire a Sheet write + payment webhook here:\n// paid -> mark recovered; unpaid after 14 days -> write off or escalate.\nconst items = $input.all();\nreturn items.map((item) => ({\n    json: { ...item.json, tracked_at: new Date().toISOString(), recovery_state: 'awaiting_payment' }\n}));"
      },
      "id": "e1000000-0000-4000-8000-000000000005",
      "name": "Track recovery",
      "type": "n8n-nodes-base.code",
      "typeVersion": 2,
      "position": [
        680,
        0
      ]
    },
    {
      "parameters": {
        "content": "## Recover no-show fees with a polite escalation ladder\n\n### How it works\n\nEvery 12 hours the workflow reads your no-show log and picks the visits missed 20 to 30 hours ago, the moment a friendly invoice still feels fair. First-time no-shows get a short message with the fee and a payment link. Repeat no-shows get the same fee plus a deposit request for future bookings. Every message is written to recover revenue without shaming the customer, because a recovered client is worth more than a fee. What leaves the workflow is ready to send: phone, channel, tier, and the message text.\n\n### Setup steps\n\n- Disable the demo node and connect your no-show sheet. Required columns are listed in that node.\n- Replace the placeholder send node with WhatsApp Business Cloud or SMS.\n- Put your payment link in the message where it says PAYMENTLINK.\n- Activate the workflow.\n\n### Requirements\n\n- A sheet or other source with one row per no-show: missed_at, fee, prior_no_shows count, and contact details.\n\n### Customization\n\nChange the escalation threshold (currently 2 prior no-shows), the 20-30 hour window, the fee amounts, or the message copy per tier.",
        "color": "#fff59d",
        "width": 320,
        "height": 1120
      },
      "id": "cccc0000-0000-4000-8000-0000000000f1",
      "name": "Sticky Note 00f1",
      "type": "n8n-nodes-base.stickyNote",
      "typeVersion": 1,
      "position": [
        -560,
        -240
      ]
    },
    {
      "parameters": {
        "content": "## 1. No-show log\nRuns every 12 hours. Demo node stands in for your sheet.",
        "color": "#ffffff",
        "width": 240,
        "height": 200
      },
      "id": "cccc0000-0000-4000-8000-0000000000f2",
      "name": "Sticky Note 00f2",
      "type": "n8n-nodes-base.stickyNote",
      "typeVersion": 1,
      "position": [
        -240,
        -220
      ]
    },
    {
      "parameters": {
        "content": "## 2. Escalation\nFirst offense gets a friendly invoice, repeats get fee + deposit ask.",
        "color": "#ffffff",
        "width": 260,
        "height": 200
      },
      "id": "cccc0000-0000-4000-8000-0000000000f3",
      "name": "Sticky Note 00f3",
      "type": "n8n-nodes-base.stickyNote",
      "typeVersion": 1,
      "position": [
        140,
        -220
      ]
    },
    {
      "parameters": {
        "content": "## 3. Send + track\nPlaceholder send node, then a recovery tracker you can wire to a sheet.",
        "color": "#ffffff",
        "width": 260,
        "height": 200
      },
      "id": "cccc0000-0000-4000-8000-0000000000f4",
      "name": "Sticky Note 00f4",
      "type": "n8n-nodes-base.stickyNote",
      "typeVersion": 1,
      "position": [
        520,
        -220
      ]
    }
  ],
  "connections": {
    "Every 12 hours": {
      "main": [
        [
          {
            "node": "No-shows (demo data)",
            "type": "main",
            "index": 0
          }
        ]
      ]
    },
    "No-shows (demo data)": {
      "main": [
        [
          {
            "node": "Escalate by history",
            "type": "main",
            "index": 0
          }
        ]
      ]
    },
    "Escalate by history": {
      "main": [
        [
          {
            "node": "Send dunning (replace me)",
            "type": "main",
            "index": 0
          }
        ]
      ]
    },
    "Send dunning (replace me)": {
      "main": [
        [
          {
            "node": "Track recovery",
            "type": "main",
            "index": 0
          }
        ]
      ]
    }
  }
}

Where this fits

This is the third full build in the series. First came appointment
reminders with a no-double-send
guard,
then waitlist backfill that fills cancelled slots
automatically.
Together they cover the loss side of the loop: prevent the no-show, refill
the slot, recover the fee. The fourth build grows the good side: reviews and
rebookings, in Turn finished visits into reviews and rebookings: an n8n follow-up workflow, JSON included. The fifth part closes the loop with the numbers: a weekly KPI digest. If you want the Dutch-language versions plus the
surrounding pack (booking intake, follow-ups, KPI digest) in one
download, it is here: https://vlotstream.gumroad.com/l/rhmxw

Coming from Pipedream?

Pipedream Workflows shuts down on March 31, 2027. I wrote a migration map that covers what the export gives you, what maps where in n8n, and how the patterns in this series land on tested library templates: Pipedream Workflows shuts down in March 2027: a migration map to n8n

Free companion tool

Want the number before the workflow? I put the no-show math in a small
free calculator (EN/NL, no signup, runs in your browser): no-show cost
calculator

Fill cancelled appointments automatically: a ranked waitlist n8n workflow, JSON included

vlotstroom — Wed, 30 Sep 2026 04:50:31 +0000

I build n8n automations for small salons and clinics. After reminders,
the second most common ask is this: a customer cancels at 18:00 for a
slot tomorrow morning, the owner does not want to spend the evening
phoning down a waitlist. Here is the full build: a webhook that takes
the cancellation, ranks the waitlist for that exact slot, and offers it
to the top three people at once. First reply wins. Complete workflow
JSON at the end, runs on n8n alone.

Why rank a waitlist instead of calling top-down

Calling one person at a time wastes the hours you are trying to save:
each no-answer burns 30 minutes of your evening. Offering to three
people at once means the first TAKE reply fills the slot and the rest
get a polite note. The only thing you have to decide in advance is who
counts as "top", and that is a scoring question, not a phone question.

My ranking, after a year of doing this for salon owners:

Treatment match is worth 50 points. Someone who wanted exactly this treatment says yes fast.
A flexible flag is worth 20. These people said "call me whenever something opens".
Your own priority score is the tiebreaker. Most owners keep a 0-10 gut-feel number per regular anyway.

What the workflow does

Twelve nodes, one webhook entry:

A booking system (or a human) POSTs the freed slot as JSON.
The payload is normalized and validated. Bad payloads get a clean 422 back so the sender knows immediately instead of guessing.
The waitlist is read (demo rows in the JSON below, swap in your Google Sheet).
Every entry gets a match score, the top three get an offer message.
The response tells the sender the slot is being offered.

A sample cancellation payload:

{
  "slot_start": "2026-10-02T09:00:00+02:00",
  "practitioner": "Lisa",
  "treatment": "Knippen",
  "duration_minutes": 45,
  "location": "Salon Vlot"
}

And the offer message that goes out:

Hi Lisa Mertens, a spot just opened up Friday 09:00 with Lisa. You are
on our waitlist. Want this spot? Reply TAKE within 30 minutes, after
that it goes to the next person.

The build, node by node

1. Webhook. Path waitlist-offer, HTTP POST, respond immediately.
Every booking tool that can fire a webhook (Cal.com, Google Calendar
add-ons, plain Forms) can drive this.

2. Normalize cancellation. A Code node that coerces the payload
into one shape and validates it:

const b = $json.body || $json;
const out = {
  slot_start: b.slot_start,
  practitioner: b.practitioner || 'Team',
  treatment: b.treatment || 'any',
  duration_minutes: Number(b.duration_minutes) || 30,
};
const valid = out.slot_start && !Number.isNaN(Date.parse(out.slot_start));
return [{ json: { ...out, valid } }];

3. Valid? IF node. One branch for good payloads, one that returns
a 422 with a reason. Validation at the edge keeps junk out of your
waitlist logic.

4. Waitlist source. Demo rows in the JSON below, a disabled Google
Sheets node in real use. The columns that matter:

customer_name, phone, wanted_treatment, flexible, priority_score
Lisa Mertens, +316****5641, Haircut, true, 9
Daan Cox, +316****5642, Balayage, false, 6
Nina Blaauw, +316****5643, Haircut, true, 7

5. Rank + build offers. The scoring heart, one Code node:

const slot = $('Normalize cancellation').first().json;
const items = $input.all();
const ranked = items
  .map((item) => {
    const r = item.json;
    let score = 0;
    if (slot.treatment !== 'any' && r.wanted_treatment === slot.treatment) score += 50;
    if (r.flexible) score += 20;
    score += Number(r.priority_score) || 0;
    return { json: { ...r, match_score: score } };
  })
  .sort((a, b) => b.json.match_score - a.json.match_score)
  .slice(0, 3);
const slotStr = new Date(slot.slot_start).toLocaleString('en-GB', {
  weekday: 'long', hour: '2-digit', minute: '2-digit'
});
return ranked.map((entry, i) => ({
  json: {
    ...entry.json,
    offer_position: i + 1,
    slot_start: slot.slot_start,
    message: 'Hi ' + entry.json.customer_name + ', a spot just opened up ' + slotStr + ' with ' + slot.practitioner + '. You are on our waitlist. Want this spot? Reply TAKE within 30 minutes, after that it goes to the next person.'
  }
}));

The $('Normalize cancellation') lookup matters: the rank node needs
slot data from a different branch, and this is the n8n way to reach it.

6. Send offers. A placeholder Code node in the JSON below. Replace
it with WhatsApp Business Cloud, SMS or email nodes. In production I
split per customer channel preference, same as in my reminder build.

7. Respond. The webhook response says the slot is being offered and
to how many people.

Test it without sending anything

The workflow JSON below has a pinned demo payload on the webhook node.
Click Execute Workflow in the n8n editor and the whole flow runs on
that pinned data, offers built, no message ever leaves. That pinned
payload is also how I smoke-test every change before it goes live.

Two lessons from running this in production

First, cap the offers at three. I tried five once and two people
replied TAKE within minutes, which means an awkward "sorry, already
taken" to a customer you want to keep. Three is the largest number
where first-reply-wins still feels fair.

Second, the 30-minute window in the message text is load-bearing copy,
not a timer. The workflow does not enforce it; the message sets the
expectation so late replies arrive pre-apologized. Owners who want a
real timer can add a Wait node and a check step, and I usually talk
them out of it: the manual path is simpler and the message does the
work.

The complete workflow JSON

Import into n8n (Workflows, Import from File), open the webhook node,
and execute with the pinned payload:

{
  "name": "Fill cancelled slots from a ranked waitlist",
  "nodes": [
    {
      "parameters": {
        "httpMethod": "POST",
        "path": "waitlist-cancellation",
        "responseMode": "responseNode",
        "options": {}
      },
      "id": "f1000000-0000-4000-8000-000000000001",
      "name": "Webhook: slot cancelled",
      "type": "n8n-nodes-base.webhook",
      "typeVersion": 2,
      "position": [
        -200,
        0
      ]
    },
    {
      "parameters": {
        "jsCode": "// Normalize the cancellation event. Expected body:\n// slot_start (ISO), practitioner, treatment, duration_min\nconst b = $input.first().json.body || $input.first().json;\nif (!b.slot_start || isNaN(new Date(b.slot_start).getTime())) {\n  return [{ json: { ok: false, error: 'slot_start invalid' } }];\n}\nreturn [{\n  json: {\n    ok: true,\n    slot_start: new Date(b.slot_start).toISOString(),\n    practitioner: b.practitioner || 'any',\n    treatment: b.treatment || 'any',\n    duration_min: Number(b.duration_min) || 60,\n    released_at: new Date().toISOString()\n  }\n}];"
      },
      "id": "f1000000-0000-4000-8000-000000000002",
      "name": "Normalize cancellation",
      "type": "n8n-nodes-base.code",
      "typeVersion": 2,
      "position": [
        20,
        0
      ]
    },
    {
      "parameters": {
        "jsCode": "// DEMO SOURCE. Replace with your waitlist sheet.\n// Columns: customer_name, phone, wanted_treatment, flexible (bool), priority_score\nconst demoWaitlist = [\n  { customer_name: 'Lisa Mertens', phone: '+316****5641', wanted_treatment: 'Haircut', flexible: true, priority_score: 9 },\n  { customer_name: 'Daan Cox', phone: '+316****5642', wanted_treatment: 'Balayage', flexible: false, priority_score: 6 },\n  { customer_name: 'Nina Blaauw', phone: '+316****5643', wanted_treatment: 'Haircut', flexible: true, priority_score: 7 }\n];\nreturn demoWaitlist.map((row) => ({ json: row }));"
      },
      "id": "f1000000-0000-4000-8000-000000000003",
      "name": "Waitlist (demo data)",
      "type": "n8n-nodes-base.code",
      "typeVersion": 2,
      "position": [
        240,
        0
      ]
    },
    {
      "parameters": {
        "jsCode": "// Rank waitlist entries for this slot: treatment match first, flexible\n// entries next, then priority_score. Offer to the top 3 at once (first\n// reply wins, the rest get a friendly 'already taken').\nconst slot = $('Normalize cancellation').first().json;\nconst items = $input.all();\nconst ranked = items\n  .map((item) => {\n    const r = item.json;\n    let score = 0;\n    if (slot.treatment !== 'any' && r.wanted_treatment === slot.treatment) score += 50;\n    if (r.flexible) score += 20;\n    score += Number(r.priority_score) || 0;\n    return { json: { ...r, match_score: score } };\n  })\n  .sort((a, b) => b.json.match_score - a.json.match_score)\n  .slice(0, 3);\nconst slotStr = new Date(slot.slot_start).toLocaleString('en-GB', {\n  weekday: 'long', hour: '2-digit', minute: '2-digit'\n});\nreturn ranked.map((entry, i) => ({\n  json: {\n    ...entry.json,\n    offer_position: i + 1,\n    slot_start: slot.slot_start,\n    message: 'Hi ' + entry.json.customer_name + ', a spot just opened up ' + slotStr + ' with ' + slot.practitioner + '. You are on our waitlist. Want this spot? Reply TAKE within 30 minutes, after that it goes to the next person.'\n  }\n}));"
      },
      "id": "f1000000-0000-4000-8000-000000000004",
      "name": "Rank + build offers",
      "type": "n8n-nodes-base.code",
      "typeVersion": 2,
      "position": [
        460,
        0
      ]
    },
    {
      "parameters": {
        "jsCode": "// Placeholder for the send node (WhatsApp Business Cloud / SMS).\nconst items = $input.all();\nreturn items.map((item) => ({\n    json: { ...item.json, sent_at: new Date().toISOString(), transport: 'demo' }\n}));"
      },
      "id": "f1000000-0000-4000-8000-000000000005",
      "name": "Send offers (replace me)",
      "type": "n8n-nodes-base.code",
      "typeVersion": 2,
      "position": [
        680,
        0
      ]
    },
    {
      "parameters": {
        "respondWith": "json",
        "responseBody": "={{ { \"ok\": true, \"offers_sent\": $input.all().length } }}",
        "options": {}
      },
      "id": "f1000000-0000-4000-8000-000000000006",
      "name": "Respond",
      "type": "n8n-nodes-base.respondToWebhook",
      "typeVersion": 1.1,
      "position": [
        900,
        0
      ]
    },
    {
      "parameters": {
        "conditions": {
          "options": {
            "caseSensitive": true,
            "leftValue": "",
            "typeValidation": "strict",
            "version": 2
          },
          "conditions": [
            {
              "id": "c1",
              "leftValue": "={{ $json.ok }}",
              "rightValue": true,
              "operator": {
                "type": "boolean",
                "operation": "true"
              }
            }
          ],
          "combinator": "and"
        },
        "options": {}
      },
      "id": "b0000000-0000-4000-8000-000000000006",
      "name": "Valid?",
      "type": "n8n-nodes-base.if",
      "typeVersion": 2.2,
      "position": [
        130,
        0
      ]
    },
    {
      "parameters": {
        "respondWith": "json",
        "responseCode": 422,
        "responseBody": "={{ { \"ok\": false, \"error\": $json.error } }}",
        "options": {}
      },
      "id": "b0000000-0000-4000-8000-000000000016",
      "name": "Respond invalid",
      "type": "n8n-nodes-base.respondToWebhook",
      "typeVersion": 1.1,
      "position": [
        130,
        220
      ],
      "webhookId": "b0000000-0000-4000-8000-000000000026"
    },
    {
      "parameters": {
        "content": "## Fill cancelled slots from a ranked waitlist\n\n### How it works\n\nWhen a booking is cancelled, your calendar system POSTs the freed slot to a webhook. The workflow checks the payload, then ranks your waitlist for that exact slot: treatment match counts most, flexibility next, then your own priority score. The top three people get an offer message at the same time, first reply wins, and the slot rarely stays empty. Invalid payloads get a clean 422 back so the sender knows immediately. Demo data is included, and the pinned webhook payload lets you run the whole flow without sending anything.\n\n### Setup steps\n\n- Point your booking system's cancellation event at the webhook URL.\n- Disable the demo waitlist node and connect your waitlist sheet. Columns are listed in that node.\n- Replace the placeholder send node with WhatsApp Business Cloud or SMS.\n- Optional: change how many people get an offer (currently 3).\n\n### Requirements\n\n- A waitlist with customer name, phone, wanted treatment, a flexible flag, and a priority score.\n\n### Customization\n\nChange the ranking weights, the offer count, the 30-minute reply window, or the message copy.",
        "color": "#fff59d",
        "width": 340,
        "height": 560
      },
      "id": "cccc0000-0000-4000-8000-0000000000f1",
      "name": "Sticky Note 00f1",
      "type": "n8n-nodes-base.stickyNote",
      "typeVersion": 1,
      "position": [
        -560,
        -280
      ]
    },
    {
      "parameters": {
        "content": "## 1. Cancellation in\nWebhook plus payload check. Bad payloads get a 422.",
        "color": "#ffffff",
        "width": 240,
        "height": 140
      },
      "id": "cccc0000-0000-4000-8000-0000000000f2",
      "name": "Sticky Note 00f2",
      "type": "n8n-nodes-base.stickyNote",
      "typeVersion": 1,
      "position": [
        -240,
        -160
      ]
    },
    {
      "parameters": {
        "content": "## 2. Rank\nTreatment match first, flexible next, then priority. Top 3 get offers.",
        "color": "#ffffff",
        "width": 260,
        "height": 140
      },
      "id": "cccc0000-0000-4000-8000-0000000000f3",
      "name": "Sticky Note 00f3",
      "type": "n8n-nodes-base.stickyNote",
      "typeVersion": 1,
      "position": [
        140,
        -160
      ]
    },
    {
      "parameters": {
        "content": "## 3. Offers out\nPlaceholder send node plus JSON response for the caller.",
        "color": "#ffffff",
        "width": 260,
        "height": 140
      },
      "id": "cccc0000-0000-4000-8000-0000000000f4",
      "name": "Sticky Note 00f4",
      "type": "n8n-nodes-base.stickyNote",
      "typeVersion": 1,
      "position": [
        520,
        -160
      ]
    }
  ],
  "connections": {
    "Webhook: slot cancelled": {
      "main": [
        [
          {
            "node": "Normalize cancellation",
            "type": "main",
            "index": 0
          }
        ]
      ]
    },
    "Normalize cancellation": {
      "main": [
        [
          {
            "node": "Valid?",
            "type": "main",
            "index": 0
          }
        ]
      ]
    },
    "Waitlist (demo data)": {
      "main": [
        [
          {
            "node": "Rank + build offers",
            "type": "main",
            "index": 0
          }
        ]
      ]
    },
    "Rank + build offers": {
      "main": [
        [
          {
            "node": "Send offers (replace me)",
            "type": "main",
            "index": 0
          }
        ]
      ]
    },
    "Send offers (replace me)": {
      "main": [
        [
          {
            "node": "Respond",
            "type": "main",
            "index": 0
          }
        ]
      ]
    },
    "Valid?": {
      "main": [
        [
          {
            "node": "Waitlist (demo data)",
            "type": "main",
            "index": 0
          }
        ],
        [
          {
            "node": "Respond invalid",
            "type": "main",
            "index": 0
          }
        ]
      ]
    }
  },
  "pinData": {
    "Webhook: slot cancelled": [
      {
        "json": {
          "body": {
            "slot_start": "2099-01-15T10:00:00.000Z",
            "practitioner": "Emma",
            "treatment": "Haircut",
            "duration_min": 45
          }
        }
      }
    ]
  }
}

Where this fits

This is the second of my salon automations I am publishing as full
builds. The first was appointment reminders with a no-double-send
guard. Together they cover the two sides of the same problem: reminders
prevent no-shows, waitlist backfill recovers the ones that happen
anyway. If you want the Dutch-language versions plus the surrounding
pack (booking intake, dunning, follow-ups, KPI digest) in one download,
it is here: https://vlotstream.gumroad.com/l/rhmxw

If you build this, the one thing to tune is the ranking weights. Every
owner ranks their waitlist slightly differently, and that is the whole
point: the machine phones nobody, it just puts your own order to work.

Related in this series

This is part 2 of a small series on appointment automation with n8n. The other parts: Appointment reminders that cut no-shows: a complete n8n workflow, JSON included, Recover no-show fees without the awkward conversation: an n8n escalation ladder, JSON included and Turn finished visits into reviews and rebookings: an n8n follow-up workflow, JSON included. The loop closes with a weekly KPI digest that tells you whether it all worked.

Free companion tool

Want the number before the workflow? I put the no-show math in a small free calculator (EN/NL, no signup, runs in your browser): no-show cost calculator

How many of those opened slots can your waitlist actually refill? I built a second free tool for that (EN/NL, no signup): waitlist fill-rate calculator

Appointment reminders that cut no-shows: a complete n8n workflow, JSON included

vlotstroom — Mon, 28 Sep 2026 12:46:25 +0000

I build n8n automations for small salons and clinics. The most requested
one is also the simplest: appointment reminders that actually reduce
no-shows. Here is the full build, step by step, with the complete
workflow JSON at the end. It runs on n8n alone, self-hosted or cloud.

What it does

Every 6 hours the workflow reads upcoming appointments from a Google
Sheet, buckets them into an upcoming and a same-day reminder, picks the
channel per customer (WhatsApp or email), and keeps a send log in
workflow static data so a rerun never sends the same reminder stage
twice.

A sample row:

appointment_id, customer_name, phone, email, starts_at, practitioner, treatment, channel_preference
APT-1041, Sanne de Vries, +31612345678, sanne@example.com, 2026-09-29T14:00:00+02:00, Lisa, Knippen, whatsapp

The build, node by node

1. Schedule Trigger. Set it to every 6 hours. Reminders do not need
minute precision, and a calm cadence keeps you far away from API rate
limits.

2. Read appointments. A Google Sheets node with the document ID and
the appointments sheet name. While building, I use a Code node with
three demo rows instead, so I can test without touching a real sheet.
The JSON below ships with that demo node and a disabled Sheets node you
swap in.

3. Bucket the reminders, with a send log. One Code node does the
sorting and the duplicate guard. It computes hours until the appointment,
checks the send log, and builds the message text:

const items = $input.all();
const now = Date.now();
const sent = $getWorkflowStaticData('global').sent || {};
const out = [];

for (const item of items) {
  const r = item.json;
  const startsAt = new Date(r.starts_at);
  const hoursUntil = (startsAt.getTime() - now) / 3600000;

  if (hoursUntil < 0 || hoursUntil > 48) continue; // not in window

  const stage = hoursUntil <= 3 ? 'same_day' : 'upcoming';
  if (sent[r.appointment_id + ':' + stage]) continue; // already sent

  const dateStr = startsAt.toLocaleString('nl-NL', {
    weekday: 'long', day: 'numeric', month: 'long',
    hour: '2-digit', minute: '2-digit'
  });

  let template;
  if (hoursUntil <= 3) {
    template = `Hi ${r.customer_name}, uw afspraak bij ${r.practitioner} is vandaag om ${dateStr} (${r.treatment}). Tot zo!`;
  } else {
    template = `Hi ${r.customer_name}, herinnering: uw afspraak (${r.treatment}) bij ${r.practitioner} is ${dateStr}. Antwoord BEVESTIG om te bevestigen, WIJZIG om te verplaatsen.`;
  }

  out.push({
    json: {
      appointment_id: r.appointment_id,
      to: r.channel_preference === 'email' ? r.email : r.phone,
      channel: r.channel_preference === 'email' ? 'email' : 'whatsapp',
      urgency: stage,
      message: template
    }
  });
  sent[r.appointment_id + ':' + stage] = new Date().toISOString();
}
$getWorkflowStaticData('global').sent = sent;
return out;

Two details matter. The send log keyed on appointment_id + ':' + stage is what makes the 6h schedule safe: a rerun inside the window, an
error recovery rerun, even a manual run all skip stages already logged,
and the log survives across executions because it lives in workflow
static data. And the message text lives in the code, not in the send
nodes, so translating or rewording is a one-place edit.

A reader correctly flagged that the first version of this article relied
on the window check alone, which re-sent the upcoming reminder on every
run while an appointment sat inside the 48h window. The code above and
the JSON below now carry the send log. The version in my template
library uses the same guard across three bands (48-72h heads-up, 8-48h
confirm ask, 0.5-3h same-day).

4. Split by urgency. An IF node on urgency equals same_day. Same-day
messages go out immediately; upcoming ones can batch.

5. Send. Wire a WhatsApp Business Cloud node and an email node to the
two branches. In the JSON below these are stub Code nodes that mark the
queue, so the workflow imports and runs green before you add credentials.

Testing it

Import the JSON, open the reminder-bucket Code node, and run it. You
should see three items become two: the demo rows sit at T-22h, T-1.5h and
T-5d, and the third one falls outside the window. Change the window in
the code and watch the third row appear. That loop, run locally before
anything touches a real sheet, is how I validate every workflow I ship.

Where this goes next

The reminder is one loop of seven. The others handle the replies
(confirm/cancel parsing), no-show follow-ups with a fee ladder, waitlist
autofill when a slot frees up, and a Monday KPI digest. I packaged the
full set with docs and test data if you want the rest:
https://vlotstream.gumroad.com/l/rhmxw

The complete workflow JSON:

{
  "id": "aaaaaaaa-0000-4000-8000-0000000000a1",
  "name": "01 - Appointment Reminders (T-24h / T-2h)",
  "nodes": [
    {
      "parameters": {
        "rule": {
          "interval": [
            {
              "field": "hours",
              "hoursInterval": 6
            }
          ]
        }
      },
      "id": "a1000000-0000-4000-8000-000000000001",
      "name": "Every 6 hours",
      "type": "n8n-nodes-base.scheduleTrigger",
      "typeVersion": 1.2,
      "position": [-200, 0]
    },
    {
      "parameters": {
        "jsCode": "// DEMO SOURCE. Replace with the Google Sheets node below.\n// Columns: appointment_id, customer_name, phone, email, starts_at (ISO),\n// practitioner, treatment, channel_preference\nconst demoRows = [\n  {\n    appointment_id: 'APT-1041',\n    customer_name: 'Sanne de Vries',\n    phone: '+316****5678',\n    email: 'sanne@example.com',\n    starts_at: new Date(Date.now() + 22 * 3600 * 1000).toISOString(),\n    practitioner: 'Lisa',\n    treatment: 'Tandreiniging',\n    channel_preference: 'whatsapp'\n  },\n  {\n    appointment_id: 'APT-1042',\n    customer_name: 'Mark Jansen',\n    phone: '+316****6789',\n    email: 'mark@example.com',\n    starts_at: new Date(Date.now() + 90 * 60 * 1000).toISOString(),\n    practitioner: 'Drs. Bakker',\n    treatment: 'Controle',\n    channel_preference: 'email'\n  },\n  {\n    appointment_id: 'APT-1043',\n    customer_name: 'Fatima El Amrani',\n    phone: '+316****7890',\n    email: 'fatima@example.com',\n    starts_at: new Date(Date.now() + 5 * 24 * 3600 * 1000).toISOString(),\n    practitioner: 'Lisa',\n    treatment: 'Nieuwe patient',\n    channel_preference: 'whatsapp'\n  }\n];\nreturn demoRows.map((row) => ({ json: row }));"
      },
      "id": "a1000000-0000-4000-8000-000000000002",
      "name": "Appointments (demo data)",
      "type": "n8n-nodes-base.code",
      "typeVersion": 2,
      "position": [20, 0]
    },
    {
      "parameters": {
        "jsCode": "// Build the reminder message for each appointment.\n// Hours-until buckets decide the template; channel comes from the row.\n// Future appointments beyond 48h are skipped so this workflow can run\n// every few hours safely.\nconst items = $input.all();\nconst now = Date.now();\nconst sent = ($getWorkflowStaticData('global').sent) || {};\nconst out = [];\n\nfor (const item of items) {\n  const r = item.json;\n  const startsAt = new Date(r.starts_at);\n  const hoursUntil = (startsAt.getTime() - now) / 3600000;\n\n  if (hoursUntil < 0 || hoursUntil > 48) continue; // not in reminder window\n\n  const stage = hoursUntil <= 3 ? 'same_day' : 'upcoming';\n  if (sent[r.appointment_id + ':' + stage]) continue; // already sent\n\n  const dateStr = startsAt.toLocaleString('nl-NL', {\n    weekday: 'long', day: 'numeric', month: 'long',\n    hour: '2-digit', minute: '2-digit'\n  });\n\n  let template;\n  if (hoursUntil <= 3) {\n    template = `Hi ${r.customer_name}, uw afspraak bij ${r.practitioner} is vandaag om ${dateStr} (${r.treatment}). Tot zo!`;\n  } else {\n    template = `Hi ${r.customer_name}, herinnering: uw afspraak (${r.treatment}) bij ${r.practitioner} is ${dateStr}. Antwoord BEVESTIG om te bevestigen, WIJZIG om te verplaatsen.`;\n  }\n\n  const channel = r.channel_preference === 'email' ? 'email' : 'whatsapp';\n  out.push({\n    json: {\n      appointment_id: r.appointment_id,\n      customer_name: r.customer_name,\n      to: channel === 'email' ? r.email : r.phone,\n      channel,\n      urgency: stage,\n      hours_until: Math.round(hoursUntil * 10) / 10,\n      message: template\n    }\n  });\n  sent[r.appointment_id + ':' + stage] = new Date().toISOString();\n}\n$getWorkflowStaticData('global').sent = sent;\nreturn out;"
      },
      "id": "a1000000-0000-4000-8000-000000000003",
      "name": "Build reminder messages",
      "type": "n8n-nodes-base.code",
      "typeVersion": 2,
      "position": [240, 0]
    },
    {
      "parameters": {
        "conditions": {
          "options": {
            "caseSensitive": true,
            "leftValue": "",
            "typeValidation": "strict",
            "version": 2
          },
          "conditions": [
            {
              "id": "c1",
              "leftValue": "={{ $json.urgency }}",
              "rightValue": "same_day",
              "operator": { "type": "string", "operation": "equals" }
            }
          ],
          "combinator": "and"
        },
        "options": {}
      },
      "id": "a1000000-0000-4000-8000-000000000004",
      "name": "Is same-day?",
      "type": "n8n-nodes-base.if",
      "typeVersion": 2.2,
      "position": [460, 0]
    },
    {
      "parameters": {
        "jsCode": "// Same-day reminders: WhatsApp first, email fallback when no phone.\n// Wire real send nodes here (WhatsApp Business Cloud / Gmail / SMTP).\nconst items = $input.all();\nreturn items.map((item) => ({\n    json: {\n      ...item.json,\n      queue: item.json.channel === 'whatsapp' ? 'whatsapp_priority' : 'email_priority',\n      dispatched_at: new Date().toISOString()\n    }\n}));"
      },
      "id": "a1000000-0000-4000-8000-000000000005",
      "name": "Dispatch same-day",
      "type": "n8n-nodes-base.code",
      "typeVersion": 2,
      "position": [680, -100]
    },
    {
      "parameters": {
        "jsCode": "// Upcoming reminders (next 48h): normal priority batch.\nconst items = $input.all();\nreturn items.map((item) => ({\n    json: {\n      ...item.json,\n      queue: item.json.channel === 'whatsapp' ? 'whatsapp_normal' : 'email_normal',\n      dispatched_at: new Date().toISOString()\n    }\n}));"
      },
      "id": "a1000000-0000-4000-8000-000000000006",
      "name": "Dispatch upcoming",
      "type": "n8n-nodes-base.code",
      "typeVersion": 2,
      "position": [680, 100]
    },
    {
      "parameters": {
        "documentId": { "__rl": true, "value": "YOUR_SHEET_ID", "mode": "id" },
        "sheetName": { "__rl": true, "value": "appointments", "mode": "name" },
        "options": {}
      },
      "id": "a1000000-0000-4000-8000-000000000007",
      "name": "Google Sheets (replace demo)",
      "type": "n8n-nodes-base.googleSheets",
      "typeVersion": 4.5,
      "position": [20, 200],
      "disabled": true
    }
  ],
  "connections": {
    "Every 6 hours": { "main": [[{ "node": "Appointments (demo data)", "type": "main", "index": 0 }]] },
    "Appointments (demo data)": { "main": [[{ "node": "Build reminder messages", "type": "main", "index": 0 }]] },
    "Build reminder messages": { "main": [[{ "node": "Is same-day?", "type": "main", "index": 0 }]] },
    "Is same-day?": {
      "main": [
        [{ "node": "Dispatch same-day", "type": "main", "index": 0 }],
        [{ "node": "Dispatch upcoming", "type": "main", "index": 0 }]
      ]
    }
  },
  "settings": { "executionOrder": "v1" },
  "pinData": {}
}

Questions about the window logic or the channel split? Ask in the comments.

Related in this series

This is part 1 of a small series on appointment automation with n8n. The other parts: Fill cancelled appointments automatically: a ranked waitlist n8n workflow, JSON included, Recover no-show fees without the awkward conversation: an n8n escalation ladder, JSON included and Turn finished visits into reviews and rebookings: an n8n follow-up workflow, JSON included. The loop closes with a weekly KPI digest that tells you whether it all worked.

Coming from Pipedream?

Free companion tool

Want the number before the workflow? I put the no-show math in a small free calculator (EN/NL, no signup, runs in your browser): no-show cost calculator