Example: Why large customers are not renewing
A fictional session from start to finish: 12 leads from 5 functions map why their largest customers are leaving.
Context
This example is fictional. It is the session that the Facilitation pages follow step by step, told here in one place with the whole tree.
A software company sells scheduling and dispatch software to field-service businesses. In one quarter, 3 of its top 20 customers left. Their exit interviews named outages during the morning rush, slow support, and promised features that never shipped.
Each of the 5 functions involved had its own explanation. Engineering pointed at sales commitments, sales at outages, and support at tooling. One of the 2 customer success leads owns renewals. She decided that those explanations mattered more than her own map, and called a session.
Goal
Understand why large customers are not renewing, over the next 2 quarters.
Pricing was named as out of scope before the session. When it came up anyway, it went to the parking lot.
How the tree was built
The session had 12 participants: leads from engineering (4), support (2), product (2), sales (2), and customer success (2). It ran for 2.5 hours on a digital board, with a break after Connect. The customer success lead facilitated it from inside the group.
- Prepare. The facilitator pre-seeded the board from the exit interviews, the incident log, and the support queue: 5 problems, 4 outcomes, and 2 actions already under way.
- Seed. In 25 minutes, the board grew to about 60 nodes, among them duplicates and solutions.
- Group. Five clusters formed: account health, support and escalations, deals and roadmap, releases and reliability, and incident communication. Duplicates were stacked, and 3 nodes went to the parking lot.
- Connect. The clusters became a tree. A loop dissolved once its hidden causes were on the board, an obvious arrow was challenged and removed, and an arrow nobody expected joined 2 clusters.
- Prioritize. Each participant placed 3 votes on the 14 problems.
- Decompose. Three subgroups of 4 each took one of the 3 problems with the most votes into a deep dive.
- Close. The group read the tree back, named 2 insights, completed the legend, and agreed when the tree comes back.
For how long each step took, see the example in timing templates.
The tree
The finished tree had 47 nodes and 60 arrows.
Diagram as text: The full tree of why large customers are not renewing
Nodes:
- Root / Problem: "Customer success has no early warning of churn"
- Root / Problem: "Tier 1 support cannot see a customer's setup"
- Root / Problem: "Most tickets are escalated to engineering"
- Root / Problem: "Large customers run custom code paths"
- Root / Problem: "Sales promises custom features to close deals"
- Root / Problem: "The roadmap is reshuffled for every big deal"
- Root / Problem: "Reliability work never makes it into a sprint"
- Root / Problem: "Staging data looks nothing like production"
- Root / Problem: "Releases ship in big monthly batches"
- Root / Problem: "Nobody has load-tested the morning peak"
- Root / Problem: "Outages hit during the morning dispatch rush"
- Root / Problem: "On-call ignores alerts because most are noise"
- Root / Problem: "Customers hear about outages from their technicians"
- Root / Problem: "No one owns customer updates during incidents"
- Action / Intervention: "Score account health from usage and tickets"
- Action / Intervention: "Review every red account with its sales lead"
- Action / Intervention: "Give tier 1 read-only access to the admin tool"
- Action / Intervention: "Write runbooks for the 20 most common tickets"
- Action / Intervention: "Rotate one engineer a week as support liaison"
- Action / Intervention: "Turn custom code into customer settings"
- Action / Intervention: "Route custom requests through a deal desk"
- Action / Intervention: "Lock the roadmap each quarter, with one slot for deals"
- Action / Intervention: "Reserve 20% of every sprint for reliability"
- Action / Intervention: "Automate tests of the morning dispatch flow"
- Action / Intervention: "Copy anonymized production data to staging nightly"
- Action / Intervention: "Release weekly behind feature flags"
- Action / Intervention: "Roll out to 5% of customers first"
- Action / Intervention: "Load-test the morning peak every week"
- Action / Intervention: "Freeze deploys during the morning rush"
- Action / Intervention: "Alert only on symptoms customers feel"
- Action / Intervention: "Name a communications lead for every incident"
- Desired State / Outcome: "At-risk accounts are flagged 90 days before renewal"
- Desired State / Outcome: "9 in 10 large customers renew"
- Desired State / Outcome: "Tier 1 resolves 7 in 10 tickets on its own"
- Desired State / Outcome: "Engineers spend 80% of their week on planned work"
- Desired State / Outcome: "New customers go live within 4 weeks"
- Desired State / Outcome: "Deals close on the standard product"
- Desired State / Outcome: "The roadmap holds for a full quarter"
- Desired State / Outcome: "Promised features ship on the promised date"
- Desired State / Outcome: "Releases ship every week without drama"
- Desired State / Outcome: "No outages during the morning rush"
- Desired State / Outcome: "On-call trusts every page"
- Desired State / Outcome: "Customers hear about incidents from us first"
- Artifact / Deliverable: "Customer health dashboard"
- Artifact / Deliverable: "Engineering's internal admin tool"
- Artifact / Deliverable: "Production-like staging environment"
- Artifact / Deliverable: "Public status page"
Arrows:
- "Customer success has no early warning of churn" influences "Score account health from usage and tickets"
- "Score account health from usage and tickets" influences "Customer health dashboard"
- "Customer health dashboard" attacks "Customer success has no early warning of churn"
- "Customer health dashboard" influences "At-risk accounts are flagged 90 days before renewal"
- "Customer health dashboard" influences "Review every red account with its sales lead"
- "Review every red account with its sales lead" influences "9 in 10 large customers renew"
- "Tier 1 support cannot see a customer's setup" influences "Most tickets are escalated to engineering"
- "Large customers run custom code paths" influences "Most tickets are escalated to engineering"
- "Tier 1 support cannot see a customer's setup" influences "Give tier 1 read-only access to the admin tool"
- "Engineering's internal admin tool" influences "Give tier 1 read-only access to the admin tool"
- "Give tier 1 read-only access to the admin tool" influences "Write runbooks for the 20 most common tickets"
- "Most tickets are escalated to engineering" influences "Write runbooks for the 20 most common tickets"
- "Write runbooks for the 20 most common tickets" influences "Tier 1 resolves 7 in 10 tickets on its own"
- "Most tickets are escalated to engineering" influences "Rotate one engineer a week as support liaison"
- "Rotate one engineer a week as support liaison" influences "Engineers spend 80% of their week on planned work"
- "Most tickets are escalated to engineering" blocks "Engineers spend 80% of their week on planned work"
- "Sales promises custom features to close deals" influences "Large customers run custom code paths"
- "Sales promises custom features to close deals" influences "The roadmap is reshuffled for every big deal"
- "Sales promises custom features to close deals" influences "Route custom requests through a deal desk"
- "Large customers run custom code paths" influences "Turn custom code into customer settings"
- "Turn custom code into customer settings" influences "Deals close on the standard product"
- "Turn custom code into customer settings" influences "New customers go live within 4 weeks"
- "Route custom requests through a deal desk" influences "Deals close on the standard product"
- "Route custom requests through a deal desk" influences "Lock the roadmap each quarter, with one slot for deals"
- "The roadmap is reshuffled for every big deal" influences "Lock the roadmap each quarter, with one slot for deals"
- "Lock the roadmap each quarter, with one slot for deals" influences "The roadmap holds for a full quarter"
- "Lock the roadmap each quarter, with one slot for deals" influences "Promised features ship on the promised date"
- "The roadmap is reshuffled for every big deal" influences "Reliability work never makes it into a sprint"
- "Most tickets are escalated to engineering" influences "Reliability work never makes it into a sprint"
- "Reliability work never makes it into a sprint" influences "Reserve 20% of every sprint for reliability"
- "Staging data looks nothing like production" influences "Releases ship in big monthly batches"
- "Staging data looks nothing like production" influences "Copy anonymized production data to staging nightly"
- "Copy anonymized production data to staging nightly" influences "Production-like staging environment"
- "Production-like staging environment" influences "Automate tests of the morning dispatch flow"
- "Automate tests of the morning dispatch flow" influences "Release weekly behind feature flags"
- "Releases ship in big monthly batches" influences "Release weekly behind feature flags"
- "Releases ship in big monthly batches" influences "Outages hit during the morning dispatch rush"
- "On-call ignores alerts because most are noise" influences "Outages hit during the morning dispatch rush"
- "Nobody has load-tested the morning peak" influences "Outages hit during the morning dispatch rush"
- "Nobody has load-tested the morning peak" influences "Load-test the morning peak every week"
- "Production-like staging environment" influences "Load-test the morning peak every week"
- "Load-test the morning peak every week" influences "No outages during the morning rush"
- "Release weekly behind feature flags" influences "Roll out to 5% of customers first"
- "Release weekly behind feature flags" influences "Releases ship every week without drama"
- "Roll out to 5% of customers first" influences "No outages during the morning rush"
- "Outages hit during the morning dispatch rush" influences "Freeze deploys during the morning rush"
- "Freeze deploys during the morning rush" influences "No outages during the morning rush"
- "On-call ignores alerts because most are noise" influences "Alert only on symptoms customers feel"
- "Alert only on symptoms customers feel" influences "No outages during the morning rush"
- "Alert only on symptoms customers feel" influences "On-call trusts every page"
- "Reserve 20% of every sprint for reliability" influences "Roll out to 5% of customers first"
- "Reserve 20% of every sprint for reliability" influences "Alert only on symptoms customers feel"
- "Turn custom code into customer settings" influences "Releases ship every week without drama"
- "Outages hit during the morning dispatch rush" influences "Customers hear about outages from their technicians"
- "No one owns customer updates during incidents" influences "Customers hear about outages from their technicians"
- "No one owns customer updates during incidents" influences "Name a communications lead for every incident"
- "Name a communications lead for every incident" influences "Customers hear about incidents from us first"
- "Public status page" influences "Customers hear about incidents from us first"
- "Public status page" attacks "Customers hear about outages from their technicians"
- "Customers hear about outages from their technicians" influences "Name a communications lead for every incident"
Almost every arrow is the default, influences. The tree has 1 blocks / impedes arrow and 2 attacks arrows, each drawn because the group needed to say something stronger.
A tree of this size cannot be read at a glance, and it does not have to be. The full tree is a map. The group worked in views of it.
One outcome at a time
"No outages during the morning rush" is the outcome the exit interviews pointed at most. Its blocked outcomes view hides every node without a path to it.
Diagram as text: Blocked outcomes view of the renewals tree, for one outcome
Filtered view: showing only "No outages during the morning rush" and the nodes with a path to it.
Nodes:
- Root / Problem: "Tier 1 support cannot see a customer's setup"
- Root / Problem: "Most tickets are escalated to engineering"
- Root / Problem: "Large customers run custom code paths"
- Root / Problem: "Sales promises custom features to close deals"
- Root / Problem: "The roadmap is reshuffled for every big deal"
- Root / Problem: "Reliability work never makes it into a sprint"
- Root / Problem: "Staging data looks nothing like production"
- Root / Problem: "Releases ship in big monthly batches"
- Root / Problem: "Nobody has load-tested the morning peak"
- Root / Problem: "Outages hit during the morning dispatch rush"
- Root / Problem: "On-call ignores alerts because most are noise"
- Action / Intervention: "Reserve 20% of every sprint for reliability"
- Action / Intervention: "Automate tests of the morning dispatch flow"
- Action / Intervention: "Copy anonymized production data to staging nightly"
- Action / Intervention: "Release weekly behind feature flags"
- Action / Intervention: "Roll out to 5% of customers first"
- Action / Intervention: "Load-test the morning peak every week"
- Action / Intervention: "Freeze deploys during the morning rush"
- Action / Intervention: "Alert only on symptoms customers feel"
- Desired State / Outcome: "No outages during the morning rush"
- Artifact / Deliverable: "Production-like staging environment"
Arrows:
- "Tier 1 support cannot see a customer's setup" influences "Most tickets are escalated to engineering"
- "Large customers run custom code paths" influences "Most tickets are escalated to engineering"
- "Sales promises custom features to close deals" influences "Large customers run custom code paths"
- "Sales promises custom features to close deals" influences "The roadmap is reshuffled for every big deal"
- "The roadmap is reshuffled for every big deal" influences "Reliability work never makes it into a sprint"
- "Most tickets are escalated to engineering" influences "Reliability work never makes it into a sprint"
- "Reliability work never makes it into a sprint" influences "Reserve 20% of every sprint for reliability"
- "Staging data looks nothing like production" influences "Releases ship in big monthly batches"
- "Staging data looks nothing like production" influences "Copy anonymized production data to staging nightly"
- "Copy anonymized production data to staging nightly" influences "Production-like staging environment"
- "Production-like staging environment" influences "Automate tests of the morning dispatch flow"
- "Automate tests of the morning dispatch flow" influences "Release weekly behind feature flags"
- "Releases ship in big monthly batches" influences "Release weekly behind feature flags"
- "Releases ship in big monthly batches" influences "Outages hit during the morning dispatch rush"
- "On-call ignores alerts because most are noise" influences "Outages hit during the morning dispatch rush"
- "Nobody has load-tested the morning peak" influences "Outages hit during the morning dispatch rush"
- "Nobody has load-tested the morning peak" influences "Load-test the morning peak every week"
- "Production-like staging environment" influences "Load-test the morning peak every week"
- "Load-test the morning peak every week" influences "No outages during the morning rush"
- "Release weekly behind feature flags" influences "Roll out to 5% of customers first"
- "Roll out to 5% of customers first" influences "No outages during the morning rush"
- "Outages hit during the morning dispatch rush" influences "Freeze deploys during the morning rush"
- "Freeze deploys during the morning rush" influences "No outages during the morning rush"
- "On-call ignores alerts because most are noise" influences "Alert only on symptoms customers feel"
- "Alert only on symptoms customers feel" influences "No outages during the morning rush"
- "Reserve 20% of every sprint for reliability" influences "Roll out to 5% of customers first"
- "Reserve 20% of every sprint for reliability" influences "Alert only on symptoms customers feel"
Of the 47 nodes, 21 passed the filtering. Most are about releases and reliability, as expected. Some are not: "Sales promises custom features to close deals" and "Tier 1 support cannot see a customer's setup" both have a path to outages.
One node at a time
In Decompose, the support subgroup took "Most tickets are escalated to engineering" into a deep-dive sub-tree. The outages node needed more time than the session had, so it got a deep-dive session of its own a week later.
What it revealed
- Sales promises reached all the way to outages. Custom promises reshuffle the roadmap, so reliability work never makes it into a sprint. No function had drawn that path alone: it crosses 3 of them.
- Customers are more likely to forgive an outage they hear about from the company first. The group began with an arrow from outages straight to renewals. The facilitator's renewal data did not support it. What mattered was how customers found out, and that became its own part of the tree.
- A problem with 1 vote sat under a problem with 5. "Tier 1 support cannot see a customer's setup" drew a single vote. Following the arrows showed it under escalations, and escalations under the missing reliability work. See the example in Prioritize.
- In its deep dive, the support subgroup found that tier 1 is measured on time to close, and escalating is the fastest way to close a ticket.
Lessons
- Invite every function the scope touches. Each function arrived with its own explanation. The tree showed how they connect, and no single one was the answer.
- Question the obvious arrows. The arrow everyone agreed on was the one that did not hold. See the challenge pattern.
- Read the votes with the arrows. Votes show where concern is concentrated. The arrows show what sits underneath it.
- Work in views. A tree of 47 nodes stays useful when the group reads it one outcome or one node at a time.
- Leave with an owner and a date. The facilitator owns this tree, with the commitment to raise it again at quarterly planning in 3 months. See a living document.