"It works on my machine" has a cousin in the automation world: "the workflow ran fine in testing." Both sentences are true. Both are the beginning of the story, not the end of it.
Most automations don't fail loudly. They fail quietly, three weeks after handoff, when a lead arrives with an emoji in their name or an API has a bad afternoon. The client doesn't notice for another week. By then the pipeline has a hole in it, and trust has a bigger one.
This is the checklist we run before any workflow touches a client's business. None of it is glamorous. All of it is the difference between an automation that compounds and one that gets switched off.
The 10 checks
1. Idempotent triggers
The same event will eventually arrive twice. A webhook retries, a user double-clicks, a sync runs overlapping. If your workflow cannot recognise "I already handled this," the client gets two invoices, two welcome emails, two CRM records. Build a dedupe key from the event's natural identity (order ID, email plus date) and check it before doing anything with side effects.
2. A dead-letter path
Some runs will fail. The question is where they go. A failed run that vanishes is a customer who never got a reply and nobody knows. Route failures to a visible place: a "needs attention" board, a spreadsheet, a channel. The volume tells you about the health of the system; the contents tell you who to call back.
3. Alerts a person actually reads
Logging is not alerting. An error log nobody opens is a diary, not a monitoring system. When something breaks, a specific person should get a message in a channel they already check. If everything alerts, nothing alerts, so reserve it for failures that need a decision.
4. An approval gate on anything customer-facing
Drafts, not auto-sends. Anything that reaches a customer in the client's name (emails, quotes, replies) should stop in a review queue until a person approves it. This is not a limitation of the automation. It is the feature that lets a cautious client say yes. The gate can widen later, once trust is earned in both directions.
5. Retries with backoff
Every external call fails sometimes. The CRM rate-limits you, the email API times out, the enrichment service has a deploy. A single failed call should never kill a run. Retry with increasing delays, respect rate limits, and only after real persistence route to the dead-letter path.
6. The ugly-data test
Test with the data you will actually receive, not the data you would like to receive. Empty fields. Names with emoji. Phone numbers with spaces. Dates in the wrong format. A postcode where the city should be. Real-world forms produce all of it in week one. If you only tested the happy path, you shipped the sad path untested.
7. A kill switch the client can press
If the client cannot stop the system without calling you, they do not control the system, and they know it. One switch, clearly labelled, that pauses everything safely. In two years of building these, the switch almost never gets pressed. Its existence is the point.
8. Explicit timezones
"Send at 9am" means nothing until you say whose 9am. Schedules should run on the client's business day, not your server's UTC. This bug is invisible in testing and permanent in production: reminders at 3am read as spam, and follow-ups sent on the client's Sunday quietly burn goodwill.
9. Logs that answer three questions
What ran. On what input. What changed. When the client asks "why did this lead not get a follow-up," you need the answer in two minutes, not an afternoon of archaeology. If your logs cannot answer those three questions for any run, they are decoration.
10. A named owner
The one everyone skips. Every automation needs a person who owns it: who gets the weekly health summary, who knows what it does, who decides when it changes. An automation without an owner is technical debt with a delay on it. It runs fine until the day it does not, and by then nobody remembers how it works.
The pattern behind the checklist
Notice what these ten have in common: none of them are about making the automation work. They are about making it fail well. Anyone can build a workflow that runs. The craft is in what happens when it does not: who finds out, how fast, and what the blast radius is.
That is also the honest pitch for doing this professionally. Clients do not pay for the zap. They pay for sleeping through the night the zap fails.
Steal the system
This checklist is one page of a larger system: the 12 workflow patterns we build from, each with its failure modes, the handoff templates, and the client-facing runbooks. If you build automations for clients (or you are the client and want to check your builder's homework), it is packaged as the Workflow Automation Playbook in our catalogue. There is also a free, print-ready PDF of this exact checklist at /free/pre-ship-checklist.
And if you would rather have all of this done and run for you, that is the other half of what we do.