# PRD — Trust-First Cancellation

**Status:** Ready for design and engineering review  
**Owner:** Pooja Hegde  
**Partners:** Design, Web, Billing Platform, Data, Lifecycle, Support, Legal/Privacy  
**Target release:** [REDACTED — planning window]  
**Last updated:** 2026-08-25

> Portfolio note: This is a simulated PRD written to production standards. Company identifiers, pricing thresholds, and internal baselines are redacted; all remaining numbers are synthetic.

## 1. Decision summary

Build a two-step, self-serve cancellation experience that:

1. makes consequences explicit before commitment;
2. offers at most one alternative when it directly matches the customer's reason;
3. preserves an equally prominent path to cancel; and
4. measures voluntary retained value without rewarding obstruction.

The initial release covers direct web subscribers in [REDACTED — launch markets]. App-store billing, account-level contracts, refunds, and collections remain on existing paths.

## 2. Problem

Customers who decide to leave face three avoidable uncertainties:

- **Access:** when paid features stop and whether remaining time is honored;
- **Data:** what is retained, exportable, or deleted; and
- **Status:** whether cancellation actually succeeded.

The business also lacks a trustworthy explanation for preventable churn. The current reason taxonomy is broad, optional, and collected after the decision, when response quality is low. Retention teams therefore optimize generic discounts instead of the underlying job.

The product problem is not “too many users click cancel.” It is:

> Customers cannot make a confident subscription decision, and the business cannot distinguish a recoverable mismatch from a resolved decision to leave.

## 3. User and job

**Primary user:** A direct web subscriber who has decided the current plan no longer fits.

**Job to be done:**

> When my subscription stops fitting my life, help me understand my options and complete my decision without pressure, so I can protect my money and data—and consider returning if the fit changes.

**High-risk users:** Customers citing privacy, unauthorized billing, financial hardship, bereavement, or accessibility barriers. These users must receive a direct exit path; persuasion is inappropriate.

## 4. Goals and success measures

| Goal | Metric | Launch threshold |
|---|---|---:|
| Preserve recoverable value | Voluntary 30-day retained value rate | ≥ +3.0 pp vs control |
| Keep exit self-serve | Cancellation completion rate | ≥ 90% and non-inferior within −1.5 pp |
| Reduce confusion | Cancellation-related contacts / 1,000 starts | No increase; target −10% |
| Preserve trust | Post-flow trust score (1–5) | Non-inferior within −0.1 |
| Improve diagnosis | Valid reason capture rate | ≥ 75% without requiring a response |

The full definitions and denominators live in [METRICS_CONTRACT.md](METRICS_CONTRACT.md).

## 5. Non-goals

This release will **not**:

- increase saves by adding steps, hiding controls, requiring support contact, or using ambiguous copy;
- personalize offers using sensitive attributes, inferred financial vulnerability, or prior cancellation attempts;
- optimize short-term reversal clicks that do not survive 30 days or produce a meaningful product action;
- redesign plan pricing, refund policy, collections, or entitlement architecture;
- support app-store, reseller, family, enterprise, or multi-seat billing;
- promise unreleased features or imply a requested feature has a committed delivery date;
- auto-enroll a customer in a pause, lower tier, annual plan, or marketing sequence.

## 6. Principles

1. **Cancel is a first-class outcome.** It is not an error state.
2. **One reason, one response.** Relevance beats a wall of offers.
3. **No dead ends.** A customer can return to cancellation without losing progress.
4. **Consequences before commitment.** Billing, access, and data status appear before confirmation.
5. **A save must persist.** Reversal clicks are not retained value.
6. **Trust concerns are resolved, not discounted.**

## 7. Scope and experience

### 7.1 Entry and eligibility

- Keep “Cancel membership” visible in the existing subscription settings hierarchy.
- Do not require search, chat, or a phone call.
- Determine offer eligibility using plan, billing status, prior offer history, and reason.
- The exact commercial threshold is [REDACTED — pricing eligibility model].
- If eligibility cannot be resolved within 300 ms, render the no-offer path. Do not block cancellation.

### 7.2 Step 1 — reason

Ask “What changed?” with four top-level reasons:

1. costs too much right now;
2. not using it enough;
3. missing something needed; and
4. privacy or trust concern.

Include “Something else” and “Skip.” One optional free-text field appears only after “Something else.” The response must never be required.

### 7.3 Step 2 — consequences and relevant alternative

Always show:

- effective cancellation date;
- final charge status;
- paid-access end date;
- data retention and export status; and
- primary “Cancel membership” action.

If eligible, show one alternative above the cancel action:

| Reason | Allowed response | Not allowed |
|---|---|---|
| Cost | Pause or lower-priced plan | Countdown discount, preselection |
| Low use | Guided restart or pause | Unsupported value claims |
| Missing capability | Feedback capture + honest status | Roadmap promise |
| Privacy/trust | Data controls or direct support in parallel | Discount, delayed exit |
| Other/skip | No offer by default | Generic offer carousel |

### 7.4 Confirmation

After cancellation, show a durable confirmation with:

- “Membership cancelled” as the page heading;
- cancellation timestamp and effective date;
- access and data status;
- confirmation email status; and
- a reference ID for support.

Do not place a resubscribe promotion above the confirmation.

## 8. Functional requirements and acceptance criteria

### FR-01 — Self-serve entry

**Requirement:** Eligible customers can start cancellation from subscription settings.

**Acceptance criteria**

- **Given** an eligible direct web subscriber, **when** they open subscription settings, **then** “Cancel membership” is visible without opening help content.
- **Given** an ineligible billing type, **when** the customer selects cancellation, **then** the product names the billing owner and provides the correct next action.
- **Given** a keyboard-only user, **when** they navigate the page, **then** focus order follows visual order and every action is operable without a pointer.

