The Captivity Well: How to Read Retention When Users Cannot Leave

A practical guide for product and design leaders building AI products people depend on

Some years ago, a service provider charged me twice for the same service. The call to customer service went nowhere, and my patience started to show. My mentor, sitting across the desk, stopped me afterwards with a simple observation. The agent on the phone was the only person who could fix this. If he didn’t help, I would pay twice.

He was right. Walking away would not have undone the charge. The only lever I had was the conversation. The agent called back, and the problem was solved.

From the provider’s side, that call registered as a retained customer. That is the problem this article is about. When people cannot leave, retention stops telling you whether your product is good. And AI products may be building that kind of dependency faster than anything before them.

Two reasons users stay

One of the product innovation courses I’m working through uses an idea called the Gravity Well to explain why “better” so often loses to “already here”. A familiar, always-available tool that is good enough becomes the default. A better alternative exists, but the improvement doesn’t justify the effort of switching.

The Gravity Well assumes something that is easy to miss: the user could leave. There is a second situation that looks identical in the data, which I call the Captivity Well.

• Gravity Well: “This is good enough, so switching isn’t worth the effort.”
• Captivity Well: “This isn’t good enough, but I can’t realistically switch.”

Combining two questions, whether the product is good enough and whether the user could realistically leave, gives four situations:

The first and last look exactly the same on a dashboard. In one, staying means preference. In the other, it means constraint. When leaving is expensive, usage stops being evidence of preference.

This isn’t specific to one industry. Changing banks means rebuilding salary arrangements, standing orders, cards and payees. Changing payroll systems means re-validating every employee record. Enterprise platforms and public services work the same way. It doesn’t require a monopoly either. A supplier can compete hard to win a customer and still hold real power over them once they’re locked in. What matters is not how many competitors exist, but whether a dissatisfied customer can take their work elsewhere at a cost they can justify.

Why AI deepens the well

Traditional software builds switching costs slowly, through data and integrations accumulated over years. AI products seem to build them faster, in five layers:

1. Personal: memory, preferences, style and project context. Moving feels like starting again with a stranger.
2. Organisational: prompt libraries, evaluation sets, guardrails, security approvals and training. None of it is on an invoice, and all of it has to be rebuilt.
3. Agentic: permissions, system connections, audit trails and escalation rules. Replacing an agent is closer to replacing a colleague than a tool.
4. Model: workflows tuned to one model’s behaviour. Outputs shift when the model changes.
5. Infrastructure: cloud commitments, data location and transfer costs.

The bottom layer already has hard evidence. In July 2025, the UK Competition and Markets Authority found that fewer than 1% of cloud customers switch provider in a year. It linked that directly to providers’ weaker incentive to improve. The US Federal Trade Commission has flagged rising contractual and technical switching costs in partnerships between cloud providers and AI developers. The upper layers haven’t been studied properly yet. They are a proposition rather than a finding, but one worth acting on before the evidence arrives.

The practical consequence is a quiet shift in the question underneath your product. Early on, it is: is this good enough for people to choose it? A few years and many integrations later, it becomes: how much worse could this get before leaving made sense? Nothing announces that shift. Your metrics look the same before and after it.

The complication: agents cut both ways

The same capability that deepens lock-in can also dissolve it. An agent that compares offers, moves data and handles the paperwork of switching dramatically lowers the effort of leaving. Much of captivity has always rested on effort rather than rules, and effort is exactly what agents remove.

As agents increasingly act on behalf of users, the agent becomes the customer. Agents don’t form habits or grow attached to interfaces. They evaluate outcomes. Any product whose retention depends mainly on friction should assume that friction won’t stay expensive forever.

One question that splits your retention

If retention can’t be trusted on its own, you need a way to decompose it. One question does most of the work:

If switching were effortless, would you still choose this product?

Combine the answer with how realistically each user segment could leave, and retention splits into three parts:

• Preference retention. They would choose you again. This is a strong product.
• Friction retention. They wouldn’t, and could leave, but it’s not worth the effort. This is the Gravity Well, and it makes you a defensible incumbent.
• Constraint retention. They wouldn’t, and can’t realistically leave. This is the Captivity Well, and it means dependency.

