AI Re-Engagement Playbook: Reopen Only with a Valid Reason

Time passing does not create renewed interest. An unanswered enquiry, a declined evaluation, an out-of-scope request, and a buyer-agreed review date need different treatment. Start with one closed record and fill the card below. Reopen it only when a current, permitted reason supports one useful choice.

Start with the re-engagement card

Original request and closing reason:
Current reason to review now:
Source and date checked:
Contact permission and channel:
One useful choice for the customer:
Person who owns a reply:
Stop and close conditions:

First action: copy the card into a document or CRM note and write the original closing reason. If the reason is unknown, do not guess it from silence.

Completion standard

• Start state: a defined inactive cohort has a recorded reason, current identity, owner, and permission.
• End state: accepted next action, human-owned clarification, explicit close, or completed no-response closure with all tasks cancelled.
• Evidence: cohort rule/version, change signal, source, permission, message approval, handoff acceptance, and final reason.
• Time horizon: one approved re-engagement window; re-entry requires new eligible evidence.

Roles and prerequisites

Before launch, define cohort-specific entry and exit, allowed evidence, expiry, per-channel permission, current sources, maximum action, no-response close, reply detector, backup owner, rollback, baseline, and thresholds.

In a small team, the record owner may also manage cohorts and approved content. A separate specialist is needed only for a material technical, commercial, or legal question; always name a backup for customer replies.

Phase 1: classify the inactive state

• Owner: RevOps.
• Inputs: last disposition, event history, identity, owner.
• Actions: place the record in one mutually exclusive cohort; preserve the reason and unknowns.
• Output: versioned cohort or ineligible state.
• Exit gate: state and original reason are traceable.
• Escalation/rollback: quarantine conflicts/duplicates; never infer a lost reason from silence.

Phase 2: verify a relevant change

• Owner: record owner; domain owner verifies material updates.
• Inputs: cohort, buyer-agreed date, customer event, or current approved change.
• Actions: test relevance, freshness, source, and whether the change resolves the recorded barrier.
• Output: eligible signal packet or no-action.
• Exit gate: evidence is current and cohort-specific.
• Escalation/rollback: expire unsupported/model-only signals; return the record to closed state.

Klaviyo documents a vendor win-back flow based on defined inactivity. This supports a trigger mechanism, not cadence or outcome.

Phase 3: approve one useful choice

• Owner: record owner.
• Inputs: signal packet, current permission, approved content.
• Actions: state the new context, offer one relevant choice plus close/decline, and remove urgency claims.
• Output: reviewed action or manual route.
• Exit gate: content matches the cohort, channel, source, and authority.
• Escalation/rollback: domain owner removes stale claims; commercial/legal exceptions stay human-owned.

Phase 4: execute and reconcile

• Owner: record owner; RevOps owns event reconciliation.
• Inputs: approved action and live events.
• Actions: recheck reply, booking, service issue, opt-out, owner activity, and delivery before sending.
• Output: send, cancel, or accepted handoff.
• Exit gate: no newer event conflicts and any buyer reply has an owner.
• Escalation/rollback: cancel queued actions on lag/conflict; preserve prior close state.

Phase 5: close and review cohorts

• Owner: RevOps and record owner.
• Inputs: outcomes, delivery, corrections, complaints, handoffs.
• Actions: close on decline/no response under policy, retain opt-outs, sample quality, and decide keep/pause/retire by cohort.
• Output: reconciled close and cohort decision.
• Exit gate: no pending task and final reason is observable.
• Escalation/rollback: pause a cohort that breaches permission, correction, complaint, or ownership threshold.

Fictional completed run

A fictional services company reviews three cohorts: 30 unanswered information requests, 12 declined evaluations, and 8 out-of-scope requests. RevOps finds only nine eligible records: four have an explicitly requested follow-up month, three now match a newly approved service boundary, and two submitted a fresh request. Owner Amina sends cohort-specific context and a close option. One reply asks a technical question and specialist Jo accepts the handoff; two people decline and close; remaining actions close after the approved window. No record is reactivated merely because time passed, and no conversion result is claimed.

• Original request and closing reason: Nine fictional records retain their own unanswered, declined, or out-of-scope reason
• Current reason to review now: Four agreed review dates, three approved service-boundary changes, and two new customer requests
• Source and date checked: Original records and current approved service source checked 15 August 2026
• Contact permission and channel: Checked separately for each record before contact
• One useful choice for the customer: Review the relevant change or close the request
• Person who owns a reply: Amina; specialist Jo accepts the technical question
• Stop and close conditions: Decline, opt-out, service conflict, invalid contact, or end of the approved no-response window

Handoff, QA, and measurement

QA checks: mutually exclusive cohort; recorded reason; relevant current change; channel permission; one useful choice; close route; live reconciliation; accepted reply owner; final cancellation.

Failure signals include cohort overlap, reason inferred from silence, stale “news,” low owner acceptance, opt-out breaches, and repeated contact after close. Pause the cohort, correct evidence/ownership, and replay before resuming.

What to do after completion

Use the win-back signal guide to choose evidence, the lost-opportunity template for one closed-lost record, and the unresponsive-lead template for a close-the-loop sequence.

Evidence and limitations

No response, pipeline, conversion, recovery uplift, integration, prediction, or Easy AI capability is claimed.