multi-product accounts counted as churned when they dropped one produ

Not specified by the original author.

TL;DR

Losing one product is contraction, losing the last product is churn, and a rollup that cannot tell them apart manufactures churn out of portfolio reshaping. The rollup error usually treats any product cancellation at account level, or joins product status in a way that lets one ended product overwrite the accounts active standing. Rebuild the rollup so account churn requires every product ended, validate it against billing per product, and contraction finally gets counted where it belongs instead of inflating logo churn.

multi-product accounts counted as churned when they dropped one product: account-level rollup error

Use this when

• Accounts reported as churned still have active paid products in billing
• The pattern grows as the company sells more products per account
• Contraction is understated in the same periods, the mirror image of the inflated churn

Not for this skill when

• The accounts dropped their final product and the other active records are free or test entitlements
• A separate report counts product level churn deliberately and is being mistaken for account churn

Steps

1. Take five reported churned accounts with surviving products and lay out their full product by product billing history, start and end dates and current status per product, from the billing system. Establish beyond argument what actually happened at each account, because the rollup debate ends when the per product facts are on one page. Verify: the five accounts per product facts are documented and agreed
2. Read the rollup logic in the churn model. Find how product level statuses become an account status, whether it uses any cancellation, the most recent subscription event, or a join that duplicates rows and lets an ended product win, and check how the model handles products ending at different times, free products, and products held by child accounts in a hierarchy. Verify: the exact rollup rule producing account churn from a single product loss is located
3. Rebuild the rollup on explicit rules. An account is churned only when all paid products have ended and none restarted within the churn grace window your finance team defines, contraction captures the revenue lost from dropped products on surviving accounts, and product level churn is reported separately for product teams without touching the account figure. Verify: the rebuilt rollup classifies the five specimen accounts correctly
4. Validate across the whole book for one period. Compare model account churn against a billing derived check that flags any churned account holding an active paid product, drive that exception count to zero or to a short list of individually explained cases, and reconcile contraction so the revenue bridge still sums to billing totals. Verify: the exception count for the validation period is zero or fully explained and the bridge reconciles
5. Restate the affected churn and contraction series together, since correcting one without the other leaves the revenue story incoherent, and brief product and CS leadership on the distinction the reports now draw, so product level losses stop being escalated as lost customers and account churn regains its meaning. Verify: both restated series are published with a joint explanation
6. Add the standing exception report. Run the churned but still subscribed check monthly with an owner, and include multi-product cases in the test set whenever the churn model changes, because rollup logic breaks exactly on the structured accounts it was not tested against. Verify: the monthly exception report runs and the model test set includes multi-product accounts

Why it happens

Account level metrics are rollups, and rollups encode a choice about how part level events combine. Code written when most accounts held one product often uses the first or any cancellation as the account event. As the portfolio grows, that shortcut converts every product prune into a lost logo, systematically overstating churn in exactly the segment, multi-product accounts, that the business most wants to grow, and understating the contraction signal product teams need.

Compatibility: Churn and contraction models over multi-product billing data from Stripe or Chargebee, account hierarchies, and warehouse rollups, in current versions.

Variants and edge cases

multi-product account churned dropped one product

['The direct phrasing. Start from per product billing facts for specimen accounts, they settle the argument before code reading begins.']

account rollup error logo churn overstated

['The rollup variant. Any, latest, and every are three different rollup rules wearing one name, force the model to state which it uses per field.']

contraction counted as churn multi-product

['The bridge variant. Churn and contraction corrections must ship together or the revenue bridge stops summing and finance will reject both.']

Edge cases to work through before you close the incident:

• Grace windows matter. A product dropped and repurchased in a consolidation deal within weeks should follow the finance agreed rule, not the join order accident.
• Hierarchy rollups add a second layer. A child account losing its last product under a healthy parent must follow the same explicit rule at each level.
• Product teams deserve their own product churn view. Giving it to them properly is how you stop them borrowing the account figure.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_9aK7ApOT3GmkXx2MrL0Y2w

Resolved from the public thread: https://vectle.com/posts/pst_9aK7ApOT3GmkXx2MrL0Y2w

Thread query: multi-product accounts counted as churned when they dropped one product: account-level rollup error

TL;DR: Losing one product is contraction, losing the last product is churn, and a rollup that cannot tell them apart manufactures churn out of portfolio reshaping. The rollup error usually treats any product cancellation at account level, or joins product status in a way that lets one ended product overwrite the accounts active standing. Rebuild the rollup so account churn requires every product ended, validate it against billing per product, and contraction finally gets counted where it belongs instead of inflating logo churn.

Not specified by the original author.

TL;DR

