Case study · Doktorsitesi.com

Subscription Cancellation Module

A self-serve cancellation and refund path for subscribers, plus an ops view so the company can track payments, bills, and why people leave — wired into online payment and billing providers.

BillingPaymentsRefunds

Context & role

At Doktorsitesi.com I owned this module end-to-end as Product & Project Specialist: clarifying the cancel experience, writing the PRD, shaping the backlog with engineering, and shipping through stage and production testing. It sits inside the broader subscription and billing surface used by our product suite.

The problem

Cancelling a subscription was opaque and often manual. Users did not always know what would happen to their access or refund. Internally, teams struggled to see payment status, related bills, and the real reasons people cancelled — which made support slower and product decisions guesswork.

The solution

We shipped one module with two audiences. For users: a clear cancel journey with reason capture, confirmation, and refund status. For the company: a tracking surface for payments, bills, and cancellation reasons, backed by online payment and billing integrations so refunds and invoices stay in sync.

User cancel flow

Scroll into view to watch the process: user inputs move through cancellation steps and land in the ops panel with payments, bills, and reasons synced.

From the user

  • Cancel reasonWhy they leave
  • ConfirmationAccess end date
  • SubscriptionActive billing plan
Refund status
  1. 1User starts cancellation
  2. 2Reason is captured
  3. 3Refund is processed
  4. 4Ops sees the full trail

Ops panel

doktorsitesi.com/panel/cancellations

Ops & integrations

The company side: track what money did, which bills apply, and why people cancelled — with payment and billing systems in the loop.

Payments

Ops can follow payment state across the cancel and refund path instead of chasing screenshots in Slack.

Bills

Related bills stay attached to the cancellation so finance and support share the same source of truth.

Cancellation reasons

Structured reasons accumulate into a dataset product can actually prioritize against.

Outcomes

  • Users can cancel without a support ticket maze
  • Refunds and bills are traceable next to the cancellation
  • Cancellation reasons feed clearer product and retention decisions

What's next

Want more context on how I ship product work, or to talk about a similar billing problem?