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.
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.