Design for Independence: Why Self-Sufficient Customers Stay Longer

A customer asks to be able to run everything without calling anyone.

The reflex inside many enterprise vendors is to treat that as a risk. Support interactions are a relationship. A customer who stops calling is a customer nobody is talking to, and the account team loses visibility into what is happening.

The reflex is wrong, and the reasoning behind it confuses two different things. Dependency is a customer who cannot proceed without you. Retention is a customer who does not want to proceed without you. They look similar on a usage dashboard and they behave very differently at renewal.

A dependent customer calculates. Every support ticket is a reminder that the capability lives outside their organization, and the calculation is whether the outcome justifies the arrangement. A self-sufficient customer who keeps choosing the product has already answered a harder question, which is whether it is worth using when nothing compels them.

This matters to buyers as much as to vendors. Independence is evaluable at purchase, and most enterprise evaluations do not test for it.

Key takeaways

• Dependency and retention produce similar usage patterns and opposite renewal behaviour.
• A customer who cannot operate without support is running a continuous cost-benefit calculation.
• Self-sufficiency raises the ceiling on expansion, since new use cases do not require vendor capacity.
• Vendors that design for independence sell differently, because the product has to be genuinely usable rather than merely deliverable.
• The clearest signal of real adoption is a customer extending the product to something the vendor did not scope.
• Buyers can evaluate for independence, and the questions are straightforward.

What dependency actually costs both sides

For the customer

A capability that never transfers. Each engagement delivers an outcome and leaves no internal capability behind, so the next engagement starts from the same position.

A ceiling on scope. Extending to a new function requires vendor time, which requires a contract change, which requires a business case. The natural expansion that would happen if the team could just do it does not happen.

Fragility. The customer's ability to operate depends on an external party's availability, priorities and continuity.

For the vendor

Growth bound by delivery capacity. Every expansion requires people. Revenue scales with headcount, which is a services business wearing a software business model.

Support cost that scales with success. The more the product is used, the more it is used through the vendor, so margin degrades as accounts grow.

A renewal conversation about the arrangement. When usage requires the vendor, the renewal is evaluated as an ongoing service relationship rather than as a tool the team relies on.

Weak signal about the product. If the customer cannot use it alone, the vendor never finds out which parts are actually usable.

The signal that distinguishes them

Usage metrics do not separate dependency from retention. Both produce logins, sessions and activity.

The distinguishing signal is extension: a customer building something the vendor did not scope. A view assembled for a purpose nobody designed for, a workflow adapted to a local requirement, the product applied to a second function without anyone asking permission.

Extension is expensive to fake. It requires that someone understood the product well enough to see a use nobody described to them, and that they were confident enough to proceed without checking.

That is why it predicts renewal better than usage does. A customer who has built on top of a product has committed something of their own to it.

Dependency and retention

Two patterns that look alike

The first two rows look similar in a dashboard. The remaining four determine what happens at renewal.

What designing for independence requires

Four properties, in rough order of difficulty.

The product has to be usable rather than deliverable. A tool that works when a specialist configures it is deliverable. A tool a business user can configure is usable, and the gap between the two is where most enterprise software sits.

The output has to be interpretable without the vendor. If reading a result requires someone to explain what it means, the customer cannot act alone. Traceability to source and explanations of method are what make output self-serving.

Onboarding has to transfer capability. An onboarding that delivers a working configuration has delivered an outcome. One that leaves the customer able to build the next configuration has delivered a capability. The second takes longer and changes the account trajectory.

Extension has to be permitted by design. A product that only supports what was scoped cannot be extended. One with general primitives can be applied to things the vendor never considered, which is where the strongest adoption signals come from.

What buyers should ask

Independence is evaluable during an enterprise evaluation and rarely evaluated. Six questions.

1. After onboarding, which activities still require the vendor?
2. Can a business user configure a new use without engineering or vendor involvement?
3. Can someone in our organization explain the output without a vendor call?
4. What proportion of your existing customers extend this to functions you did not scope?
5. What happens to our ability to operate if our account team changes?
6. What would we be able to do in twelve months that we cannot do today, without buying more services?

Question 4 is the most informative and the least expected. A vendor whose customers routinely apply the product beyond the original scope has evidence that the product is usable. A vendor who cannot answer it usually has a delivery model rather than a product.