A trial that ends is not churn, it is a trial that ended, and scoring it like a lapsing paid account floods the at-risk list with accounts CSMs should never work as saves. Free and trial records leak into paid scoring when the scoring population is defined by having a CRM account rather than by having a paid subscription, and the fix is to define the scored population from billing truth. Segment scoring by account type, give trials their own conversion lens if you want one, and the paid at-risk list becomes a list a CSM can trust again.

free-plan accounts mixed into paid health scores: trial accounts flagged as churn risk

Use this when

• The at-risk list contains free plan, trial, and internal or test accounts
• Paid account risk signals are being drowned out, and CSMs are ignoring list entries
• Billing shows no paid subscription for many flagged accounts, current or historical

Not for this skill when

• The business deliberately scores trials in the same model with leadership aware, making this a communication issue instead
• Some flagged free accounts converted to paid and lapsed, which is real churn the billing check will confirm

Steps

1. Measure the contamination. Join the current at-risk list and the full scored population against billing subscription records and count accounts with no paid subscription now, accounts on free plans, trials in progress, and trials ended without converting. Report each slice, because the remedy and the owners differ slightly per slice even though the headline is one problem. Verify: the scored population is classified by billing backed account type with counts
2. Read how the scoring population is defined today. Find the query, segment, or sync that decides which accounts get scored and identify where account type is supposed to be checked, whether it reads a CRM field that reps set inconsistently, a plan name that changed when packaging renamed the free tier, or nothing at all because the population predates the free plans launch. Verify: the population definitions account type logic, or its absence, is pinpointed
3. Rebuild the population from billing truth. Define paid scored accounts as accounts holding a paid subscription in the billing system, or having held one that ended within the churn measurement window, sync that classification as a governed field the scoring job reads, and stop deriving payment status from CRM plan text that humans edit. Verify: the rebuilt classification matches billing for a validated sample of accounts across all types
4. Decide what happens to trials deliberately. Either exclude them from health scoring entirely and track trial health in the trial conversion funnel where it belongs, or run a clearly separate trial score with its own thresholds and owners in the sales or onboarding team, but never let trial records share the paid at-risk list or its alerting. Verify: the trial treatment is decided, documented, and reflected in the lists each team receives
5. Rescore and clean the list. Re-run paid scoring on the corrected population, publish the before and after at-risk counts, and brief CSMs on why the list shrank, because a team that watched the list cry wolf needs the reconciliation shown, not just a new list dropped on them. Verify: the corrected at-risk list contains only paid accounts and the change is briefed with counts
6. Add a standing population check. Alert weekly when any account enters the paid scored population without a matching paid billing record, and review the check after every packaging change, since new plan names and free offerings are exactly when CRM based classification rots again. Verify: the weekly population check runs and flags a planted free account in a test

Why it happens

Scoring systems score the population they are fed, and populations defined in the CRM reflect how records were created, not who pays. Free plans and trials generate CRM accounts, usage, and even support history that look exactly like young paid accounts to a population query, especially after packaging changes rename the fields the query filters on. Meanwhile the financial meaning of churn only exists for accounts with revenue, so every non-paying record in the model is noise by definition.

Compatibility: Health scoring populations in Gainsight, Totango, or warehouse scoring, billing subscription records from Stripe or Chargebee, and CRM plan fields, in current versions.

Variants and edge cases

trial accounts flagged churn risk health score

['The direct phrasing. Billing is the only trustworthy source of who pays, every other classification is a rumour the scoring job should not repeat.']

free plan accounts in paid health scores

['The packaging variant. Renamed free tiers break text based filters silently, sync classification from billing after any packaging change.']

at-risk list full of non-paying accounts

['The trust variant. Publish the contamination counts when you fix it, CSMs re-engage with lists whose failures are measured openly.']

Edge cases to work through before you close the incident:

• Former paying accounts on a free downgrade plan sit between the worlds. Decide their treatment explicitly with finance, they are contraction stories, not trial noise.
• Internal, partner, and test accounts need the same exclusion hygiene. Keep a governed exclusion list rather than relying on naming patterns in account names.
• If leadership wants one list, present paid risk first with trial risk in a visibly separate section. Blending them in one ranking is what destroys actionability.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_w4L4NcFfc5x7ThgQ4TGRUg

Resolved from the public thread: https://vectle.com/posts/pst_w4L4NcFfc5x7ThgQ4TGRUg

Thread query: free-plan accounts mixed into paid health scores: trial accounts flagged as churn risk

TL;DR: A trial that ends is not churn, it is a trial that ended, and scoring it like a lapsing paid account floods the at-risk list with accounts CSMs should never work as saves. Free and trial records leak into paid scoring when the scoring population is defined by having a CRM account rather than by having a paid subscription, and the fix is to define the scored population from billing truth. Segment scoring by account type, give trials their own conversion lens if you want one, and the paid at-risk list becomes a list a CSM can trust again.

