Growth and Return

Questions this playbook answers

• Which existing customers should we offer more to, and which should we leave alone for now?
• When does cross-selling a second product help an account, and when does it lose us money?
• How do we win back customers who left without sending everyone the same "we miss you" discount?
• What does our memory need to hold about a customer who left?
• Is it true that keeping a customer is five times cheaper than finding one?

The moment

Larkspur Systems (a fictional company, a composite of many real ones) sells field-service and fleet software. On the first Monday of the quarter, revenue operations hands the sales team two lists. The first is 3,100 current accounts that score high on an expansion model: more seats, the route-optimization add-on, or the new parts-inventory module. The second is 2,300 accounts that cancelled in the last three years. The plan for both is the same: one well-written email per list, a limited-time offer, and a sequence of two follow-ups.

Pick one row from the second list. Ridgeway Pest Services (also fictional) ran 60 technicians on Larkspur for four years and cancelled eighteen months ago. The CRM says "Closed Lost: Churn." The reason field says "Other."

The real reason is in three places nobody joined. The cancellation call recording, where the operations director says the mobile app's offline mode failed at rural job sites and her technicians were writing work orders on paper. Fourteen support tickets about the same failure, two of them escalated. And the product changelog, which shows that Larkspur rebuilt offline mode in its spring release, eleven months after Ridgeway left.

The planned win-back email offers Ridgeway 25 percent off to come back. It does not mention offline mode, because the system that writes it does not know. So it asks a customer who left over a broken feature to return for a discount on the same broken feature, as far as she can tell. The one thing that might bring her back, "the problem you left over is fixed, and here is the evidence," sits unused in a transcript.

Now look at the first list. One of the 3,100 accounts has doubled its fleet and is at its seat limit: a real expansion moment. Another scores high because its usage spiked, and the spike is its dispatchers re-entering routes by hand after a sync failure. Same score, opposite situations.

Both lists are built from prediction. Neither is built from memory.

The decision

Growth and return are three decisions, not one campaign. Expand sells more of what the account already uses (seats, tiers). Cross-sell introduces a product it does not use. Return tries to reacquire an account that left. For each account, the decision layer (Chapter 14) chooses among the same options: make an offer, route to an account manager, wait for a condition, ask a question, or do nothing. For former customers there is one more: suppress permanently, because some people asked not to hear from you and some relationships ended for reasons no offer fixes.

Here is the sentence this playbook turns on: a growth or win-back message is only as good as the company's memory of what happened last time. A propensity model knows who looks like a buyer. Only memory knows that this account already declined the add-on twice, that its champion left in June, or that it cancelled over a defect you have since fixed.

Start by retiring the arithmetic everyone quotes

Two numbers justify most retention and expansion budgets: "acquiring a customer costs five times more than keeping one," and "a 5 percent increase in retention raises profits by 25 to 95 percent." Neither survives a look at its source.

A widely read 2014 Harvard Business Review piece by Amy Gallo states that acquiring a customer is "anywhere from five to 25 times more expensive than retaining an existing one," with no source, and that "increasing customer retention rates by 5% increases profits by 25% to 95%," linking to Bain & Company [1]. The Bain text by Fred Reichheld says something narrower: "In financial services, for example, a 5% increase in customer retention produces more than a 25% increase in profit" [2]. The 95 percent is not there. The older root, Reichheld and Sasser's 1990 HBR article "Zero Defections," reported that cutting defections by five percentage points raised profits by 25 to 85 percent in a handful of service businesses (85 percent in one bank's branch system, 30 percent in an auto-service chain) [3]. That is a real observation about specific firms in 1990, not a law about yours.

The part of the Bain piece nobody quotes is the most useful: "not every customer has potential to be profitable and long-standing," so companies should "segment clients to identify the subset that holds this potential" [2]. The original argument is for selection. Selection is a decision, made per account, which is what this playbook is about.

Cross-selling has the same problem. Shah, Kumar, Qu and Chen studied the customer databases of five firms and found that 10 to 35 percent of customers who cross-buy are unprofitable, and that they account for 39 to 88 percent of the firms' total losses from customers [4]. The unprofitable ones shared persistent traits: limited spending, heavy returns and revenue reversals, excessive service requests, and buying only on promotion. For them, more products meant a deeper loss. "Sell more to existing customers" is not a strategy. It is a hypothesis that holds for some accounts and fails for others.

Target the change you cause, not the likelihood

The deeper reason to decide per account is the one Chapter 14 develops: a score predicts who will act, not whom your action will move. Accounts at the top of an expansion list are rich in Sure Things, who would have upgraded anyway (the Discount Mistake in Chapter 2 is exactly this). And contact can backfire: Chapter 14 walks through the retention campaign that raised churn and the evidence that sensitivity to the intervention, not risk, picks the right targets [5][6]. An upsell call to an unhappy account can be the prompt it needed to review the whole contract.

