月次経営レビュー、月次 EC 定例、月次 CS ミーティング — 業態を問わず、多くの事業者様で月一の数字確認の場が設けられています。その場で「先月の解約数」「MRR の変動」「新規獲得件数」は議論されているはずです。ところが、「先月の決済エラー由来の解約は何件で、いくらだったか」を独立した議題として扱っている事業者様は、それほど多くありません。多くは「解約数」という 1 本の数字に、能動的解約（顧客が辞めると決めた）と決済エラー由来解約（顧客は使い続けたかったが課金が止まった）が混在したまま、流れていきます。
「解約数」と「MRR 変動」だけでは内訳が見えない
月次レビューで頻繁に登場する新規獲得・解約件数・チャーン率・LTV・CAC といった指標は、いずれも経営判断に欠かせません。一方でこれらは「結果」を集計したものであり、解約の内訳までは見せてくれません。
たとえば「先月の解約 MRR は ¥120,000」と報告されたとき、それが「ほぼ能動的解約」なのか「半分以上が決済エラー由来」なのかで、打つべき手は大きく変わります。前者であればプロダクト・価格・カスタマーサクセスのレバーを引くべきです。後者であれば、まず決済エラー由来の解約を止める運用設計が先決です。「解約数」「MRR 変動」だけを見ていると、この内訳が常に隠れてしまいます。
月次振り返り KPI の 4 軸
決済エラー由来チャーンを月次の議題に乗せるためには、以下の 4 軸で数字を整理するのが現実的です。
1. 回収できた件数 / 金額（先月戻せた成果）
リトライ・カード更新案内・個別連絡などを経て、最終的に課金が再開した件数と金額です。「戻せた金額」が見えると、決済エラー管理が「いくらの売上を守っているか」が経営層にも伝わり、コストセンターから「売上を守る運用」に位置づけが変わります。
2. 回収できなかった件数 / 金額（残った問題の規模）
リトライしても戻らず、最終的に解約扱いになった件数と金額です。これがまさに「決済エラー由来チャーン」です。解約 MRR からこの金額を引いたものが、純粋な能動的チャーンに近い数字になります（受動的チャーンの全体像はこちら）。
3. 戻せなかった理由の内訳
回収できなかったエラーを、カード期限切れ・不正検知・残高不足・認証エラー・その他に分類して提示します。海外の参考値では、カード期限切れだけで全体の 35〜40%（参考値）を占めるとされています。商材・価格帯・顧客属性によって分布は変わるため、自社の数字を当てはめる際は参考値としてご覧ください。重要なのは、内訳が見えると「来月どこから手をつけるか」が定まることです。
4. 次月の改善案（1〜2 個に絞る）
振り返りの目的は「報告」ではなく「次月の改善」です。戻せなかった理由の内訳から、来月優先的に取り組む改善案を 1〜2 個に絞ります。3 個以上並べると結局どれも進まないことが多くなります。
議題化されると何が変わるか
月次振り返りの議題テンプレが整うと、以下のような変化が期待できます。
- 経営層: 解約 MRR の内訳が見え、施策判断（プロダクト改善か / 運用改善か）の根拠が明確になる（MRR / LTV / CAC への影響を経営判断に組み込む方法は経営者が見るべき決済エラー KPI ダッシュボードを参照）
- EC・SaaS 担当: 回収できた金額が可視化され、決済エラー対応が「売上を守る業務」として認識される
- CS 担当: 顧客フォローの優先順位が明確になり、限られたリソースを「戻せる可能性が高い顧客」に集中できる
- EC・CS・経営層が同じ表を見て議論できる: 部門ごとに別の数字を見て議論する状態から、共通の KPI を見て議論する状態に変わる
地味ですが大きな変化です。月一の場で同じ表を見て、同じ言葉で議論できる状態が整うと、改善のスピードが目に見えて変わります。
Recovery Monitor の月次サマリー機能
議題テンプレを整えるには、4 軸の数字が毎月安定して集計されている必要があります。Recovery Monitor は決済エラー管理（Payment Error Management）のレイヤーを担うサービスで、決済代行会社のデータを読み取り、月次の以下のサマリーを自動集計します。
- 先月の決済エラー総件数 / 総金額
- 回収できた件数 / 金額
- 回収できなかった件数 / 金額（決済エラー由来チャーン）
- 理由別の内訳と、対応カテゴリ別の振り分け結果
経営層向けには月次レポートの下書きが AI で生成されます。Rule-first, AI-assisted の方針に従い、AI は集計結果の要約と次月の改善案ドラフトのみを担当し、議題化・送信・社内共有は事業者様の判断で行います。AI が顧客に直接メールを送信したり、課金処理を自動実行したりすることはありません。
まずは自社の規模感を確認する
記事中の数字は海外の参考値です。自社の月次振り返りでどの程度の決済エラー由来チャーンが見え隠れしているかは、過去数ヶ月の決済エラー件数 / MRR / 平均顧客単価から試算できます。決済エラー損失計算機と、実データで月次サマリーを試せる30 日間無料トライアルをご用意しています。
「先月の決済エラー由来の解約は何件で、いくらだったか」 — この問いを月次の議題に乗せることが、決済エラー管理の運用化の第一歩です。