解約率を改善するには、解約を妨げるのではなく、顧客が価値へ到達できない原因、利用障害、サポート、価格・契約、請求失敗を分けて直します。顧客数のチャーンと売上のチャーンは意味が異なるため、定義と期間を固定してコホートで確認します。
1. 解約率とは
一定期間の開始顧客のうち、期間中に解約した顧客の割合として扱うのが基本です。休会、無料化、未払い停止、プラン変更をどう扱うか明記します。
2. 顧客チャーン
解約顧客数を基にします。法人で一社が複数ユーザーを持つ場合、ユーザー削除と契約解約を分けます。注文件数を顧客数の代わりにしません。
3. 売上チャーン
解約や減額による継続売上の減少を見ます。顧客チャーンが同じでも契約規模で影響が変わります。追加購入や値上げを相殺するかどうかを定義します。
4. 期間
月次と年次を直接比べません。契約更新周期に合わせます。期間途中で開始した新規顧客を同じ分母へ混ぜないようにします。
5. コホート分析
初回契約月、プラン、獲得経路、用途別に同じ経過期間を比較します。Google公式のコホート定義を参考に、共通条件の顧客群を追います。
6. 初期チャーン
契約後すぐの解約は、期待のずれ、設定、データ移行、社内展開、初回価値到達を確認します。営業説明と製品体験が一致しているか見ます。
7. オンボーディング
顧客の目的別に必須操作を案内します。機能説明の完了ではなく、顧客が最初の価値を得たかを確認します。強制的な面談を解約条件にしません。
8. 製品・サービス品質
障害、速度、使いにくさ、品質差、在庫、提供遅延を記録します。利用不足を顧客の責任にせず、障害を除去します。
9. サポート
問い合わせが解決したか、同じ問題が再発していないかを確認します。解約希望者だけ特別対応するのではなく、通常の利用者を支援します。
10. 価格と価値
価格そのものと、価値が伝わらない問題を分けます。値引きで一時的に残っても、利用価値がなければ根本改善になりません。条件と終了後の価格を明示します。
11. 請求失敗
カード期限、残高、請求情報、システム障害などを区別します。再試行や通知は契約と同意に従い、不要な重複請求を防ぎます。
12. 解約導線
解約方法、効力日、返金、データ出力・削除を分かりやすくします。画面を隠す、電話だけにする、過度に引き止める方法で率を下げません。
13. 解約理由
短い選択肢と任意の自由記述を用意します。回答を必須にせず、回答者だけを全体とみなしません。複数理由を許可するか決めます。
14. 休会とダウングレード
顧客の用途に合う場合だけ選択肢として示します。解約を押した全員へ複雑なオファーを重ねません。条件、機能、データ保持を明示します。
15. 予兆モデル
利用減少や失敗を使う場合、誤判定を前提にします。顧客を「解約しそう」と断定せず、選択可能な支援を示します。センシティブな推測を使いません。
16. 改善優先順位
重大障害、説明相違、請求誤りを先に直します。件数、影響、再発、改善可能性を見ます。大口顧客だけを優遇し、他を放置しません。
17. 実験
一つのコホートでオンボーディングや通知を試します。解約率だけでなく、利用、サポート負担、苦情、解除を測ります。観測期間を揃えます。
18. データ品質
契約開始・終了、休会、再契約、統合、返金を確認します。管理画面上のステータスと請求結果が一致するか照合します。
19. 組織運用
営業、製品、サポート、請求が同じ解約定義を使います。解約率目標が解約妨害や不適切な営業を生まないよう監査します。
20. 改善チェック
顧客・売上の区分、期間、コホート、初期価値、品質、支援、価格、請求、理由、導線を確認します。業界平均を根拠なく成功基準にしません。
再契約の扱い
再契約を新規とするか復帰とするか決めます。解約と再契約を繰り返す顧客を別人として数えず、同意の範囲で履歴を関連付けます。
まとめ
チャーン改善は解約操作を難しくすることではありません。定義とコホートを揃え、初期価値、品質、支援、価格、請求の原因を分けて改善し、顧客の解約する自由を守ってください。
定期レビュー
月次では指標と異常、四半期では原因分類と施策、商品・契約変更時には定義を見直します。解約理由の選択肢が現状に合わなくなっていないか、未回答や「その他」が増えていないかも確認します。改善済みの原因は監視を続け、再発した場合に担当部門へ通知します。
報告書には顧客数、売上、期間、コホート、除外条件、データ更新日を併記します。役員向けの要約でも分母を省かず、推測と確認済み事実を区別してください。
計算対象を固定する
月初に契約中だった顧客を分母とする場合、月中の新規はその月の顧客チャーン分母へ入れません。月中に開始して同月に解約した顧客をどう扱うかは別に記録します。期首・期末のスナップショットとイベント履歴を照合します。
売上チャーンでは、解約による減収、プラン縮小、値引き、返金を分けます。拡張売上を差し引いたネット指標と、差し引かないグロス指標を同じ名称で表示しません。通貨、税、為替の扱いも固定します。
自発的解約と非自発的解約
顧客が意思を持って解約した場合と、支払い失敗や事務エラーで停止した場合を分けます。後者は請求情報更新、通知、再試行の問題が中心で、製品価値の改善とは対応が異なります。
ただし、支払い失敗後の連絡を無制限に繰り返しません。契約、法令、同意に従い、回数、間隔、終了条件を決めます。支払ページは安全な公式導線を使い、メールで機密情報を求めません。
解約面談の設計
高額契約で面談が必要な場合も、解約を妨げる手段にしません。契約上必要な通知方法、期限、効力日を明確にし、担当者の都合で処理を遅らせない手順を作ります。
理由を聞く場合は短く、回答しない選択を認めます。営業提案、休会、ダウングレードを提示するなら、顧客の申告理由に関係する選択肢だけに絞り、同じ提案を何度も表示しません。
プラン別に原因を読む
低価格プランと高価格プランでは、利用者、期待、サポート、契約期間が異なります。全体平均だけで原因を判断せず、同じプラン・経過期間のコホートを比較します。法人契約では導入担当者と実利用者を分けます。
特定プランの解約が多い場合、価格だけでなく、機能制限、上位プランへの誘導、説明、導入条件を確認します。解約理由アンケートの回答が少なければ、製品ログとサポート記録を補助として使います。
障害時の扱い
大規模障害の期間を通常チャーンと同じ分析へ混ぜると、日常施策の評価を誤ります。障害発生、影響範囲、復旧、補償、問い合わせを記録し、該当コホートを別途確認します。
復旧後に解約を思いとどまらせる連絡を優先せず、事実と対応を伝えます。未確認の原因や復旧見込みを断定しません。解約希望は通常どおり処理します。
予測モデルの監査
チャーン予測を使う場合、学習データ、目的変数、更新頻度、誤判定を確認します。過去に多く解約した属性をそのまま不利益な扱いへ使うと、偏りを再生産する可能性があります。
モデル出力は支援の優先候補として使い、価格やサービスを不透明に変える根拠にしません。人が理由を確認し、顧客が不要な連絡を停止できるようにします。
改善結果の読み方
解約率低下と同時に、新規獲得減少や契約期間変更が起きていないか確認します。年契約への移行で月次解約が一時的に見えなくなる場合もあります。更新到来後まで観測します。
率だけでなく、解約顧客数、期首顧客数、失われた売上、理由別件数を表示します。結果が良く見えるよう対象顧客を除外せず、除外条件を記録します。
この分野の実務を相談したい方へ
記事で扱っている内容は、当社が実務として支援している領域です。 自社で進めるか外部に任せるかの判断からご相談いただけます。