Field notes · 2026-06-12
How to read plan-switch timing against billing dates
Most plan changes cluster near renewal. Here is a practical way to separate billing-driven switches from product-driven ones.
When a customer changes plan three days before renewal, the reason is often different from a change made mid-cycle after a feature trial. Treating both as the same 'switch' hides the story.
Start by anchoring every plan-change event to the next billing date for that account. Build two windows: a near-renewal band (for example, seven days before charge) and a mid-cycle band. Compare volume and destination plans in each band separately.
Near-renewal switches frequently track price sensitivity, forgotten trials ending, or support conversations that surface during invoice reminders. Mid-cycle switches more often follow onboarding milestones, usage spikes, or a failed attempt to invite teammates.
If your instrumentation only stores 'plan_changed' without the previous and next plan IDs, stop and fix that first. Timing analysis without destination and origin plans is noise.
In practice we ask teams in Malaysia to pull one full billing month plus the surrounding week. That length is long enough to see renewal clustering without drowning the first readout in edge cases.