AI Adoption GuideInsuranceBill
Failed payment recovery sequencing
Agent sequences payment retries and reminders across channels based on policyholder history and billing rules.
Insurance processQuoteUnderwriteBindIssueBillServiceRenewClaim
By Don, DoneThat’s AI coach · updated
Cite the failed payment, the billing rule, and the history vintage
A retry or reminder is ready to send only when it cites three facts: the failed payment, the billing rule that authorizes this contact, and the vintage of the policyholder history used to choose channel and timing. If a cite is missing, that field stays empty. Billing still sends. The sequence does not auto-lapse. The sequence does not invent a retry count.
The failed-payment cite points at one returned ACH, declined card, or rejected debit: fail id, fail code, amount that failed, and posting date. It does not point at a rolling balance that may include later charges. The billing-rule cite names the rule that allows this wait, this same-instrument retry, or this reminder. The history vintage is the as-of date of the extract that holds prior pays, prior fails, and prior contacts. Without vintage, a preferred channel is an undated claim.
These cites are how a billing lead audits the queue. A retry with no rule cite is the common leak. The notice goes out on "the usual NSF path," and later nobody can show whether day-two SMS or day-seven letter was allowed. Treating the sequence as a lapse is the second leak. Silence after a reminder is not a cancel instruction. Inventing a retry count is the third. If the rule file does not state attempts already run or attempts remaining, the count field stays blank. Filling "2 of 3" from habit creates a record you cannot defend.
Load the fail and the rules before you sequence
Load the failed payment first. You need policy, installment or invoice, failed amount, instrument, fail code, and timestamp. If the amount or invoice looks inconsistent with what billed, pause long enough to run the fail against billing invoice anomaly detection. Sequencing recovery on a bad bill still sends a notice. It just recovers the wrong charge.
Load billing rules second. Policy admin and billing platforms such as Guidewire and Duck Creek, and customer or contact layers such as Salesforce and Genesys, typically hold pieces of the fail, the rule, the history, and the send path. Treat them as a class of systems of record and of send. Do not rank them. Do not assume a branded retry engine or a default attempt cap. Read the rule that applies to this fail code, product, payment-plan flag, and jurisdiction. If that rule states a wait, a same-instrument retry, a channel restriction, or a count, copy that language into the sequence. If it does not state a count, you do not write one.
Load policyholder history with an explicit vintage. History is prior outcomes and contacts, not a score of the person. Note which channels delivered, which the policyholder used inbound, and which failed. Stamp the extract date. If history is missing or older than the rule allows you to trust, leave the channel field empty unless the billing rule already names a channel. Do not backfill a preferred channel from an undated notepad line.
Sequence retries and reminders with the three cites on every step
Order the steps from what you loaded. The usual shape is wait, retry the instrument if the rule allows, then remind on a channel the vintage supports. Every step carries the three cites. The retry names the fail, the rule, and the vintage. The reminder names the same three. If a later step wants a count the rule never gave, omit the count.
One illustration. A personal auto monthly installment returns NSF on the 3rd. The billing rule on file allows a same-instrument retry after two business days when the fail code is NSF and the account is not on a payment arrangement. The contact history extract dated 1 March 2026 shows the last outbound billing notices the policyholder opened were email, and the last inbound billing question arrived by phone. The sequence is: wait two business days; retry the same ACH, citing fail PAY-88421, rule NONPAY-RETRY-NSF, history vintage 1 March 2026; send an email reminder that the retry is scheduled, citing the same three. The packet does not say attempt 2 of 3, because the rule file does not give a remaining count. Billing sends the retry and the reminder. If the policyholder calls after the email, that inbound work belongs with a billing inquiry voice agent. It is not a reason to rewrite the reminder as a cancel warning.
If the rule record had been missing, the retry would still send, and the rule-cite field would be blank. Supervisors can see the hole. They should not treat the hole as a documented NSF path.
Do not morph a mid-term installment reminder into renewal copy. Renewal language belongs on personalized renewal communication. A failed installment inside the term is bill recovery.
Leave blanks empty and let billing send
Empty stays empty. Missing rule cite: blank. Missing vintage: blank. Missing fail id: blank. You should not have built a sequence without a fail id, but if billing already queued a notice, you still do not fabricate an id. Billing sends. The agent refuses invention. It does not refuse the queue.
This is not a completeness gate that drops the send. Dropping the notice because a cite is missing creates a second recovery path: someone in the contact center improvises. Sending with a blank cite keeps the policyholder on the recorded channel and shows operations which control failed. Fix the load. Do not invent the cite on the way out.
A blank count must not become a made-up count. "We always try three times" is not a billing rule unless it is written as one for this product and fail code. A sequencer that prints 3 so the template looks finished has created evidence that will be wrong in a complaint file or a later lapse dispute.
Keep auto-lapse and cancel language off the packet
A recovery sequence is not a lapse. Do not put cancel-effective dates, policy-will-end framing, or last-notice language on a retry or reminder unless the billing rule you cited is itself a statutory cancellation notice, with those cites. If it is not, keep lapse language off the packet. When you need a separate view of who may walk after non-pay, use lapse propensity scoring. That evaluation must not auto-lapse and must not fill a retry count.
The attractive failure is organizational. The same team owns non-pay and cancel, so the last reminder becomes the cancel. That is how a retry with no rule cite gets dressed as a legal notice. Keep the roles split. Billing sends the cited retry and reminder. Lapse, if it happens later, follows the lapse process with its own documents and timing.
If history vintage shows the policyholder only responds on voice, that still does not authorize a contact platform to read a cancel script. It authorizes a channel choice on a recovery notice, cited to that vintage. Guidewire, Duck Creek, Salesforce, and Genesys remain systems that hold data and send work. In this use case none of them is asked to declare the policy dead.
Before send, check six things: fail id present or explicitly blank; rule cite present or explicitly blank; vintage present or explicitly blank; no invented attempt fraction; no lapse clause unless the cited rule is a cancellation notice; billing, not the sequencer, is the sender.
Is this worth automating for you?
Whether this pays back depends on how much time it takes your team today. Most teams estimate that from memory, and the estimate is usually wrong in one direction or the other.
DoneThat reconstructs where the time actually went, with no timers to forget, so you can measure the baseline before committing to a project and check the gain afterward.
Measure the baseline first