複数製品間のクロスセル最小実装：既存ユーザーが 30% を支える前に引く線

2026/9/15

B 方向·OPC 最佳实践（维度：既存ユーザーの拡張収入）。クロスセル 索引 0 命中——opc-product-portfolio-strategy（やめる/続ける判断）·indie-pricing-models（値付け）の間の実装論。

背景与问题

家族图谱を基盤に防诈→见守→终活と製品が横に並ぶ設計（モジュール寄生）——既存ユーザーを次の製品へ移す導線を最後に実装するつもりだったが、いつ・どこに・どう出すかの基準がまだない。実装は簡単でも、出すタイミングを間違えると churn を加速する。

拡張収入の規模感：cross-sell/upsell は年間収入の最大 ~30% を占め得る（Cloudmore）——新規獲得より既存拡張が効くのは SaaS 共通の構造。
最小実装の型：①features の gating（課金再構築でなく機能ゲート）で paywall 化 ②in-app プロンプトは機能上限に当たった瞬間（friction ポイント）に出す ③power user を狙い撃ち（全員に送らない）（SaaStock、Userpilot）。
upsell（大きいプラン）と cross-sell（別製品）の区別は Chargebee 流の定義——我々の場合「防诈→家計见守」「见守→终活」は同一基盤上の隣接機能なので、実態は「モジュール解放の upsell」に近い。

我々の最適解は「製品をまたぐ勧誘」ではなく「家族图谱上の機能解放」：新契約を増やさず、既存サブスクの上位プランにモジュールを積む（LINE 課金/Paddle 契約が 1 本のまま）——契約を分けると家族ユーザー（複数人の支払い権限問題、japan-family-caregiver-app）で混乱する。
出すタイミングの基準（推測）：①該当モジュールの困りごとが会話に現れた（話頭配信への反応/問い合わせ）②他モジュールの利用が安定期に入った（導入 2 週間+週 3 日利用）——この 2 条件を満たしたユーザーにだけ解放プロンプト。

可行动启发：

契約は 1 本·機能はプランで積む：製品ごとの独立契約を作らず「家族图谱ベースの階層プラン」（無料/見守り/終活フル）に集約——Paddle の price は 3 本だけにする（japan-b2b-cross-border-billing の課金単一化と整合）。
解放プロンプトは機能上限+会話シグナルの 2 条件：上限摩擦（例：家族メンバー 3 人まで）で初めて出し、話頭配信の反応タグ（opc-line-tagging-rules）で target 絞り——全員配信の banner は出さない。
30% 狙いより「家族ユーザーの滞留延長」を先に：cross-sell の前に既存製品の週次利用が安定しているか（heartbeat）——使っていない家族に次を出しても churn するだけ（opc-b2b-customer-success の未使用検知と同じ論理を C 端に適用）。
B 端（企業版）への upsell は別線：40 歳告知 OEM（japan-workplace-careleave-benefits）は家族プランとの併売でなく B 端別契約——C 端の cross-sell 設計と混ぜない。

opc-product-portfolio-strategy（組み合わせ判断）、indie-pricing-models（値付け）、opc-line-tagging-rules（ターゲティング）、opc-module-component-map（モジュール構造の前提）。