Inactive Customer Re-Engagement Template: Offer a Clear Choice

An inactive customer is not automatically a lost sale. They may have completed their task, moved to another channel, paused for a valid reason, or no longer want contact. Re-engagement should offer a useful choice and update the relationship state—not manufacture urgency.

This template is broader than an ecommerce purchase win-back: it covers a documented service, membership or account relationship where “active” has an owner-approved meaning.

Copy and fill this re-engagement record

Relationship/account ID and type:
Definition of active and inactive:
Last verified meaningful event/date/timezone:
Current service/account state:
Permission, preference and identity checks:
Exclusions and suppression:
Useful current reason/source:

Evaluation trigger:
Message purpose and approved fields:
Choices: [continue] [change preference] [pause/close] [help]
Response and owner route:
Exit and re-entry events:
No-response state:
Completion evidence:
QA owner and review cadence:

Estimated completion time: 30–40 minutes after relationship, permission and preference policies are defined. Copy the record into the workflow or account-health document, replace every field, then save or export the approved version with query version, source dates and owner.

Field guidance

  • Define meaningful activity for this relationship; opening a message may be weaker than completing a task, using a service or explicitly confirming interest.
  • Verify the account is still valid and reconcile duplicate identities before contact.
  • Give a current useful reason based on an approved source, not a speculative score or generic company news.
  • Offer a preference update, pause or close route as clearly as the continue route.
  • Close no-response records visibly and require a new eligible event before re-entry.
  • Store the last meaningful event with exact date/timezone and source version.
  • Reconcile current service/account state so closed, disputed or vulnerable cases are excluded.
  • Evaluate permission, preference, identity and suppression as distinct checks.
  • Run a versioned trigger that records why the account is eligible on that date.
  • Allowlist message fields; route HELP and consequential account questions to an accepted owner.
  • Define all exits/re-entry events and store eligibility, source, response and final state for QA.

Salesforce publishes vendor documentation for an inactivity-triggered re-engagement process. It is evidence that this workflow pattern exists, not support for its example timing, a result claim or feature parity in Easy AI. Review the vendor page.

Fictional filled example: training membership account

Relationship/account ID and type: M-302; fictional business-training membership
Definition of active and inactive: Active means the member completes a session, saves a learning plan or explicitly confirms the next topic; inactive means no such event during the owner-reviewed 75-day window
Last verified meaningful event/date/timezone: Learning-plan save on 1 June 2026, 09:20 ICT (UTC+7)
Current service/account state: Membership remains valid; no billing/service dispute
Permission, preference and identity checks: Identity match verified; service email permitted
Exclusions and suppression: No opt-out, complaint, vulnerable-case flag or duplicate account
Useful current reason/source: Revised orientation guide for existing members, version OG-4, approved 15 August 2026

Evaluation trigger: Daily evaluation against query version Q-6
Message purpose and approved fields: Offer the revised guide and relationship choices using account status, guide version and approved options. Message: “Your membership is still available. Would the revised orientation guide help you choose a next topic? You can view it, change email preferences, pause these reminders, or ask for help.”
Choices: View guide / update preference / pause / HELP
Response and owner route: Store explicit choice; HELP or ambiguous account issue routes to member-support owner Hoa
Exit and re-entry events: Exit after any choice, new meaningful activity, opt-out, contact failure, account closure, dispute or owner pause; re-enter only after a new explicit request or policy-approved meaningful event
No-response state: Close after this one message; preserve channel preference
Completion evidence: Eligibility snapshot, query/source versions, message, response and final state stored
QA owner and review cadence: Service owner reviews false inactivity, identity errors, complaints, preference writes and reopened cases monthly

Every account, person, date and window in this example is fictional. The 75-day value is illustrative and must not be copied as a benchmark.

Quality checklist

  • Active/inactive definitions are observable and owned.
  • Account validity, identity and current service issues are reconciled.
  • The message offers a useful current resource or choice.
  • Preference, pause, close and help routes work before launch.
  • No-response closure does not erase channel suppression.
  • Reporting distinguishes reactivation, preference updates, help cases and complaints.

Common mistakes

Mistake Safer correction
Calling email opens meaningful activity Choose an event that reflects the relationship job.
Contacting an inactive duplicate or closed account Reconcile identity and account state first.
Offering only “come back” Include preference, pause/close and help choices.
Repeating the sequence on a timer Require a new eligible event after visible closure.

What to do next

Copy the record into a document and fill the relationship, last meaningful activity, and contact-permission fields first. Send HELP responses into the unresolved-conversation workflow; write explicit preference changes to the source record and stop obsolete actions.

Evidence and limitations

This template does not define consent, a universal inactivity period, account policy, retention lift, product integration, or Easy AI capability.

FAQ

Recommended for you