The uncomfortable implication for vendors

Designing for independence reduces revenue in the short term. Fewer services hours, fewer support interactions, less account team involvement.

It also changes what the vendor learns. A product used independently generates honest signal about which parts are clear and which are not, because nobody is compensating for the gaps in real time.

The trade is between measurable near-term revenue and a harder-to-measure change in retention and expansion. That is a genuinely difficult trade to make inside an organization measured quarterly, which is why so few make it.

The observable outcome is that the vendors who do tend to have customers who describe the product rather than the relationship.

Where Horizon fits

Horizon is an AI-powered continuous discovery platform, and independence is a design position rather than a claim.

Discovery Cycles are configured and launched by the customer's own team against the processes and objectives they choose. The Insights Dashboard carries traceability from each finding back to the employee input that produced it, which is what allows someone inside the organization to evaluate a finding without asking anyone whether it is reliable. The Initiatives Dashboard and the Process Library accumulate across cycles, so the second cycle is cheaper than the first and runs on the customer's schedule.

PedidosYa, the leading food delivery and quick commerce platform in Latin America operating across 15 markets, followed the pattern this piece describes.

The engagement began as a focused pilot across two teams, Rider Payments and Partner Payments, with 14 or more asynchronous AI interviews over three months. It produced 31 actionable findings across five high-impact process areas and generated structured process documentation for internal knowledge management and junior team onboarding.

What happened next is the relevant part. Based on the pilot results, PedidosYa extended the deployment to additional Finance areas including Tax, Collections and cross-market process benchmarking, with Rider Care planned. The company now uses Horizon as a continuous discovery engine rather than as a one-time diagnostic, running discoveries across those areas with a backlog of prioritized improvements ready to execute each quarter.

That extension was a customer decision applied to functions the original pilot did not cover, and it scaled without restarting the process. Employee feedback described the platform as intuitive, rational and accurate, and one participant noted that the compilation feature automates a discovery process that would otherwise take months.

That is one engagement under specific conditions rather than a projection for any organization. The pattern it illustrates is the one this piece argues for: a customer who can run the next cycle themselves runs more of them.

Evaluation checklist

For buyers assessing an enterprise vendor:

1. After onboarding, which activities still require the vendor?
2. Can a business user configure a new use independently?
3. Is the output interpretable without a vendor explanation?
4. Does the output trace back to source evidence you can inspect?
5. What proportion of existing customers extend it beyond the original scope?
6. Does the second deployment cost less effort than the first?
7. What happens if your account team changes?
8. What will you be able to do in twelve months without buying more services?

FAQ

What is the difference between customer dependency and customer retention?

Dependency means a customer cannot proceed without the vendor. Retention means they do not want to. Both produce usage, and they behave differently at renewal: a dependent customer evaluates whether the arrangement is worth its cost, while a self-sufficient customer evaluates whether they would give up something they rely on.

Does reducing support interactions hurt retention?

Not when the reduction comes from the customer being able to operate independently. Support volume falling after onboarding while usage holds or grows is a positive signal. Support volume falling while usage also falls is a different situation entirely, and the two are easy to distinguish.

What is the strongest signal of real product adoption?

Extension: a customer applying the product to something the vendor did not scope or describe. It requires understanding the product well enough to see an unstated use and enough confidence to proceed without checking, which makes it expensive to fake and predictive of renewal.

How should buyers evaluate a vendor for independence?

Ask which activities still require the vendor after onboarding, whether a business user can configure a new use alone, whether output is interpretable without a vendor explanation, what proportion of existing customers extend the product beyond original scope, and what the organization will be able to do in twelve months without buying more services.

Why do vendors resist designing for independence?

Because it reduces near-term revenue from services and support, and the benefit appears later in retention and expansion, which is harder to attribute. Inside an organization measured quarterly, that trade is difficult to make even when the long-term case is clear.

The customer who does not need you is the one who keeps choosing you

A support relationship generates activity that looks like engagement and answers an easier question than the one that matters.

The harder question is whether a team that could stop using something chooses not to. Designing so that customers can answer it is the only way to find out what they would say.

See it. Fix it. Own it.

See Horizon in action.