The Best Automation Ends With A Human, Not An Email
A card expires. The payment fails. The subscription lapses.
Nothing happens, because nothing was built to happen. The business records a cancellation and moves on.
The customer never decided to leave. They are not aware anything has ended. And that revenue is now filed under churn, which is a category for people who chose to go.
Is a failed payment the same as churn?
No, and treating them as the same is why so little is done about it.
Real churn is somebody choosing to stop. They evaluated, decided the thing was not worth the money, and left. That is a product or a value problem and it is hard to reverse.
A failed payment is an administrative accident. A card expired, a bank declined a transaction, a limit was hit. The customer liked the product enough to keep paying for it right up until a piece of plastic stopped working.
The second category is recoverable in a way the first is not, and most businesses have no process for it at all because it never appears as a distinct number. It arrives at the end of the month inside the churn figure, indistinguishable from people who left on purpose.
Why do dunning emails perform badly?
Because they read like a bill.
A templated notice about a payment issue with a link to update card details is functionally correct and emotionally wrong. It arrives sounding like a collections department, from a business the person had a warm relationship with ten minutes earlier.
On a business built around a personal relationship with the founder, that tone is worse than sending nothing. It converts a neutral administrative event into a small negative interaction, and it does it at the exact moment somebody is deciding whether this relationship is worth the friction of finding their new card.
What does a human response to a failed payment look like?
On Your Parenting Mojo, a parenting education business founded by Jen Lumanlan, it looked like this.
A declined payment in Ontraport triggered a Zapier workflow. That workflow created a task so somebody knew it had happened, and triggered a Bonjoro request so the follow up went out as a short personal video from the founder.
The customer with the expired card receives a video from the person whose podcast they listen to, saying their payment did not go through and here is how to fix it. Same underlying event, entirely different message.
Around one in ten failed payments came back.
That figure is worth reading carefully. It is not ten percent of subscribers and it is not ten percent of revenue. It is ten percent of the payments that were already gone: transactions the business had written off, from customers who had not chosen to leave and were not going to be contacted about it. On recurring revenue that compounds, because a recovered subscriber does not pay once.
The 10% is my recollection from when I was working on that account rather than a report I can produce, which is worth stating.
When should automation replace a person, and when should it fetch one?
The default use of automation is replacement. Send the email nobody has time to send, at scale, forever. That works for reminders, confirmations and anything where the message genuinely does not need to be from a person, and it is why most automation output reads like it came from a machine.
The more valuable pattern is the opposite: use automation to catch the moment, then put a person in it.
Nobody can monitor payment failures manually. It is invisible, unpredictable work that never rises to the top of anyone's list. But once a system is watching for it, the response does not have to be automated at all. A workflow that ends with a founder recording thirty seconds of video is still automation. The machine did the part machines are good at, which is noticing, and stopped before the part it is bad at.
The same logic runs through a merchant services build on Infusionsoft, now Keap, where the automation created sales tasks for a person at the moments the process required a human, rather than sending another email and hoping. A sales person opens their list and it is already correct.
Where else does this pattern apply?
Anywhere the detection is hard and the response benefits from being human.
A course member who has not logged in for three weeks. No person will notice. A system will, and what it should trigger is a message somebody actually wrote.
A high value customer who opened everything and bought nothing. The detection is trivial for a system and impossible for a person watching a list.
A refund request. Almost always handled by a template, almost always the moment where a conversation would have changed the outcome.
An inquiry that arrives at 9pm on a Saturday. The response can be automatic and warm, and the human follow up scheduled for the moment somebody is actually available.
In each case the rule holds: automate the noticing, think carefully about whether to automate the responding.
How do I know if my automation is doing the wrong half?
Three questions, and the third one gives you a number.
1. What happens when a customer's card is declined?
Not what should happen. What actually happens today.
2. Of everything your automation sends, is there anything a real person would be glad to receive?
If every workflow ends in a template, the machine is doing both halves.
3. What share of last month's churn was involuntary?
Most businesses cannot separate the two. That separation is the number, and it is usually larger than anybody expects.
A Decision They Never Made
Nobody cancels because their card expired.
They just stop, and the business writes it down as a decision they never made.
If your automation ends every workflow with an email, there are probably one or two moments in your business worth handling differently.