SECTION 01

What belongs in a cancellation record?

Start with one customer and one subscription reference. Build a short event timeline from the original request through the recorded outcome. A useful timeline lets another staff member retrieve the source and distinguish what happened from what someone entered later.

  • Customer and subscription reference, without copying unnecessary personal details.
  • Original request time, time zone, channel and ticket, message or portal-event reference.
  • Acknowledgment or reply, its time and a reference to the actual message.
  • Provider action time and the reported cancellation setting or status.
  • Scheduled end date and actual end date, with separate source references.
  • Any later charge, refund, reversal or disputed fact that needs review.
  • Who recorded the information, when they recorded it and the remaining question.
SECTION 02

Why keep request time separate from the end date?

A customer can ask to cancel while a subscription remains active through a paid period. Stripe, for example, supports cancellation immediately, at a period end or on a custom date. Those settings describe the provider’s action; they do not establish when an earlier email or support request reached your business.

Keep the time reported by each source. If a support ticket arrived first and the billing change happened later, retain both events. If the request time is unknown, say unknown. Do not substitute the billing end date just to fill the field.

SECTION 03

A fictional cancellation timeline

This example is made up to show the record structure. It does not establish an appropriate deadline or outcome for a real customer. All four times use UTC.

  • 3 November, 09:10: request received through support. Source: fictional ticket EXAMPLE-TICKET-104.
  • 3 November, 09:25: staff reply records a planned end on 30 November. Source: fictional reply EXAMPLE-REPLY-104. A saved reply does not establish delivery.
  • 3 November, 09:30: billing provider reports a scheduled cancellation. Source: fictional event EXAMPLE-PROVIDER-104.
  • 30 November, 23:59: provider reports that the subscription ended. Source: fictional event EXAMPLE-END-104. Record this only after the source reports it.
SECTION 04

How to use the free worksheet

Download the CSV and replace the fictional rows with events you are authorized to review. Keep one row per event, including the source’s time zone. Leave the outcome unknown until a source supports it. Keep your working copy and the original files in your business’s approved storage.

The worksheet is an event review aid, not a direct TermWitness import file. It does not process a cancellation, send a confirmation, calculate a legal deadline or decide whether a cancellation was handled correctly.

SECTION 05

What if your support and billing records disagree?

Retain both source statements and write down the specific difference. For example: support records a request on Tuesday, while the provider reports a change on Thursday. Assign an owner to review the original records instead of replacing one date with the other.

Record a later correction as a correction, with its reason and time. Keep the original message when available. If the source is a staff recollection rather than a contemporaneous record, label it that way.

SECTION 06

How TermWitness fits into the workflow

TermWitness lets your business keep subscription records and evidence events together, with cancellation request and effective events recorded separately. You can review a customer’s timeline, retain source references and export records. It does not cancel a subscription or send a subscriber message.

With the read-only Stripe connection, changes appear when your team presses Sync now. Stripe-reported timestamps retain their provider source. Keep any earlier support or portal request alongside them; a provider timestamp does not automatically establish the original customer request.

REFERENCES

Sources and further reading