A note on method: stated intentions are imperfect. Ask the question neutrally, and repeat it over time. Even a rough split changes the conversation.

A quick exit feasibility check

To know which segment users sit in, you need a rough sense of how realistically they could leave. Score each of these six factors from 0 (blocked) to 3 (straightforward):

1. Substitutes: is a viable alternative both permitted and available?
2. Technical: can data, integrations and configuration move?
3. Financial: what does leaving cost in penalties, fees and sunk commitments?
4. Organisational: how much retraining, re-approval and process change would it take?
5. Context: does accumulated knowledge (memory, agents, tuning) travel?
6. Risk: what could go wrong during migration?

Treat the total as a conversation starter, not a verdict. This is a working method, not a validated instrument. In a regulated service, a single 0 can outweigh everything else. The most useful output is usually the disagreement. When product and engineering score the same factor differently, that gap is worth more than the number.

What it looks like in practice

Here’s a hypothetical example. A company is three years into an enterprise AI assistant, and 96% of active users are still on the platform. Ask the question, score each segment’s exit feasibility, and the picture changes:

• 40% would genuinely choose it again.
• 22%, mostly light users who could move easily, would prefer something else but don’t find it worth moving.
• 34% are agent-heavy teams who would leave if they could. Their configurations, memory and evaluations have no way out.

The most strategically important use of the platform turns out to be the least willing. The headline number is the same. What it means is not. And you can no longer present 96% retention without saying what it’s made of.

Where dissatisfaction goes instead

In a competitive product, dissatisfaction shows up as churn. In a captive one, it moves into the user’s time, errors, support calls and workarounds. A field experiment with the US Internal Revenue Service showed how real this cost is: simpler notices meaningfully increased the number of eligible people who claimed a tax credit they had been missing. The friction was in the design, and evidence found it.

When users can’t leave, competition stops setting your minimum standard. Something else has to do that job: regulation, reputation, your own mission, or user voice that actually changes decisions. If none of those is strong, nothing is holding quality up.

For AI products, these are the signals that tell you what your retention figure won’t:

• Share of AI outputs accepted without edits
• Re-prompting, rephrasing and retries per task
• Time users spend verifying AI output
• Agent tasks escalated or silently dropped
• Human takeovers of agent workflows
• Users running unofficial tools alongside yours for the same job
• Feedback on AI answers, and whether it ever changes anything

Watch these most closely in your constraint segment. It’s the only channel that group has left.

Design the exit

We spend enormous effort designing onboarding and almost none designing offboarding. In products people depend on, the exit is part of product quality.

For AI products, the questions are concrete:

• Can users take their context and memory with them?
• Can agents and their configurations be exported in a form another system can use?
• Do integrations run on open standards or proprietary glue?
• Can old and new systems run side by side during a transition?
• Is historical data still accessible after termination?

In most organisations, nobody owns the exit. Legal owns the termination clause. Procurement owns the contract. Engineering owns the data export, if one exists. The experience of leaving, what a user actually goes through, belongs to no one. That makes it a design leadership question. It is an end-to-end journey across several teams, with real consequences for trust. It only gets designed if someone treats it as part of the product rather than the paperwork around it.

A product that is easy to enter and deliberately hard to leave may have excellent growth design and poor market design. Organisations that design a credible exit get something less obvious in return: retention they can actually believe.

Six questions for your next product review

1. How much of our retention is preference, friction and constraint?
2. How realistically could each segment leave, and what would change that?
3. Where does dissatisfaction go in our product, if not to churn?
4. If users can’t leave, what is actually keeping our quality up: regulation, reputation, mission or user voice?
5. Are we building a moat users choose, or one they can’t cross?
6. If switching became effortless tomorrow, which of our users would stay?

The last one matters most. The answer is the real size of your product.

A user who cannot leave is not a loyal user. Just a quiet one.

The full framework, including the complete measurement toolkit and a worked example, is available here.

The Captivity Well: How to Read Retention When Users Cannot Leave was originally published in Bootcamp on Medium, where people are continuing the conversation by highlighting and responding to this story.