### FR-02 — Optional reason capture

**Requirement:** Customers may provide one structured reason or skip.

**Acceptance criteria**

- **Given** no reason is selected, **when** the customer chooses “Skip,” **then** they advance without validation error.
- **Given** a reason is selected, **when** the customer advances, **then** exactly one `cancel_reason_selected` event is emitted with taxonomy version.
- **Given** free text, **when** it is submitted, **then** it is excluded from offer eligibility and stored under the approved retention policy.

### FR-03 — Reason-matched response

**Requirement:** At most one alternative is rendered for an eligible customer.

**Acceptance criteria**

- **Given** zero eligible alternatives, **when** step 2 loads, **then** cancellation renders without an empty offer container.
- **Given** multiple technically eligible alternatives, **when** step 2 loads, **then** the rules service returns one ranked response or none.
- **Given** a privacy/trust reason, **when** step 2 loads, **then** no price incentive is displayed.
- **Given** the rules service times out after 300 ms, **when** step 2 loads, **then** the no-offer path renders and cancellation remains available.

### FR-04 — Equal-action clarity

**Requirement:** Viewing an alternative must not obscure or weaken the cancel path.

**Acceptance criteria**

- The cancel action uses the explicit label “Cancel membership”; “Continue,” “Confirm,” or double negatives are not accepted.
- No alternative is preselected.
- Returning from alternative detail restores the same reason and scroll position.
- Cancel action contrast, tap target, and accessible name meet the same internal UI standard as the alternative action.

### FR-05 — Consequence disclosure

**Requirement:** The customer sees billing, access, and data consequences before the final action.

**Acceptance criteria**

- Effective dates use the customer's locale and time zone.
- If the customer retains paid access through term end, the product does not say access ends “today.”
- If data policy cannot be retrieved, the final action remains available and the copy links to the canonical policy; an error event is emitted.

### FR-06 — Idempotent cancellation

**Requirement:** Repeated confirmation cannot produce duplicate cancellation operations.

**Acceptance criteria**

- A double click creates one billing cancellation request.
- A network retry with the same idempotency key returns the original result.
- If billing succeeds and analytics fails, the customer still sees confirmation; analytics retries asynchronously.
- If billing fails, no success state is shown and the customer receives a retry path plus reference ID.

### FR-07 — Durable confirmation

**Requirement:** Customers can verify the completed state later.

**Acceptance criteria**

- Subscription settings show “Cancels on [date]” within five seconds of success.
- A confirmation email is queued within one minute.
- Refreshing or returning to the page does not show an active renewal state.

## 9. Analytics and instrumentation

Required events:

```text
cancel_flow_started
cancel_reason_selected
cancel_reason_skipped
cancel_response_viewed
cancel_response_accepted
cancel_confirmation_viewed
cancel_completed
cancel_failed
subscription_reactivated
meaningful_product_action_completed
cancel_support_contact_created
```

Every event includes: anonymous account key, experiment assignment, plan family, billing channel, locale, taxonomy version, and event timestamp. Free text, exact price, and sensitive-reason detail are excluded from the experiment payload.

## 10. Experiment and rollout

- Randomization unit: billing account.
- Eligibility: direct web subscribers who initiate cancellation.
- Holdout persists for the experiment duration, including repeat attempts.
- Ramp: employee → 5% → 25% → 50% → decision.
- Do not ramp on the same day as a price, billing, or refund-policy change.
- Stop immediately for duplicate charge/cancel incidents, materially lower completion, or privacy event leakage.

See [EXPERIMENT_PLAN.md](EXPERIMENT_PLAN.md) for hypotheses, sizing inputs, and stopping rules.

## 11. Dependencies

| Dependency | Owner | Failure behavior |
|---|---|---|
| Billing cancellation API | Billing Platform | Show retry + reference ID; never show false success |
| Offer eligibility service | Growth Platform | Fall back to no offer after 300 ms |
| Entitlement status | Identity/Access | Use canonical billing date and log mismatch |
| Data-retention copy | Privacy/Legal | Link canonical policy if service unavailable |
| Email service | Lifecycle | Do not reverse cancellation; retry asynchronously |

## 12. Risks and mitigations

| Risk | Why it matters | Mitigation |
|---|---|---|
| Save metric rewards accidental retention | Creates a dark-pattern incentive | Count 30-day voluntary retained value + meaningful action |
| Offer cannibalization | Customers who would stay take a cheaper option | Include persistent holdout and contribution-margin analysis |
| Reason quality is performative | Customers select fastest option | Keep optional; compare reason with downstream behavior |
| Edge-case billing state causes harm | Money errors destroy trust | No-offer fallback, idempotency, staged ramp |
| Accessibility regression | Blocks the exit for some users | Keyboard, screen-reader, zoom, and contrast acceptance tests |

## 13. Open questions

1. Does a pause preserve the same re-entry value for annual and monthly subscribers?
2. Should “financial hardship” bypass every commercial response?
3. What is the minimum sample required for reason-level decisions without false precision?
4. Who owns reason taxonomy governance after launch?
5. How will support identify a customer's exact experiment state?

## 14. Launch checklist

- [ ] Design review complete, including no-offer and failure states
- [ ] Legal/privacy copy approved
- [ ] Accessibility audit passes at 200% zoom and keyboard-only
- [ ] Billing idempotency and recovery tests pass
- [ ] Event QA matches the metrics contract
- [ ] Support macros and reference-ID lookup ready
- [ ] Experiment assignment verified; no sample-ratio mismatch
- [ ] Dashboard and alerts live before external exposure
- [ ] Named on-call owner for first 72 hours