Win-back
When to use it
Section titled “When to use it”- You can tell someone is active from one event (an order, a login, a lesson, a visit).
- You want to reach people before they're gone for good, without messaging active people.
Where the data comes from
Section titled “Where the data comes from”| How | What |
|---|---|
| Events from your app or website (needs a developer) | Your store or app sends the activity event. |
| A CSV upload | Or import your orders or visits as events from a CSV or a synced sheet, one row per visit. |
What it sets up
Section titled “What it sets up”| Kind | Name | What it does | Lands |
|---|---|---|---|
| Team | Customer success | Calls people who didn't respond. | Empty |
| Segment | Gone quiet | Active within the last year, nothing in the quiet window. | Ready |
| Template | We miss you (email) | First win-back email. | Ready |
| Template | Still there? (email) | Second win-back email. | Ready |
| Follow-up | Win-back | Two emails and an optional call; leaves as soon as they're active again. | Off |
The questions it asks
Section titled “The questions it asks”| # | Question | Default | Fills in |
|---|---|---|---|
| 1 | What should messages call your organisation? | none, must answer | org_name |
| 2 | Which event means someone is active? (order, login, visit…) | Order Completed | active_event |
| 3 | After how long without it is someone "gone quiet"? | 60d | quiet_days |
| 4 | Where should the "come back" button go? | none, must answer | come_back_url |
| 5 | Should your team also call people who don't respond? | No | call_task |
Other settings
Section titled “Other settings”These have defaults. Change any that don’t fit.
| Setting | Default | Key |
|---|---|---|
| Sender address | ‹workspace default_sender› | email_from |
| Counts as "used to be active" within | 365d | active_window |
| Team that calls | Customer success | caller_team |
| Second email after the first | 5d | second_message_delay |
| Greeting when a first name is missing | there | greeting_fallback |
Timings
Section titled “Timings”- People enter the sequence when they've had no Order Completed for 60d.
- First email straight away, second email 5d later, then (if switched on) a call task due in 3 days.
- Re-entry at most once every 90 days.
Channels
Section titled “Channels”| Channel | Needed for | Before it can send |
|---|---|---|
| The two win-back emails | A verified sending domain for ‹workspace default_sender›. |
What you need to do
Section titled “What you need to do”- Send Order Completed from your app or store each time someone is active.
- Verify the sending domain.
- If you switch the call task on, add people to the Customer success team.
- Note: a quiet-since rule only counts from when the segment is saved, so the first people enter after 60d.
- Check the segment's size before switching the follow-up on.
This playbook is synthesized: no customer has run it with us yet. If you build it, tell us what you changed, and we’ll replace it with the real version.
Copilot eval
Section titled “Copilot eval”The request used to test the copilot on this playbook (a live eval):
Win back customers who used to order from us but haven't in 60 days. Send a we-miss-you email, then another one five days later, and stop as soon as they order again.
It passes when every piece is a valid draft and everything lands off, with at least: segment, workflow, message_template.