Churn research: find what has to change before asking customers to stay

A customer selects “too expensive” and closes the account. A discount seems like the obvious response. But the same answer could follow a lost client, a change in working routine or a service that never became useful. Before choosing a retention offer, establish what the customer was trying to do and what changed.

Consider Sessionlane, a fictional booking service for independent tutors. Tutors publish availability and let students request appointments. Its team needs to choose between improving the first booking experience, addressing a recurring service problem and changing the offer for established users. This example sets out how to investigate that choice; it reports no collected churn findings.

Define the departure before explaining it

For Sessionlane's investigation, count a paying tutor account as churned when its subscription actually ends. Retain the date cancellation was requested separately. An account that will remain paid until the end of its term has made a decision, but it has not yet left under this definition.

Separate an explicit cancellation from a failed renewal payment, a pause, a duplicate account and a trial that never became paid. Those records can all matter, but they do not describe the same event. A payment failure needs investigation before being labeled a decision to reject the product.

Choose the account as the unit, so several staff or contact records do not become several lost customers. Fix the observation period and keep the eligible starting base. Newer accounts have had less opportunity to leave than older accounts; compare like periods rather than treating their shorter histories as evidence of stronger retention.

Then divide the investigation by meaningful prior experience. Examine tutors who left before receiving a first appointment request, tutors who used the service regularly and then stopped, and tutors whose usage continued until cancellation. These are starting contrasts, not explanations. Low recorded use cannot by itself tell you whether the tutor lacked students, met a technical problem or moved bookings elsewhere.

Reconstruct the episode behind the reason box

Use the product, billing and support records to build a dated account: availability published, appointment requests received, relevant failures, contact with support and cancellation. Check that an apparent drop is not a tracking change or missing event. An appointment request is not proof that the lesson occurred.

An exit interview adds the customer's account of that sequence. Start with the last period when the service was useful, then follow what happened before the decision to leave. Ask what they tried, who else was involved, which alternatives they considered and what they now do instead.

For example, ask a tutor to describe the last appointment they arranged through Sessionlane and the first one they arranged another way. With permission, relevant calendar entries or messages can help locate the sequence. They do not automatically establish everything the tutor remembers about it.

Use open questions and follow the episode before proposing a rescue. “What happened after that request?” leaves room for a problem the team has not imagined. “Would a cheaper plan have kept you?” introduces a proposed solution before explaining the original decision. GOV.UK's interview guidance recommends neutral questions, follow-ups and concrete stories rather than general accounts of how things should work.

Hear from more than the easiest former customers

Invite people across the relevant usage and departure groups. Do not rely only on cancellation-survey respondents, recent support callers or people the account team still knows well. Each route makes some experiences easier to hear than others.

Include contrasting retained customers who faced a similar problem. A tutor who experienced a failed request and stayed may reveal a workaround, a different consequence or another reason to value the service. Their presence does not turn the interviews into a causal experiment, but it helps challenge a convenient explanation.

Record who was invited, reachable, eligible, interviewed or unavailable. Where appropriate, compare known tenure and usage characteristics of participants with the invited groups. If heavily disengaged tutors rarely reply, say which experience remains thin. Silence is not an answer to the reason question.

AAPOR's Standard Definitions distinguishes coverage and nonresponse error and cautions that a response rate alone cannot determine whether nonresponse error exists. More interviews from the same responsive group do not necessarily address the missing experience.

Report interview themes against the people who supplied them. “Mentioned in these interviews” is different from “caused this share of all churn.” Measuring the prevalence of reasons requires a suitable population, question and response design, with its missing coverage preserved.

Keep competing explanations in the decision

Suppose the team is investigating a tutor who reports that Sessionlane became too expensive after appointment requests stopped. There are several plausible sequences. A product failure may have prevented students from requesting lessons. The tutor may have reduced teaching hours, leaving less work for the service. They may have moved regular students to direct messages and no longer needed online booking.

Look for the evidence that distinguishes them. A reproducible failure and affected request records support a product investigation. A changed schedule can explain why the previous offer no longer fits. A switch to messages invites questions about which part of booking remains useful and what the alternative handles better.

Price can still matter. Ask what the tutor paid for, what value they expected and what they compared with the subscription. Avoid forcing every explanation into a single primary reason when several conditions interacted. Preserve the original account and any uncertainty about their order.

Our customer needs analysis guide helps separate the desired outcome from a requested solution. “Give me a discount” may be one proposed response. Dependable access to suitable appointments is the outcome the business still has to serve.

Choose a repair the evidence can evaluate

If tutors cannot complete a first booking task, reproduce the problem and test the repaired experience with relevant users. If established users no longer receive the service they expected, investigate delivery before changing the cancellation message. If the need has ended, a retention prompt may be the wrong intervention.

Give the proposed change an owner and an outcome beyond a saved cancellation. For a booking repair, examine whether eligible tutors can receive and manage the intended request. For a revised offer, examine whether the people it is designed for choose it and continue using it through an appropriate follow-up period.

A discount accepted at the cancellation screen does not show that the original problem was solved. Keep later service use, repeat cancellation, support problems and payment outcomes visible. Before a live comparison, specify the eligible group, allocation, primary outcome and consequences to monitor. Microsoft's experimentation guidance explains why these choices belong in the design before results are read. A before-and-after change alone may also reflect seasonality or a different mix of tutors.

Use simulated responses to explore the next offer

Sapien can compare modeled reactions to feasible alternatives and explore the reasons behind differences across audience groups. Our team builds the simulated population and runs the agreed research; customer data and past research can add context. Our market research services guide explains the engagement and the offer comparison that can follow an investigation.

For Sessionlane, that could mean exploring how different tutor situations interpret a revised service or commitment. It cannot establish why a named tutor canceled, recover the testimony of someone who did not answer or prove that a proposed repair reduces churn. Generated explanations must remain hypotheses alongside real customer accounts and event evidence.

Choose the response source according to the remaining question, as we explain in our synthetic versus human respondents guide. Actual exit interviews concern what happened. A modeled comparison explores how a defined audience might respond. A real service evaluation tests whether the change helps.

Bring the departure you can define, the evidence you already hold and the alternatives your team can deliver. Book a demo to explore the next offer with Sapien while keeping the explanation of actual churn tied to customers and their records.