Automation

Re-engage users who've gone quiet

A scenario prompt that converts a described inactive-user re-engagement workflow into a recipe, resolving inactivity-definition, escalation, and win-back-offer edge cases.

Works with Claude / GPT550 uses 4.2

The prompt

automation-re-engagement-inactive-users
A membership site describes their process like this: "If a member hasn't logged in
for 30 days, I want them sent a 're-engagement' email checking in, and if they still
haven't logged in 14 days after that, a follow-up email with a win-back offer before
we consider them churned."

AVAILABLE TOOLS: [Membership login-activity data (trigger), Uncanny Automator,
email/SMTP, membership platform tagging]

Turn this into an implementation-ready automation recipe, thinking through what the
plain description leaves ambiguous:
1. Trigger: a daily scheduled check against last-login timestamps, and the exact
   definition of "hasn't logged in," specifically whether opening a login-required
   email link counts as activity even without a full session, since that distinction
   changes who qualifies as inactive.
2. Conditions: state the exact logic for excluding members who are inactive because
   their subscription is on a paused or gifted plan rather than genuinely
   disengaged, since re-engaging someone who's paying but on vacation reads as
   tone-deaf.
3. Actions in order: tag the member "at-risk" at day 30 before sending the first
   email so the state is queryable elsewhere, send the check-in email, then at day 44
   check whether they logged in during the gap before sending the win-back offer, not
   just whether 14 days have passed on a fixed schedule.
4. Failure handling: if the win-back email includes a discount code and the coupon
   system fails to generate one, should the email send anyway without an offer, or
   should it hold until the code exists, given that a broken or missing code in a
   "come back" email undermines the whole point of the send.
5. One edge case specific to this exact workflow: a member who logs in exactly on day
   30, the same day the check would fire. Decide whether same-day activity should
   count as still-active and skip the email that cycle.

Replace the workflow description and available tools with your own.

Re-engagement sequences fail quietly when the “still inactive” check at the second touchpoint is a fixed timer instead of a fresh activity check, since that’s how a member who came back on day 35 still ends up getting a “we miss you” email on day 44. Building the re-check into the second step is what separates this from a generic drip.