Customer Win-Back & Membership Recovery

Customer Win-Back & Membership Recovery

Win back the customers you already earned — and stop losing the ones a bounced card would have quietly cancelled.

Customer Win-Back & Membership Recovery fuses the two highest-ROI retention plays a local business has into one app:

• Voluntary win-back — lapsed regulars who simply drifted away get a warm "we've missed you" call that makes a comeback offer and books the return visit on the spot.
• Involuntary churn rescue — the moment a member's card is declined, an agent calls to fix the card before the membership lapses by accident.

Built on the Telenow App Platform as a pure declarative app: the data model, the agent tools, the Stripe webhook, the recovery workflow, both vernacular-friendly agents, and the win-back playbook all run on-platform. No external server.

The problem (and the number)

For salons, gyms, spas, clinics, and restaurants, the cheapest revenue on earth is the customer you already have. Reactivating a past customer costs roughly 5–7× less than acquiring a new one, and past customers convert at 20–40% versus 5–20% for cold prospects. Yet most SMBs let dormant regulars quietly fade and let "failed payment" emails go unopened — and a huge share of membership cancellations are never even chosen: they're involuntary churn from an expired or reissued card. Customer Win-Back & Membership Recovery attacks both leaks with a phone call, the one channel that still books.

How it works

                     VOLUNTARY WIN-BACK                         INVOLUNTARY CHURN RESCUE
  client list ──► dormant queue (by days-since-visit)      Stripe ──(charge.failed webhook)──► stripe_failed hook
        │                    │                                   │                                    │
        │        launch a bulk campaign over the             dedupe on phone                 failed_payment row
        │        dormant view (app-campaigns API)                │                        fires object.failed_payment.created
        ▼                    ▼                                   ▼                                    ▼
   Call now (per row)   win-back agent dials each          send_card_link (WhatsApp)        card_recovery workflow
        └──────────►  find_client → "we've missed you"      secure update-card link          ├─ delay ~2 min
                       offer → book_return / mark_lost                                        └─ outbound-call {{settings.recovery_agent_id}}
                       → log_outcome                                                   ├─ flag membership failed_payment
                                                                                                    └─ dials {{trigger.data.phone}}
                                                                                                       → card-recovery agent
                                                                                    find_membership → update card → mark_recovered / mark_churned

Everything the agents do on a call updates the same rows you see on the dashboard — and the Call now buttons on the Clients and Memberships pages dial the very same agents and tools.

Two paths, by design

• Dormant win-back is a campaign. It's a batch sweep over the client dormant view, launched at runtime via the app-key campaign API (below) — not a per-row workflow. That's the right shape for "dial my whole backlog."
• Card rescue is declarative and real-time. A single decline should trigger a call within minutes, so it runs as an inbound hook → workflow with zero code.

Agent tools (used mid-call — all declarative)

