Can an account have high adoption breadth and still be at risk?

Yes, and that combination is the most misleading one. Wide shallow usage reads well on every standard health input while remaining fully reversible by a single budget decision, because no workflow would need rebuilding if the product were removed.

How is adoption depth measured?

Depth is measured by asking rather than by instrumenting. Having users describe what they would do if the product disappeared tomorrow separates real dependency, which shows up as a multi-day manual workaround, from substitutability, which shows up as naming another tool.

Does adoption breadth matter at all for retention?

Breadth matters for organizational visibility and for sizing expansion, since a product used across several functions is harder to cut quietly than one used by a single team. It sets the ceiling for growth but does not by itself make an account defensible.

Adoption depth vs adoption breadth: which one predicts renewal

Comparison · customer-success · 5 min read · last verified 2026-07-21

Reviewed before publication Editorial board Independent commercial review

In shortAdoption breadth counts how many people touch a product; adoption depth counts workflows that would break without it. Wide shallow usage flatters dashboards, while a few deeply dependent workflows are what retain.

Adoption breadth measures how many people or teams touch a product, while adoption depth measures how completely a specific workflow depends on it — and depth predicts retention better, because a few workflows that cannot run without the product are harder to remove than wide, shallow usage spread thinly across an organization.

Adoption depth vs adoption breadth at a glance

Unit of measurement. Breadth counts users, seats, teams, or features touched. Depth counts workflows that would break if the product were removed.
What it indicates. Breadth indicates exposure and reach. Depth indicates dependency.
How it moves. Breadth can rise through provisioning and mandates. Depth rises only when someone rebuilds a process around the product.
Reversibility. Breadth is easy to reverse; unused seats are cut in a budget review. Depth is expensive to reverse because the process has to be rebuilt.
Effect on renewal. Breadth affects the size of the contract under discussion. Depth affects whether the discussion ends in renewal.
Failure mode. Breadth without depth produces flattering dashboards and fragile accounts. Depth without breadth produces defensible accounts with limited expansion room.
Who feels a removal. Breadth spreads mild inconvenience widely. Depth concentrates severe disruption on specific teams that will resist the change.

What adoption breadth is

Adoption breadth is the extent of a product's footprint across an organization: how many licensed users are active, how many distinct teams or departments use it, and how many features or modules see traffic.

Breadth is the easier of the two to measure, since every component is directly instrumented. It is also the easier to influence. Seats can be provisioned during rollout, access can be granted by default, and internal mandates can push adoption numbers up without any change in how work gets done.

Breadth matters for real reasons. A product used by one team is invisible to leadership; a product used across several functions appears in more conversations and has more people who would notice its removal. Breadth also sets the ceiling on expansion.

The problem is that breadth measurements say nothing about substitutability. A thousand people who each open a tool occasionally, for tasks they could accomplish another way, produce a strong usage report and a weak renewal position.

What adoption depth is

Adoption depth is the degree to which a specific workflow has become dependent on the product — the extent to which removing it would require rebuilding a process rather than substituting a tool.

Depth accumulates through mechanisms that are mostly invisible in usage telemetry:

Process embedding. The product's output has become an input to something else — a report that feeds a planning cycle, an alert that triggers a defined response, a record other systems read.
Data accumulation. History, configuration, and institutional context have built up inside the product and do not transfer cleanly.
Downstream consumption. People outside the immediate user group consume what the product produces, often without knowing where it came from.
Procedural encoding. The product appears in documented procedures, onboarding materials, or compliance evidence, so removing it means editing those artifacts.
Integration. Other systems read from or write to it, making removal a technical project rather than a cancellation.

These are the mechanisms that generate real switching costs. A customer with three deeply embedded workflows faces a project to leave. A customer with wide shallow usage faces a decision.

How they relate

Breadth and depth are not stages of one progression, and treating them as such causes most of the misreading.

Breadth can grow while depth stays flat. A rollout that provisions many seats produces a rising adoption curve with no additional dependency, since nobody has changed how they work. This is the pattern that flatters dashboards and surprises forecasts.

Depth can grow while breadth stays flat. A single team can move progressively more of its core process onto the product without any new users appearing. Usage counts barely move while the account becomes substantially harder to displace.

The two also carry different information about future revenue. Depth supports the current contract. Breadth indicates where the next one might come from, which is the underlying logic of land and expand motions: establish depth in one team, then extend the pattern outward.

The dangerous combination is high breadth with low depth, because it presents as the healthiest possible account while being the least defensible. Every input to a standard health assessment reads well, and the entire footprint can be reversed by one budget decision.

Which to use when

Use depth to assess renewal risk. The question at renewal is what breaks without the product. Count the workflows that would need rebuilding, name them, and identify who owns each. An account with no nameable dependent workflow is at risk regardless of how many people log in.

Use breadth to size expansion potential. Which teams have touched the product without embedding it is a map of where depth could be built next.

Use both to diagnose a stalled account. Rising breadth with flat depth means the rollout added users but not use cases, and the response is workflow-level work with a specific team rather than more enablement sessions. Flat breadth with rising depth means the product is working and has not been introduced beyond its first home.

Use depth to prioritize support and reliability investment. Failures in a load-bearing workflow have consequences the customer cannot absorb, and those incidents damage renewals far more than problems in peripheral features.

Use breadth to gauge organizational visibility. A product used by one team depends on one manager's budget; one used by several is harder to cut quietly.

Practically, depth is measured by asking, not by instrumenting. The reliable method is to have users describe what they would do if the product disappeared tomorrow. Answers that describe a manual workaround taking days indicate depth; answers that describe using a different tool indicate breadth without it. That single question separates accounts that renew from accounts that look identical on a dashboard and do not, and it feeds directly into any credible view of customer lifetime value.