Win-back depends on why they left

For return, the best evidence says the reason for leaving is the variable that matters. Kumar, Bhagwat and Zhang, using eight years of telecom data, found that first-lifetime behavior, the reason for defection, and the type of offer all predict whether a lost customer comes back and how valuable they are afterward [7]. Customers who left over service and were won back with a service upgrade were profitable. Customers who left over price were less profitable once regained but tended to stay longer. Offers combining a discount with a service upgrade performed best, and customers who had referred others or had problems resolved well in their first lifetime were likelier to return [7][8]. One telecom, one market, one period: treat it as a strong prior, not a rule.

That gives a decision table for former customers:

Why they left (from memory)	Default decision
A product gap that is now fixed	Route or send: show exactly what changed, offer a low-risk way to verify it
A service failure	Lead with the service remedy (named contact, onboarding, credit), not only price
Price	A priced offer from the approved catalog; expect a smaller but steadier second lifetime
Acquired, closed, or consolidated vendors	Do nothing; watch for a new decision-maker only where appropriate
Champion left and nobody else knew the product	Wait; re-establish a relationship before any offer
Left angry, disputed, or asked not to be contacted	Suppress, permanently if they objected
Unknown	Ask, or stay honestly general; do not guess a reason

The last row matters most. A system that invents a reason ("we know budgets are tight") is worse than one that admits it does not know.

What you need to know

The signals differ by motion, and all of them live in memory before they live in a message (Chapter 10).

For expansion and cross-sell: entitlement against actual use (seats bought versus active, features licensed versus adopted); growth events (fleet size, new locations, a hiring wave); support health, including open escalations and any promise made to the account (the Broken Promise in Chapter 18 is an expansion email that ignored one); who the buyer is now, since titles go stale (the Stale Self, Chapter 11); and the offer history: what was offered, when, and what the account said. A declined offer with its reason ("not until the integration works") is one of the most valuable memories on the record. It tells you both what not to repeat and what would change the answer. Low seat adoption is a Customer Success play before it is a sales signal: help the unused seats get used first, because a nudge about unused seats can invite a downsizing review (Playbooks CS and SW).

The offer needs a source too. In the governed personalization engine I built, each campaign carries a capability map: the products, modules, and offers the model is allowed to recommend (Chapter 18). The model answers "which approved option fits what we know?", not "what would sound good?" Otherwise it will invent a module because it fits the buyer's problem. The same engine refuses relationship claims it cannot back. "Your unused module," "your renewal," and "your current contract" are allowed only when that relationship is on the record, enforced by a guideline and by a check in code; otherwise the copy is reframed as an evaluation. Expansion is where these claims tempt most, because they sound like knowing the customer.

For return: a departure record, which most companies do not keep. It needs:

• Typed properties (what you filter and decide on): departure date, reason category, reason source (declared, observed, or inferred), whether the reason is resolved, destination if stated, contact permission, prior win-back attempts.
• Evidence memories (what you quote): the exit-call statement, the key tickets, the cancellation email, each with its source and date.
• A synthesis: the relationship in a paragraph, first lifetime through exit, written for the account manager and the agent.
• Graph edges: the account's departure reason linked to the defect or product gap in your own tracker, and people linked to the organizations they now work for.

Apply the Boundary Rule from Chapter 10: "left over offline mode" is a property you will filter on; how the operations director described her technicians writing on paper is a memory you might quote. And apply provenance strictly (Chapter 11): an agent's guess that an account "probably left over price" must stay labeled as an inference, or it will harden into the reason the win-back offer is built on.

The join that makes win-back work is the one Larkspur never built: customer-side memory of why they left, linked to company-side memory of what has changed. When the spring release closed the offline-mode defect, every departure record linked to that defect should have changed state from "unresolved" to "resolved, eligible for review." The trigger for a good win-back is usually an event on your side, not a date on theirs.

Figure S2.1. Link why they left to what you changed, so a fix reopens the record instead of a timer.