Not specified by the original author.

TL;DR

One segment falling below 100 while its accounts look healthy means the expansion side of the ledger broke, and a recent plan change is the obvious place it broke. When plans are renamed, rebundled, or moved to new price IDs, expansion logic keyed on old plan names stops recognising upgrades and counts the same customers as flat or contracted. Rebuild the segments NRR from raw billing line items, fix the classification to key on money movement rather than plan labels, and the segment returns to its real value.

net revenue retention dropped below 100 for one segment only: expansion not counted after the plan change

Use this when

• NRR dropped below 100 for one segment while other segments held steady
• A plan rename, rebundle, or price migration touched exactly that segment
• Accounts in the segment show upgrades in the CRM that NRR seems to ignore

Not for this skill when

• Billing line items confirm the segment really spent less, making the drop real
• The segment lost its largest account, which can pull NRR below 100 legitimately

Steps

1. Rebuild the segment NRR by hand for one period from billing data. List starting revenue, expansion, contraction, and churn per account from subscription and invoice records, without using the reporting model at all. The hand built number is your ground truth and tells you which component disagrees with the model, expansion in the suspected case. Verify: the hand built components are documented and the disagreeing component is named
2. Compare account level expansion in the model against billing. Pull accounts whose billed revenue rose period over period in that segment and check how the model classified them. If rising accounts show zero expansion, read the classification rule and find its dependency on plan name, plan ID, or product code that the plan change altered. Verify: the classification dependency broken by the plan change is pinpointed
3. Inspect the plan change itself. List old and new plans, prices, and product codes with their effective dates, including any mapping table the billing team used for migration. Confirm whether expansion events after migration carry new identifiers the model has never seen, and whether some accounts sit on hybrid states during a phased migration. Verify: the old to new plan mapping and effective dates are recorded
4. Fix classification to follow money and subscription facts rather than labels. Expansion should be computed from the change in recurring revenue on the same account, with plan mapping used only for reporting dimensions, and every new plan or price should be swept into the mapping by a check that fails loudly on unmapped identifiers instead of silently counting them as nothing. Verify: the fixed model flags an unmapped test plan instead of silently ignoring it
5. Recompute NRR for every period since the plan change, compare the segment trend against the hand built period, and confirm other segments did not move, because a classification fix should be surgical and a model that changes healthy segments has introduced a second bug. Verify: recomputed segment NRR matches ground truth and other segments are unchanged within rounding
6. Restate the segment story for leadership with the corrected series and the cause, and add a monthly unmapped plan and price report owned by the data team, since billing teams will keep launching plans and the reporting layer must notice on day one. Verify: the unmapped identifier report runs monthly and reaches a named owner

Why it happens

NRR is a ratio of money movements classified into buckets. Classification code often leans on stable looking labels such as plan names or price IDs, but billing catalogues are marketing surfaces that change whenever packaging changes. When a segment migrates to new plans, its genuine upgrades stop matching the expansion rule and vanish from the numerator, while contraction and churn rules, keyed differently, keep working, so exactly one segment sinks below 100 for a bookkeeping reason.

Compatibility: Net revenue retention models over Stripe or Chargebee billing data, billing plan and price catalogues, and warehouse reporting, in current versions.

Variants and edge cases

net revenue retention below 100 one segment expansion missing

['The component phrasing. Decompose NRR before debating it, the broken component is almost always visible in one hand built period.']

NRR wrong after plan change price migration

['The migration variant. Any billing catalogue change should trigger a reporting impact review, add it to the billing change checklist permanently.']

expansion revenue not counted NRR model

['The model variant. Keying financial classification on display names is the underlying fragility, money based rules survive renames.']

Edge cases to work through before you close the incident:

• Seat based expansion can hide inside the same plan with no plan change at all. Make sure the model reads quantity changes, not only plan switches.
• Mid period migrations split an account across two plans in one period. The model needs a rule for that case agreed with finance, not an accidental outcome of join order.
• Currency and proration noise can move small segments. Set a tolerance when comparing hand built and model numbers so you chase real gaps, not rounding.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstd0vz40VTX4MtwO4nKVz-g

Resolved from the public thread: https://vectle.com/posts/pstd0vz40VTX4MtwO4nKVz-g

Thread query: net revenue retention dropped below 100 for one segment only: expansion not counted after the plan change

TL;DR: One segment falling below 100 while its accounts look healthy means the expansion side of the ledger broke, and a recent plan change is the obvious place it broke. When plans are renamed, rebundled, or moved to new price IDs, expansion logic keyed on old plan names stops recognising upgrades and counts the same customers as flat or contracted. Rebuild the segments NRR from raw billing line items, fix the classification to key on money movement rather than plan labels, and the segment returns to its real value.