Skip to main content
DoneThat

AI Adoption GuideBankingClose

Winback timing prediction

ML predicts the optimal re-contact window post-closure by segment and stated reason, producing a prioritized re-engagement queue.

Banking processAcquireOnboardOpenFundTransactServiceReviewClose

By Don, DoneThat’s AI coach · updated

A predicted window is a recommendation with a citation

The useful output is not a campaign. It is a ranked queue of closed customers, each with a proposed re-contact window and a cite back to the reason they gave when they left. Treat that row as a timing suggestion a person must accept, change, or suppress. It is not a sale and not permission to reopen a relationship they already ended.

Prediction belongs after eligibility is known. The customer closed, they have not opted out of marketing or of this product family, and there is a recorded reason specific enough to time a conversation. If those are not true, do not rank a window. Ranking a date for someone who must not be contacted is a quality failure.

The cite makes the queue usable. A window of "wait several weeks, then discuss a fee review" is defensible only if the closure reason mentioned fees. If the record says they moved, or asked not to be called, the same window is the wrong action. Later work such as churn-to-win-back targeting can consume the queue. It cannot invent the reason.

Use the classified reason before you pick a date

Timing is reason-dependent. A close after a better rate elsewhere is not in the same cooling-off world as a service failure, a move, or a complaint about contact volume. The model input is the classified reason, not a free-text guess and not a lookalike of people who later returned. If classification is weak, pause and fix closure reason classification. A precise window on a vague or invented reason still produces the wrong conversation.

Do not invent a reason the customer did not give. If the note is "leaving the country," you may not recode it as price sensitivity because price-sensitive customers sometimes return. If the note is blank, the queue should say so: no cite, no commercial offer, suppress or send to manual review. Blank is not an invitation to impute.

Reason also constrains the offer attached to the window. A fee-related close can support a later tariff conversation if policy allows. A rate-shop close can support a later rate conversation if they did not opt out. A "stop contacting me" close supports no window. A close because the product is no longer needed usually needs long suppression, not a nurture track.

If the relationship was still live, pre-closure churn interception is the earlier control. Winback timing starts only when the product is actually closed.

Cooling-off rules that block the queue

The model ranks among customers who are allowed to be contacted. Cooling-off is a rule layer, not a feature of the scorer. Blocks include marketing opt-out, product-family opt-out, do-not-call or complaint-driven restrictions, legal quiet periods after some complaint outcomes, and a minimum quiet period after closure that varies by reason class. If any block is present, the row is not actionable. Suppress it, or show it as ineligible with the blocking rule named.

Quiet periods should be reason-class defaults a human can widen, not shrink below policy. A service-failure close usually needs a longer quiet period than a rate-shop close. A harassment or "too many calls" close should hard-block outbound for that relationship, not merely delay it. Treating a harassment complaint as "later is better" is how winback programs create new complaints.

Channel restrictions travel with the window. Email-only consent is not call consent. A proposed call for a customer who only allowed post is a policy error. Store the allowed channel next to the date range so the owner does not just try a call.

Do not use lookalike audience generation to refill a suppressed row. Similarity to customers who returned does not override opt-out, cooling-off, or a stated reason that forbids the pitch.

Rank the window, then hand it to a person

For each eligible closure, the model proposes a window (earliest, latest, preferred channel) and a rank versus waiting or suppressing. Rank is relative inside the eligible set. It is not a probability of sale and must not be labeled as one. The human owns the contact: they confirm the cite, confirm consent, and book the window, extend it, or drop the row.

Work rank order only after filters. A CRM lead should see eligible, not opted out, cooling-off complete or approaching, cite present, proposed window, and the verbatim or classified reason. Anything missing those fields is not ready for outreach.

Illustrative path, not a measured case: a current account closed eleven days ago. The classified reason is "fees after the last tariff change," and a short staff note matches. Policy for fee-related closes sets a three-week quiet period and allows a later fee-review conversation, not a cross-sell. The queue proposes a window in the fourth to sixth week, letter then an inbound-capable call, offer type fee review only. The manager reads the cite, checks consent, and accepts or delays if another product has an open complaint.

If the same row came from a note that the customer left because of persistent calls, the correct behavior is no window. If the model still emits "week four, fee review," a person must reject it. Quality is the cite matching the action, not dial volume.

Failure modes that turn a winback into a complaint

Calling someone who complained of harassment is the first failure. Contact-volume complaints are a stop, not a timing problem. If case history shows harassment, aggressive collections language, or an explicit do-not-call, the row is ineligible. A high rank does not weaken that rule.

Offering a product they closed for a better reason is the second. A customer who emigrated does not need an "improved app" call in week six. A customer who closed savings after a better rate elsewhere should not be pitched a credit card in the winback window. The window inherits the reason. A different product is a separate, consent-checked campaign, not this queue.

Ignoring opt-out is the third. Opt-out in the CRM, preference center, or complaint system wins over any predicted date. Refresh consent at queue build time, not from a stale weekly extract. If consent was withdrawn after scoring, drop the row before anyone dials.

A fourth failure is treating the queue as a sales list. Scoreboards that reward contacts, not appropriate contacts, push people to ignore cites. The operating measure is quality: queued rows with a valid cite, rows suppressed for opt-out or complaint, and accepted windows that stayed inside the allowed offer type. Conversion, if tracked, does not define a good queue.

What Salesforce and Temenos already hold

CRM-class platforms such as Salesforce typically hold consent, complaints, campaign membership, and the contact owner. Core-banking-class platforms such as Temenos typically hold close date, account status, and whether other products remain live. The model should read those facts. It should not duplicate them or invent a close reason neither system recorded.

Keep the proposed window next to the cite in the work object the human already uses. Dates without a reason are how people just call anyway. When the owner accepts a window, write the decision back: accepted, delayed, or suppressed, with a short note. That feedback catches models that still rank forbidden reason classes.

If the core says the product is still open, this is not winback. If the CRM says opted out, there is no window. If neither system has a reason, do not guess. The queue remains a proposed window, a cite to the closure reason, and a person accountable for the contact.

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