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

Role	Owns	Approves	Receives handoff
RevOps	Cohorts, eligibility, suppression	Rule changes	Data conflict
Record owner	Customer context and response	Final outreach	Buyer reply
Domain owner	Material update evidence	Claims/exceptions	Specialist question
Sales manager	Handoff coverage	Backup assignment	Owner timeout

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. Review the source.

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

Trigger	Owner and timing	Context and fallback
Permission or identity conflict	Operations owner, before action	Keep record IDs, source, and channel; stop that record
Material update question	Domain owner, before reply	Keep the original barrier and source version; state the limit
Customer reply timeout	Sales manager, within the team target	Keep the reply and full card; assign a backup

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

Metric	Definition	How the team uses it
Eligible-signal rate	Records with a verified relevant change / records reviewed	Operations owner reviews weekly against the pre-pilot audit and sets the launch threshold
Coherent-action rate	Actions without a stale or conflicting event / actions executed	Operations owner reviews weekly against the pilot and uses a pre-set pause threshold
Accepted-response rate	Replies accepted in time / customer replies	Sales manager reviews weekly against the pilot and sets the launch threshold

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.