The failure that kills automations
Ask someone why they stopped using the workflow they built, and it is almost never "it broke". It is one specific story: it sent something odd to a real person, and they turned it off that afternoon and never turned it back on.
That is not an argument against automation. It is an argument about where the last step sits.
The rule
The workflow does the ninety percent. The human does the send.
Watch what the ninety percent actually is for an inbound inquiry: notice the message, pull the sender's history, classify the request, check the calendar, draft a reply in the right tone and language, attach the right PDF, file the thread. That is the work. Clicking send is not the work — it is the decision.
Handing over the work and keeping the decision gives you most of the time back and none of the risk. And it is a much easier thing to trust on day one, which matters, because an automation you don't trust is one you will disable.
Three reasons it holds
The asymmetry. A bad draft costs the two seconds it takes to delete it. A bad send costs an apology, sometimes a client. Those two outcomes are not on the same scale, and a system should be built around the expensive one.
The law now rewards it. Since 2 August 2026, publishing AI-written text on matters of public interest requires a disclosure — unless it went through genuine human review with someone taking editorial responsibility. If your workflow drafts and you read, you are inside the exemption by construction, without adding a compliance step. The details are here.
It gives you the data to go further. After fifty drafts you know exactly which category the model gets right every time and which one it fumbles. Then you can let the safe category send itself, with evidence instead of hope. Nobody can tell you that on day one — including the person who built the workflow.
Building it in n8n
Four shapes, in increasing order of effort:
- Write a draft, not a message. Gmail and Outlook nodes can create a draft in the thread. The reply is sitting there when you open your inbox; you read it, adjust a word, send. Most workflows need nothing more than this.
- Approve in chat. Send the proposed text to yourself in Slack or Telegram with an approve link, and let a Wait node hold the run until you answer. Good when the send is time-sensitive and you are not at your desk.
- Stage it in a document. For content — posts, newsletters — the workflow writes rows into a sheet or a Notion database with a status column, and only published rows go out. Good when you review ten things at once rather than one at a time.
- Auto-send with a delay. Drafted now, sent in thirty minutes unless you cancel. The most convenient, and the one to reach for last, after a category has earned it.
Whatever the shape: log the run. Which input, which output, who approved, when. One line in a sheet is enough, and it turns the question "why did that go out?" from an argument into a lookup.
What to auto-send anyway
Not everything deserves a checkpoint, and putting one everywhere is its own way of abandoning the system. Let these run untouched:
- Notifications to yourself and internal alerts — worst case, you ignore one.
- Filing, labelling, tagging, deduplicating, backing up — reversible, invisible to customers.
- Scheduled internal reports — wrong numbers in a report you read are a bug you find, not a message someone received.
- Strictly factual confirmations with no generated text: "we received your form", a calendar invite, a receipt.
The checkpoint belongs where generated text reaches a person who is not you. That is the whole line.
Why it shows up everywhere in the Vault
Every workflow in The Automation Vault that produces text for a customer ends in a draft, not a send. Not because it is more cautious in general, but because that is the version people keep running after week three. See what's in it →