The Scariest Thing an Automation Does Is Work Twice
A crash pages somebody. A double-fire is silent and looks like success.
When I hand a small business an automation, the thing that keeps me up at night is not that it will break. A break is loud. Something errors out, a run fails, a notification fires, and somebody looks at it. Broken is a Tuesday. Broken is fixable. The failure I actually lose sleep over is the one where the automation works, and then works again, on the same thing, and both times it thinks it did its job perfectly.
That is a double-fire, and it is the quietest disaster in the whole toolkit. There is no error. There is no red light. There is a green checkmark, twice, and two of everything downstream. Two follow-up texts to the same customer. Two invoices for one job. Two records in the system that your office manager now has to notice, question, and manually reconcile, assuming she notices at all. The automation did not malfunction. It functioned, extra.
Here is what nobody selling you the tool will tell you: this is not a rare edge case. It is the default behavior of how these things are wired together. Webhooks retry on purpose. If the receiving end is slow to answer, the sender assumes the message got lost and sends it again. Forms double-submit because a customer taps the button, sees nothing happen for half a second on a bad connection, and taps it again. A queue redelivers. A browser tab gets refreshed mid-submit. Every one of those is normal, expected, happens-every-week internet behavior, and every one of them fires your automation a second time on the same event.
I build a lead-and-quote flow for a window cleaning company. Early on, a customer filled out the request form on a spotty phone signal, the page hung, she tapped submit again, and the system did exactly what it was told. Two leads. Two "thanks, we got your request" texts, back to back, ninety seconds apart. To her, that is not a clever automation. That is a company that looks like it cannot keep its own records straight, before it has even quoted the job. The tech worked. The impression was a disaster.
Now move that same glitch onto money and it stops being an impression problem. A billing automation that double-fires charges a card twice. A payout flow that retries pays a vendor twice. "The system ran again" is not a sentence you get to say to a customer whose card you hit for four hundred dollars they did not authorize a second time. It is not a defense that survives a chargeback, and it is definitely not one that survives them telling forty people.
A demo can only show you the run that worked. It cannot show you the run that ran again.
The fix has a boring name. Idempotency. It means the automation is built so that running it twice with the same input produces the same result as running it once. The second fire recognizes "I already handled this exact event" and quietly does nothing. You do it with a unique key on each event, a dedupe check before the action, a record of what has already been processed. It is a few hours of unglamorous plumbing, and it is the difference between a tool you can trust and a loaded gun pointed at your customer list.
So why does almost nobody build it in? Because it demos as nothing. When a vendor shows you the flow in a meeting, they submit the form once, on good wifi, on clean test data, and it works beautifully. The guard against double-firing, by definition, only does something on the second run, which they are never going to trigger in a fifteen-minute demo. It costs the builder real hours and it makes the sizzle reel look identical. The incentive is to skip it and hope you never find out, and most of the time you find out from an annoyed customer, not from them.
Here is the ammunition, and it is one question. Before you sign anything, ask: "What happens if this runs twice on the same customer?" Then watch the face. If they immediately say "we use an idempotency key" or "it dedupes on the record, so a second run is a no-op," they have built this before and you can relax. If they say "oh, it won't run twice," you are done, because that is the exact sentence of someone who has only ever seen the happy path. It will run twice. The internet guarantees it. The only question is whether they planned for it or are going to learn about it from your bank.
And if you already have automations running, you can test this yourself in about a minute, no developer required. Submit the same form twice, fast, like a real customer on a bad signal would. Then go look. One record and one message, you are fine. Two of everything, you just found the bug before your customer did, which is the only good day to find it.