Two cautions. People move (Chapter 11's tenure data) [9], so a two-year-old cancellation record may name someone who is gone. Re-verify the contact first. And the reason for leaving stays true as history forever, while its relevance expires when the cause is fixed. Supersede, do not overwrite. In the self-hosted memory system I built, that is schema, not habit. A replaceable field keeps every prior value with the dates it was valid, so "when did this reason become resolved, and what did the record say before?" is a lookup. An append-only field keeps every value as its own entry, the right shape for offer history and win-back attempts. The system also takes a list of fields its extractor may never infer: put the declared reason on it, and a model reading old tickets can propose an inferred reason in its own field but cannot fill the declared one.

The action

Most of this is asynchronous work (Chapter 17): a win-back needs to be right, not fast. A nightly or event-triggered job selects the accounts whose state changed (a defect closed, a seat limit reached, a contract anniversary, a new decision-maker detected), re-runs the decision for them, and queues actions. The exception is in-product expansion: a prompt when a user hits a seat or feature limit is a real-time "show" decision, and it should stay small and factual.

Channel follows value and consequence. For Larkspur's top 400 accounts, the output is a brief for the account manager, not an email: what changed, what the account said last time, what to offer, what to avoid. For the long tail, email or in-product messages, with human approval on any offer above a discount threshold.

The message is built from typed zones (Chapter 15), and each zone has a different source:

1. What we remember: one or two grounded facts from memory, each with a receipt. "You left in March last year because offline mode failed at your rural sites."
2. What changed: claims only from verified company-side sources (release notes, the closed defect, a named new service). Never generated from general knowledge.
3. The offer: selected by code from an approved catalog, with price and terms stated in full, including what happens after any introductory period. The model may describe it; it may not invent or modify it.
4. The ask: one low-cost next step, such as a pilot on their own routes or a call with the engineer who rebuilt the feature.

For Ridgeway, that becomes a short note from the account manager: it names the reason they left without excuses, links the release notes for the offline rebuild, and offers a 30-day pilot on three rural routes. No countdown and no manufactured deadline. A former customer is someone who already decided you were not worth it; pressure confirms the decision.

Close the loop. Every offer, what was delivered, and what the account did next are written back to the record as typed values (Chapter 10). In the engine I built, that continuity is the point of memory: lead, research, score, content, delivery, engagement, and then future context that sees what already happened. Without the write-back, next quarter's list offers the add-on again to the account that said no in March.

Memory of why someone left is the most useful thing you hold about them, and the easiest to misuse. Use it to show what changed, never to press where it hurt.

What can go wrong

Failure story: The Revolving Door

A composite of a pattern that is easy to fall into (illustrative, not a specific deployment). Larkspur's first win-back campaign sent a 25 percent discount to every account that had left in the past two years. It worked on the headline metric: about one in twelve came back, and the campaign was presented as found revenue.

Two renewal cycles later, most reacquired accounts that had left over service problems had left again. Nothing about the service had changed; they had been paid to retry the thing that failed them, and several now asked not to be contacted again. Meanwhile, the accounts that had left over the offline-mode defect, the group most likely to return for the right reason, had received the same generic discount and mostly ignored it.

The campaign measured reactivation. It should have measured second-lifetime survival by reason. Winning a customer back for the reason they left is a sale. Winning them back despite it is a delay.

Figure S2.2. Reactivation rewards the Revolving Door; second-lifetime value by reason shows whether the win-back was a sale.

Governance risks

• Money and commitments are on the irreversible list (Chapter 18). Discounts, credits, and price terms come from a catalog and pass a gate in code. A generated win-back that improvises "we can match that price" has made a commitment someone will have to honor.
• Former customer is not a consent status. An objection to marketing must survive the account closing and even record deletion, as a minimal suppression entry every send path checks (Chapter 19). Rules for contacting former customers differ by jurisdiction and channel, and the existing-customer exceptions some regimes allow are narrow; check them in dated notes, not in this playbook. This is not legal advice.
• Known, not watched. Following a former champion to a new employer can feel like service ("you used us at Ridgeway; here is what changed") or like surveillance, depending on what the person expects and how you learned it. Use relationship history the person shared with you; do not assemble a new profile of them from outside sources to reopen a sale.
• Sleeping Dogs in the expansion list. Suppress offers during open escalations and unresolved promises, and watch for accounts whose churn rises after contact.
• Stale inferences. A reason for leaving that the system guessed is not a reason the customer gave. Never quote an inference back to them as if they said it. The account manager's brief may carry a hypothesis ("likely left over price, unconfirmed"); the customer-facing message may not. Enforce that with an explicit list of fields allowed to reach the customer, not with the model's discretion (Chapter 15).

What this does not do

Memory does not create a reason to buy. It cannot make an unprofitable account worth expanding, and it cannot bring back a customer whose reason for leaving is still true. What it can do is stop you from asking at the wrong moment, for the wrong reason, with the wrong offer.

How you will know

Measure the change you caused, per motion and per reason, against a randomized holdout (Chapter 21).

For win-back: randomize at the account level within each departure-reason segment, with three arms where volume allows: reason-specific outreach, the generic offer, and nothing. The primary outcome is not reactivation. It is second-lifetime value: reactivated accounts still active and paying at twelve months, net of discounts. Guardrails: unsubscribes, complaints, and suppression requests per contact.

For expansion and cross-sell: measure incremental expansion revenue over a holdout, and pair it with two guardrails most programs skip. Expansion that sticks: seats or modules still in use two renewal cycles later (a sale followed by a downgrade is shelfware with a delay). And churn among contacted accounts versus holdout, which is how Sleeping Dogs show up.

Be honest about power. Larkspur's 2,300 lapsed accounts, split by five reasons and three arms, leave small cells. At that size only large effects are detectable within a year. Pool across quarters, measure more frequent outcomes (replies, pilot starts) as leading indicators validated against the slow one, and label underpowered decisions as judgment.

Reader Q&A

We never recorded why customers left. Where do we start? The reasons usually exist, just not as a field: cancellation calls, the last three months of tickets, CSM notes, the cancellation email itself. Run schema-guided extraction over them (Chapter 8) into a reason category with its source and a confidence, and review a sample by hand before trusting it. From today, capture the reason at exit as both a category and a verbatim quote.

Should a win-back offer include a discount? Match the offer to the reason. The evidence favors combining a service remedy with a price incentive over price alone, and it favors a service remedy for service defectors [7]. A discount answers price. It does not answer "your product failed us."

How soon after someone leaves should we reach out? When something relevant has changed, not on a fixed timer.

Is it cheaper to keep a customer than to find one? Often, for customers worth keeping. But the "five times" and "25 to 95 percent" figures do not trace to evidence that applies to you, and the original source argues for choosing which customers to invest in [2]. Compute your own acquisition and retention costs per segment.

playbook: S2
title: "Sales II: Growth and Return"
question: "What do we already know, and how do we use it to go deeper or win them back?"
concepts:
  - name: Growth and return decisions
    definition: "Three per-account decisions (expand, cross-sell, return), each choosing among offer, route, wait, ask, do nothing, and for former customers, permanent suppression."
  - name: Departure record
    definition: "Typed memory of why an account left: date, reason category, reason source (declared/observed/inferred), resolved status, destination, contact permission, prior win-back attempts, plus evidence memories, a synthesis, and graph links to the company-side cause."
  - name: Reason-to-resolution link
    definition: "A graph edge from a customer's departure reason to the defect, gap, or policy on the company side, so a fix changes the departure record's state and triggers review."
  - name: Offer history
    definition: "Every offer made to an account, when, and the account's response and stated reason; used to avoid repeats and to detect when the reason for a no has changed."
  - name: Second-lifetime value
    definition: "Value of a reacquired account over a fixed period after return, net of incentives; the primary win-back outcome instead of reactivation rate."
  - name: Capability map
    definition: "The approved products, modules, and offers a campaign may recommend; expansion and cross-sell suggestions are chosen from it, never generated from general knowledge."
decision_rules:
  - if: "an account's departure reason is unknown"
    then: "ask or stay honestly general; never infer and quote a reason"
  - if: "an account left over a product gap and the linked defect is now resolved"
    then: "mark eligible for review; lead with verified evidence of the change and a low-risk way to test it"
  - if: "an account left over service"
    then: "lead with a service remedy; price incentive only as a complement"
  - if: "an account objected to marketing or left in dispute"
    then: "suppress; the suppression survives account closure and record deletion"
  - if: "an expansion candidate has an open escalation or an unresolved promise"
    then: "suppress the offer and route to the account owner; revisit after resolution"
  - if: "an account shows unprofitable cross-buy traits (heavy returns or reversals, excessive service load, promotion-only buying)"
    then: "do not push additional products; review the account economics first"
  - if: "a win-back or expansion message includes a price, discount, or term"
    then: "select it from the approved catalog in code; require approval above threshold; state full terms"
  - if: "the contact on a departure record is older than its freshness window"
    then: "re-verify the person and role before writing to them"
  - if: "a message would state a relationship fact (your renewal, your unused module, your contract)"
    then: "allow it only when the relationship is on the record; otherwise reframe as an evaluation"
  - if: "an expansion or cross-sell recommendation is generated"
    then: "choose it from the campaign's capability map; write the offer and the response back to the record"
assessment_questions:
  - "Where is the reason each customer left recorded today, and in what form (field, ticket, call, nowhere)?"
  - "Is any product defect or gap linked to the accounts that left over it?"
  - "Do you store offers made to each account and the account's response?"
  - "Do win-back and expansion programs have randomized holdouts, and what outcome do they measure?"
  - "How are marketing objections from former customers enforced across every send path?"
  - "Which expansion offers can an agent send without human approval, and what gate enforces price terms?"
patterns: [Departure Record, Reason-to-Resolution Link, Offer History, Capability Map, Customer-Status Guard, Typed Zones, Do-Nothing Option, Permanent Global Holdout]
anti_patterns: [The Revolving Door, The Discount Mistake, The Stale Self, The Broken Promise, Retention Arithmetic Myth, Reactivation-as-Success]
links: {memory: [10, 11], decision: 14, generation: 15, timing: 17, governance: 18, privacy: 19, measurement: 21}
maturity_dimension: decisioning