Direct answer: create a Churn codebook with a small set of mutually understandable themes, assign one Primary tag to every usable response, add a Secondary tag only when another reason is explicitly present, and preserve a short Evidence note in the respondent's own terms. Route unclear records to an ambiguity queue instead of forcing certainty. Review the same codebook on a fixed cadence so changes remain visible and comparable.
- Record: response ID, event date, source and a short verbatim excerpt.
- Tag: one primary reason, an optional secondary reason and the codebook version.
- Qualify: evidence note, confidence level, ambiguity flag and reviewer.
- Review: reconcile usable responses, tag counts and unresolved records before summarising.
This template codes completed feedback. It starts only after a person has voluntarily answered an exit question or supplied an unsolicited explanation. It does not collect feedback, decide why a silent subscriber left, diagnose account events, choose a retention intervention, or execute a return campaign. If collection is the current job, use the exit-survey question guide first.
The result is a modest evidence table, not a verdict. A person can report that the content no longer fit their interest, but that statement does not establish a single cause for every cancellation. The code records what was said, where it was said, and how confidently it fits a defined theme. Keeping those distinctions visible makes later review more honest.
Define the record before defining the tags
Use one row per completed response. Give it an internal response ID, capture date, source or survey version, subscription-event status if already known, verbatim excerpt, primary tag, optional secondary tag, evidence note, confidence label, and reviewer initials. Do not place unnecessary personal details in the coding sheet. The response ID should let an authorised reviewer trace the source when needed without copying a whole conversation into every view.
Keep operational events separate from reported reasons. A recorded renewal failure belongs in an event-status field. A respondent saying “I meant to renew” belongs in the feedback excerpt. Neither field should overwrite the other. This separation stops a payment event from being mislabeled as dissatisfaction and stops a subjective statement from being treated as a confirmed platform event.
Mark empty, unreadable, irrelevant, and declined responses explicitly. “No response” is not a churn reason. It belongs outside the reason distribution because silence supplies no theme to code. The same rule applies when a response contains only an emoji or a greeting with no usable explanation.
Build a small Churn codebook
Start with broad themes that can be recognised from the text: budget or spending priority, interest or content fit, usage frequency, experience or communication, temporary break, technical or renewal issue, another stated reason, and unclear. These are starter labels, not universal categories. Rename or remove them when the actual wording in your completed responses calls for a different structure.
For every tag, write a one-sentence inclusion rule, one exclusion rule, and two short examples. “Usage frequency” might include a person explicitly saying they did not visit often enough. It should exclude someone who merely says the subscription was expensive, unless low usage is also stated. “Temporary break” should require language about pausing or returning later; do not infer it from a short subscription duration.
Keep the codebook version beside every coded row. If the definition changes materially, issue a new version and note the date. Do not silently reinterpret old rows. A stable version lets reviewers compare like with like, while a visible revision log explains why later records may use a refined tag.
Choose one Primary tag
The Primary tag should represent the clearest reason the respondent foregrounded. Read the entire response, underline the words that support a theme, then apply the tag whose inclusion rule best matches those words. If the person explicitly ranks reasons, use the highest-ranked one. If one reason occupies most of the answer and another appears as context, use the dominant reason.
Do not choose the tag that seems easiest to fix. Coding should describe evidence before the team discusses action. Likewise, do not select a preferred explanation because it matches last month's pattern. If two themes are equally explicit and neither is primary, use the codebook's tie rule: either mark primary as “multiple stated” or route the row for a second review.
Confidence describes fit to the codebook, not truth. “High” can mean the response uses direct wording that clearly meets one definition. “Medium” can mean a reasonable fit with some missing context. “Low” should trigger review or the unclear tag. It must not become a score for how believable the respondent seems.
Add a Secondary tag only with evidence
A Secondary tag is useful when a distinct second reason is plainly stated. “I am cutting subscriptions and I was not logging in much” supports two themes. “It cost too much for how often I visited” may still be one linked explanation, depending on the codebook rule. The reviewer should quote the words supporting each tag rather than split every sentence into as many categories as possible.
Limit the row to one secondary theme. If three or more reasons appear, preserve the full excerpt and mark the record for qualitative review. Unlimited tags make summary counts hard to interpret because one long response can outweigh several concise responses. The limit is an analysis convention, not a claim that people have only two reasons.
Never manufacture a secondary theme from sentiment. Frustration does not automatically mean communication quality; mentioning a busy month does not automatically mean budget pressure. Use the respondent's stated content, and put reviewer questions in the evidence note.
Write an Evidence note that another reviewer can audit
The Evidence note should be brief: quote or paraphrase the supporting phrase, identify any ambiguity, and explain the rule applied. A useful note reads, “Primary usage: respondent says they opened the page twice this month; secondary budget: says they are reducing all subscriptions.” An unhelpful note reads, “Probably lost interest.” The first points to evidence; the second adds an unsupported conclusion.
Do not clean up a respondent's language until it changes meaning. Preserve a short verbatim excerpt separately, then use neutral words in the note. Remove unrelated identifying details before the sheet is shared. If the response mentions a support problem that needs individual handling, route that issue through the appropriate support process while leaving the coding row descriptive.
Add a “review needed” field for translation uncertainty, unclear pronouns, contradictory statements, or missing context. The purpose is not to make every row fit today. An honest unknown is more useful than a confident but unstable label.
Resolve ambiguous and multi-reason responses consistently
Set a short decision order. First ask whether the response contains a reason at all. Second test the clearest phrase against each inclusion rule. Third apply the explicit ranking or dominant-theme rule. Fourth use the secondary field only for another direct reason. Fifth send unresolved ties to a second reviewer. Record the final decision and why it changed.
For calibration, give the same small sample to two reviewers without showing each other's answers. Compare disagreements by definition, not by person. If one label repeatedly overlaps another, tighten the inclusion and exclusion rules. Recode the calibration sample after the revision, but do not rewrite the whole history unless the change is important enough to justify a documented migration.
A recurring unclear pile can be a finding about the collection question. It may mean the prompt combines several ideas or the response choices do not match how people describe their experience. That observation belongs as a handoff to the collection owner, not as a reason to guess the missing detail.
Review patterns without turning counts into causes
On a fixed cadence, show response count, no-response count, codebook version, primary-tag counts, secondary-tag counts, unclear count, and a few de-identified examples. Compare only equivalent windows and survey versions. A rise from two to four responses can look dramatic as a percentage while still being a very small amount of evidence, so always retain the raw count.
Use patterns to form questions. If several respondents mention low usage, ask what changed in the experience or audience context and what other records could clarify it. The separate churn diagnosis worksheet handles that investigation. Coding alone cannot tell the team which change will work.
If a confirmed segment and an approved return objective later exist, the expired-subscriber win-back guide is a separate downstream tool. Do not turn every feedback response into an immediate message. Collection, coding, diagnosis, and outreach need distinct owners and decision points.
Copy the worksheet and quality check
Use these columns: response ID; captured date; source version; event status; verbatim excerpt; Primary tag; Secondary tag; Evidence note; confidence; review needed; reviewer; codebook version; and downstream question. For each row, confirm that the excerpt supports the primary label, any secondary label has separate wording, silence was not coded, and uncertainty remains visible.
Before publishing a summary, check that totals reconcile to usable responses, multi-tag rows are not double-counted as people, examples are de-identified, and codebook changes are disclosed. State the evidence window and the number of completed responses. Keep the underlying row table available to the reviewers responsible for the analysis.
Limitations and source notes
Limitations: voluntary responses can be incomplete, selective, or shaped by the question wording. The template describes reported themes within the collected set. It does not represent silent subscribers, prove causation, predict future behaviour, or establish which intervention should follow.
The method adapts the GOV.UK Service Manual guidance to record observations, group similar evidence into themes, name those groups, and decide what needs action. See Analyse a research session and Start by learning user needs. The codebook, confidence labels, and calibration routine are original SirenCY editorial tools, not platform features or official standards.