Define inactivity in product terms, send a relevant reason to return, and recheck eligibility before each win-back message.
A win-back email is for someone who used to get value from the product and stopped. The difficult part is knowing what stopped, and whether you have a credible reason to ask them back.
"We miss you" is a sentiment. A fixed problem, useful feature, or relevant offer is a reason.
Use an action that reflects the product's job: a completed order, successful sync, published project, or campaign sent. Choose a window that makes sense for the normal usage cycle.
An annual buyer and a daily operator should not share the same inactivity rule. Neither should be classified as inactive solely because an email tracking pixel did not load. Open rates are too weak for that decision.
Keep marketing permission and suppression status in the eligibility check. Being a former customer does not override an unsubscribe.
I would rather send a short note about the particular issue that blocked someone than a long recap of the roadmap. Use the customer's known context carefully, and do not claim to know why they left unless they told you.
An illustrative message could say:
You previously asked for [specific capability]. It is now available on [applicable plan]. Here is how it works, including [important limitation].
If that was the thing blocking you, you can try it here: [direct link].
Those are editorial placeholders, not live merge tags. Fill them with verified facts. If the feature does not apply to the recipient's account, the message needs a different reason to exist.
Decide how many messages you can justify and what new information each one adds. There is no universal rule that three touches is ideal. A second message that repeats the first with more urgency may not earn its place.
A discount should have real terms and an actual expiry. Do not imply that an account will be deleted unless that is true and appropriate to communicate in that message.
If the person returns, stop treating them as inactive. In a Brew event-triggered flow, a condition on contact.<name> reads the current Brew field when that node executes. Put the check after the wait and keep the field synced with meaningful product activity. Event payload values remain fixed.
If the activity or eligibility data lives outside Brew, have your application check it when a follow-up is due. Fire a fresh eligible event only for people who still qualify. The automation guide explains both approaches.
This also keeps a useful return visit from being followed by an embarrassing "We haven't seen you" email.
Review meaningful product activity, replies, complaints, and unsubscribes. Do not keep sending because the old customer record is still in the database, and do not suppress a currently active customer solely because opens are absent.
If the sequence produces no useful response, revisit the reason to return and the audience. More volume is not the default answer.
Use the deliverability guide when planning sends to an older audience. A win-back should make the relationship more relevant, including respecting the point at which someone no longer wants it.
