What is human-in-the-loop dunning?

Human-in-the-loop dunning is a failed-payment recovery model where automation handles the high-volume tail (low-value declines, simple retries) and a person handles the judgment calls (high-value invoices, VIP accounts, ambiguous declines) with full context attached. The software decides which failures need a human; the human decides what to say.

When should I stop automating failed-payment emails?

Stop automation when the invoice is high-value, the account is named/strategic, or the decline reason is ambiguous (do_not_honor, transaction_not_allowed, generic_decline). For low-value self-serve renewals on transient retry-able codes, full automation is the right tool.

How is human-in-the-loop dunning different from regular dunning?

Regular dunning fires a templated email sequence on every failure. Human-in-the-loop dunning classifies the failure first, runs the right playbook automatically for the easy cases, and escalates only the judgment calls to a queue where a person sees live payment state, account value, and history before they act.

What's the best tool for human-in-the-loop dunning on Stripe?

Chaser is purpose-built for it: a Stripe-native exception queue that holds high-value or relationship-sensitive failures back from automation and routes them to a person with full context. See the open playbooks for what runs automatically and what escalates.

Human-in-the-Loop Dunning: When Automation Should Stop

Human-in-the-loop dunning: when automation should stop

Most failed-payment recovery is fully automated: a card declines, a sequence of emails fires, and the system hopes. That works for a $40 self-serve renewal. It is the wrong tool for a $12,000 enterprise invoice that failed because procurement reissued a card. Human-in-the-loop dunning keeps automation for the volume and routes the judgment calls to a person, with full context attached.

What "human-in-the-loop" actually means

Automation handles classification, retries, and the long tail of low-value failures. A human handles the exceptions where the relationship is worth more than the invoice. The software's job is not to send more emails. It is to decide which failures a person should see, and to hand that person every piece of context (live payment state, history, account value) so they decide instead of diagnose.

Why pure automation leaks money at the top of your book

A templated "your payment failed, update your card" email is fine for a free-tier signup. Forwarded by a champion at your largest account, it reads as a debt notice and costs you relationship equity worth far more than the invoice. Involuntary churn is 20-40% of total churn (industry benchmark), and the highest-value slice of it is precisely the slice automation handles worst.

When to use human-in-the-loop vs full automation

Use full automation when: invoice value is low, the account is self-serve, the decline is a soft retry-able code. Use a human when: the invoice is high-value, the account is a VIP or anchor logo, a rep already has an open commitment, or the failure signals something other than a routine decline. A good system lets you draw that line by value, risk, or a VIP flag, and then enforces it.

What a human-in-the-loop system needs to have

Routing rules that segment every failure before a person sees it
An exception queue, not another inbox: each row pre-classified by root cause
Full context on the row: live payment state, prior messages, account value
A stagnation safeguard so nothing rots unresolved
Write-back to your ledger so finance has a record, including the losses

How Chaser implements it

Chaser, the Stripe-native failed-payment recovery tool, runs smart retries and classified playbooks automatically, then escalates only the judgment calls to a command center where each row arrives pre-classified with live Stripe state and full history. You define what deserves a human by value, risk, or VIP flag. Anything unresolved for 48 hours escalates to the workspace owner. Every outcome, recovered or lost, is written back to Stripe.