Both bundled agents are multi-context flows: a deterministic lookup tool node (find_client / find_membership, looking the caller up in this app's data) → a conversation node that makes the offer / fixes the card and sets status.

Dashboard pages

• Customer Win-Back & Membership Recovery (dashboard) — KPI tiles (recovered revenue, win-back rate, saved memberships, dormant clients, cards to rescue), a client-status mix bar, the longest-gone dormant clients, and recent call outcomes. Also powers the platform dashboard_widget slot in a compact form.
• Clients — the dormant win-back queue sorted by days-since-visit, with status filters, search, and per-client Call now (dials the win-back agent with the client's context).
• Memberships — the failed-payment rescue queue with the at-risk amount per member and per-member Call now (dials the card-recovery agent).
• Setup — configuration checklist, one-click Create agent for both bundled agents, and the post-install wiring steps.

Knowledge base

winback-playbook ships four real scripts both agents answer from: the "we've missed you" comeback offers, the card-update rescue script, retention talking points, and objection handling for win-back calls.

Install & post-install wiring

1. Install Customer Win-Back & Membership Recovery into your org.
2. Open Setup and click Create agent for both the win-back agent and the card-recovery agent (each auto-wired to the tools + playbook).
3. Copy each new agent's ID into the app's settings: Win-back agent ID (winback_agent_id, required) and Card-recovery agent ID (recovery_agent_id).
4. (Optional) Set Dormant threshold (dormant_days, default 90) and WhatsApp channel ID (wa_channel) to auto-text the secure update-card link on a decline.
5. Point a Stripe charge.failed (or invoice.payment_failed) webhook at the app's stripe_failed inbound hook (verified via the Stripe-Signature header). Declines now flow in and auto-dial.
6. Import (or webhook in) your customer list as client rows so the dormant queue fills up.

Settings

Bulk dialing the dormant queue (campaign API)

The card-rescue path (webhook → workflow → call) covers declines automatically. To launch the voluntary win-back across your whole dormant backlog, use the app-key campaign API over the client object's dormant view:

POST /api/app-campaigns
{
  "agentId": "<win-back agent id>",
  "targetQuery": { "status": "dormant" },   // over the `client` object
  "result": { "object": "campaign_result" }
}

Every dialed client's result lands as a campaign_result row, which powers the dashboard's win-back rate.

Monetization

Customer Win-Back & Membership Recovery is billed on outcomes, not seats:

• Per reactivated client — a fee for each dormant client the win-back agent books back in (reactivated), since each is revenue you'd otherwise have written off.
• Per saved membership — a fee for each declined card the recovery agent rescues (recovered), which prevents an involuntary cancellation and pulls the whole remaining membership value forward.

Because a reactivation and a saved membership are both worth many multiples of a single call, the app nets positive for the merchant on the very first save — and the dashboard's recovered revenue tile makes that ROI obvious at a glance.

Changelog

1.1.0 — 2026-07-12

• Renamed to Customer Win-Back & Membership Recovery (business-friendly) with a marketplace icon.
• Added real UI screenshots (dashboard + key pages).
• Dormant clients are now derived from days-since-visit (works for real imported lists); a card decline flags the membership and mark_churned was added.
• Verified end-to-end loop closure: trigger → workflow → call → agent tools → write-back → dashboard.

1.0.0

• Initial release.
• Data model: client (name, phone, last_visit, days_since, lifetime_value, status, note) with a dormant win-back queue view (by days-since) plus reactivated / lost views; membership (name, phone, plan, card_last4, status) with failed_payments / recovered / churned views; failed_payment (phone, amount, card_last4, created_at) with a recent declines view; and campaign_result (phone, outcome, booked) with a booked view.
• Agent tools (declarative): find_client, find_membership, book_return, mark_recovered, mark_lost, mark_churned, log_outcome.
• Bundled agents: Win-back Agent — a warm "we've missed you" multi-context flow (deterministic find_client lookup → comeback offer → book the return / mark lost) — and Card-recovery Agent — a calm decline-rescue flow (find_membership lookup → card-update script → mark recovered). Both auto-wired to the tools and the win-back playbook.
• Knowledge base: winback-playbook — the comeback offer menu, the card-update rescue script, retention talking points, and win-back objection handling.
• Automation: stripe_failed inbound webhook (HMAC-verified via Stripe-Signature, dedupe on phone); card_recovery workflow (flag the matching membership failed_payment so it surfaces on the rescue queue → delay ~2 min → outbound card-recovery call); send_card_link workflow (WhatsApp the secure update-card link on a decline).
• Dashboard UI: KPI tiles (recovered revenue, win-back rate, saved memberships, dormant clients, cards to rescue), a client-status mix bar, the longest-gone dormant clients, and recent call outcomes; also renders into the dashboard_widget slot in compact form.
• Clients page: the dormant queue by days-since-visit, status filters, search, and per-client Call now (dials the win-back agent with context).
• Memberships page: the failed-payment rescue queue with at-risk amounts and per-member Call now (dials the card-recovery agent).
• Setup page: configuration checklist, one-click Create agent for both bundled agents, Stripe wiring, and the dormant-campaign API note.
• Self-seed: a fresh install auto-loads six realistic clients (three dormant, one reactivated, one lost, one active), two memberships (one failed, one recovered), a failed payment, and four call outcomes (removable) so every page looks alive on first open.