SaaSのチャーンを減らすための多くの文章は、チャーンに専念する担当者がいる企業を対象としています。ヘルススコア、CSMプレイブック、四半期ビジネスレビュー。もしあなたがStripeやLemon Squeezyを通じて請求されるセルフサービス製品を出荷している2人のチームであれば、今年はそれらのどれもあなたには当てはまりません。

これはもう一つのバージョンです。リテンション機能もアナリストもなく、一週間の努力を前提としています。以下のすべては、実際のAPIコールが重要なところで使われ、スキップすべきことのリストと共に、あなた自身で構築できるメカニズムです。

まず、これが本当に最大の問題かどうかを確認する

チャーンに1週間を費やす前に、算数に10分を費やしましょう。チャーン計算機は、現在のチャーン率が1年間でどれだけのコストになるか、部分的な回復がどれだけの価値があるかを計算する重要な数学を行います。

月間収益12,000ドルと月間チャーン率4%の入力を示すOutroチャーン計算機、計算結果として月間収益損失、年間収益損失、年間回復可能収益が表示されている

$12,000のMRRと4%の月間チャーン率では、月に$480、年間で$5,760の損失が報告され、キャンセルしようとする顧客の4分の1を救うことができれば、年間で$1,440を回復可能としています。このツールは、MRRが大体一定であると仮定した大まかな見積もりであることを明示しているので、精度よりも形を読み取ってください。月間の数字は耐えられるように見えますが、年間の数字は通常そうではないため、チャーンは月ごとに先送りされます。

まずは自分の数字を計算してください。年間の数字があなたの1週間の時間よりも小さい場合は、機能を構築することに専念しましょう。

始める前に2つの測定に関する注意点:

顧客チャーンだけでなく収益チャーンを追跡する : $10のアカウントを10件失うことと、$1,000のアカウントを1件失うことはどちらもチャーンですが、同じ問題ではありません。ロゴだけを数えると、最大の損失が最小の数字の中に隠れてしまいます。
コホート年齢でセグメント化する : 月1でキャンセルする顧客はオンボーディングされておらず、月14でキャンセルする顧客はニーズが変わったのです。それらを平均化すると、誰も説明しない率が生まれます。

Day 1: 自発的チャーンと非自発的チャーンを分ける

これは最も重要な区分であり、多くの小規模チームが見逃す部分です。

非自発的チャーン は支払いの失敗です。有効期限切れのカード、不足している資金、銀行が越境請求を拒否することなどです。顧客は離れることを決めたわけではなく、離れたことに気づいていないかもしれません。

自発的チャーン は顧客が意図的にキャンセルをクリックすることです。

これらは異なるメカニズムを必要とし、単一のツールで両方をカバーすることはできません。Outroを含むキャンセルフローは、非自発的チャーンには全く触れることができません。なぜなら、インターセプトするキャンセルイベントがないからです。誰も何もクリックしません。サブスクリプションは単に支払いを停止します。

したがって、これをあなたの請求プロバイダーの機能で処理してください。Stripeには再試行スケジュールとカード更新メールを含む収益回復があり、Lemon Squeezyはチェックアウトの側でダニングを処理します。それらをオンにし、メールがあなたが管理するドメインから送信されることを確認し、それから非自発的チャーンを脇に置いてください。これは製品の問題ではなく設定の問題であり、ここで最も安価な勝利となります。

残りの週は自発的チャーンです。

Day 2: 理由をカテゴリーではなく言葉で捉える

理解できない解約を減らすことはできません。そして、それを理解するための標準的な手段は5つの選択肢があるドロップダウンです。そのドロップダウンは一方向に一貫して嘘をつきます。

ドロップダウンは、顧客に状況的な不満をあなたの語彙に圧縮するよう求めます。そして「Too expensive」は社会的に受け入れられる選択肢なので、近くのすべてを吸収します。本当の価格感度、「設定を完了しなかった」、「必要な機能が欠けていた」、そして「予算が削減された」はすべて同じ言葉で表現され、4つの異なる対応が必要です。

したがって、顧客が解約する瞬間に彼ら自身の言葉で尋ねてください。その瞬間、彼らは最大限に正直であり、技術的にはまだあなたの顧客です。

短い謝罪文がヘッダーにあるブランド化された解約ページ、ラジオボタンの解約理由、オプションのメールフィールド、入力の代わりに音声で回答を記録する目立つオプションが表示されている

構造化された理由はまだそこにあります。なぜなら、それは何もコストがかからず、集計報告を簡単にするからです。データ品質を変えるのは、それらの横にある録音オプションと、スキップが見えるままであるという事実です。解約の瞬間に必須の質問をすると、反感を持った曖昧な回答が返ってきます。

もしあなた自身で質問を書くなら、退会アンケートの質問とテンプレートのセットから盗む価値があります。また、退会時の音声の優位性は、音声での回答がより長く、具体的に返ってくる理由を説明しています。

何を構築するにしても、自由形式の回答を小さな固定分類に分類してカウントできるようにしてください。Outroは7つのバケットを使用しており、それぞれが明確な対応に対応しているため、自作バージョンの出発点としても合理的です。これらはCSVエクスポートで自動化を構築する場合に重要な正確な識別子です:

too_expensive : 異議は予算または費用対効果に関するもの。
missing_features : 求められた仕事を妨げる能力のギャップ。
not_using : 低使用率、もはや必要ない、または単に忘れられている。
too_complex : オンボーディングまたはインターフェースの摩擦、時には最初の週に致命的。
technical_issues : バグ、障害、修復されずに残った何か。
switching : 競合他社が勝った、最も商業的に価値のある正確に記録すべき回答。
other : 明確な製品理由がない、理解不能な回答やこれらのカテゴリー外の何か（例えば、ビジネスの閉鎖など）。

最後のバケットはその価値があります。それがなければ、6つの中から選ばざるを得ない分類器は、本当に分類できない回答を最も悪くないバケットに押し込み、結果をシグナルとして読むことになります。

7つのバケットで十分です。15にすると、どのバケットにも行動を起こすのに十分な回答が得られません。

Day 3: 4つのオファーを構築する

理由がわかったら、その理由に応じて対応しましょう。すべての人に一律の割引を提示するのは簡単だからデフォルトになっていますが、実際には大きな損害を与えます。なぜなら、顧客に対して、退会をちらつかせることで価格を下げる方法を教えてしまい、価格に敏感な顧客とそのトリックを学んだ人を区別する能力を破壊してしまうからです。

4つのオファーは、上記の分類のほとんどをカバーしており、それぞれの実装にかかるコストは以下の通りです。

キャンセル中に表示される保存オファー画面。3か月間50%オフの一度限りのオファーを提示し、主要な承諾ボタンと「いいえ、キャンセルします」というプレーンテキストリンクが表示されている

ツールに関係なくコピーする価値のある2つの詳細があります。オファーは無期限ではなく期間限定であるため、既知のコストと自然なレビュー時点があります。そして、辞退のパスはプレーンテキストで直接下にあり、2回目の確認の背後に隠れていません。なぜなら、去ることを決意した人はどちらにしても去るからであり、残された唯一の変数はその後のあなたの評価です。パターンを並べて見たい場合は、キャンセルフローの例の広範な調査があります。

一時停止、not_usingの場合。 Stripeは一時停止をサポートしています pause_collectionを使用して、請求を停止しながらサブスクリプションを維持します。

const stripe = require('stripe')(process.env.STRIPE_SECRET_KEY);

await stripe.subscriptions.update(subscriptionId, {
  pause_collection: {
    behavior: 'void',
    resumes_at: Math.floor(Date.parse('2026-11-01') / 1000),
  },
});

このコードでは、behaviorをvoidに設定して、一時停止中に生成された請求書が後で回収されるのではなく無効になるようにし、resumes_atを請求を再開する日付のUnixタイムスタンプに設定します。シークレットキーはソースからではなく環境から取得します。顧客はデータを保持し、あなたは新たなサインアップの決定なしに再開する関係を維持します。一時停止は保存された収益ではなく、延期された収益であり、一部は再開しないため、別途報告してください。それでもキャンセルよりはましです。なぜなら、一時停止した顧客はリマインドでき、キャンセルした顧客は再取得しなければならないからです。

割引、too_expensiveの場合。 事前に作成したクーポンをdiscountsまたはcouponと共に渡すsubscriptions.update呼び出しです。

await stripe.subscriptions.update(subscriptionId, {
  discounts: [{ coupon: process.env.STRIPE_SAVE_COUPON_ID }],
});

上記のコードは、既存のクーポンをライブサブスクリプションに添付しますので、固定期間のクーポンを一度作成し、設定からIDで参照します。キャンセルごとにその場でクーポンを作成すると、後で監査できない一回限りの割引オブジェクトが山積みになります。

ダウングレード、「このプランは現在のニーズに合っていない」場合。 サブスクリプションアイテムの価格交換です。

const sub = await stripe.subscriptions.retrieve(subscriptionId);

await stripe.subscriptions.update(subscriptionId, {
  items: [{ id: sub.items.data[0].id, price: process.env.STRIPE_PRICE_STARTER }],
  proration_behavior: 'create_prorations',
});

このコードでは、既存のアイテムIDを取得するためにサブスクリプションを取得し、そのアイテムの価格を下位層に交換します。proration_behaviorをcreate_prorationsに設定することで、残りの期間を黙って贈与したり二重請求したりすることなく、計算を正直に保ちます。ダウングレードは、完全な損失を部分的な収益保持に変えるため、キャンセル画面に表示されるべきであり、アカウント設定だけに表示されるべきではありません。

Lemon Squeezyでは1つのギャップを予想してください。 サブスクリプションの変更はPATCH /v1/subscriptions/:idを通じて行われ、リクエストはJSON APIコンテンツタイプを使用しなければ拒否されます。

curl -X PATCH "https://api.lemonsqueezy.com/v1/subscriptions/$LS_SUBSCRIPTION_ID" \
  -H "Authorization: Bearer $LEMONSQUEEZY_API_KEY" \
  -H "Content-Type: application/vnd.api+json" \
  -H "Accept: application/vnd.api+json" \
  -d "{\"data\":{\"type\":\"subscriptions\",\"id\":\"$LS_SUBSCRIPTION_ID\",\"attributes\":{\"variant_id\":$LS_TARGET_VARIANT_ID}}}"

上記のコードは、サブスクリプションを異なるバリアントに向けることでダウングレードし、APIキーと両方のIDは環境変数から読み取ります。注意すべきヘッダーはContent-Type: application/vnd.api+jsonであり、通常のapplication/jsonリクエストはこのエンドポイントに対して失敗します。一時停止は異なる属性で同じエンドポイントに存在し、Lemon SqueezyサブスクリプションAPIに文書化されています。割引はそうではありません。なぜなら、Lemon Squeezy APIは既存のサブスクリプションに割引を適用できないため、そこでの提供には手動のステップと約束が守られるまで追跡するものが必要です。

Day 4: 正直に保存を定義してから、カウントを始める

このステップは、リテンションシステムを単なる気分を良くする数字から分けるものです。誰かが「サブスクリプションを維持する」をクリックした瞬間に保存をカウントすると、保存率は素晴らしく見えますが、意味はほとんどありません。その顧客の中には2日後にキャンセルする人もいれば、割引を受け入れて期限が切れるとすぐに解約する人もいます。

Outroは、14日間の猶予期間の後にのみ保存をカウントし、その時点でサブスクリプションがまだ有効である場合に限ります。自分の実装も同じ基準に従いましょう。それは数行のロジックと、請求プロバイダーに対する遅延チェックだけであり、回復率を知ることと推測することの違いです。

このアカウントに請求プロバイダーがリンクされていないため、支払いプロバイダーを接続する空の状態を示す収益回復ページと、手動適用を待つ受け入れられたオファーのリスト

このスクリーンショットはテストアカウントからのもので、結果ではなく構造を読むためのものです。プロバイダーがリンクされていないため、「支払いプロバイダーを接続する」空の状態を示しており、手動で適用されるのを待っている受け入れられたオファーのキューも表示されています。キューは内面化すべき部分です。請求システムに到達しない受け入れられたオファーは、オファーがないよりも悪いです。なぜなら、顧客が再び信頼するかどうかを決める瞬間に約束を破ったことになるからです。

Day 5: 週に1つの習慣を作り、それ以上はやめる

チャーン対策の作業は、怠慢よりも野心から失敗することが多いです。2回しか確認しないダッシュボードを作るのではなく、5分間の定期的なレビューを1つ作りましょう。

Outroは、誰が離れたのか、理由は何か、リスクにさらされているMRR、保存されたMRR、主な理由、オファーのパフォーマンスをカバーする月曜日のダイジェストメールを送信します。自分で作成する場合、そのリストは週次のcronジョブに適した範囲です。ダイジェストはダッシュボードよりも優れています。それは存在を忘れていても届くからです。

データが蓄積されたときの様子

このループの出力は感覚ではなく、特定の人に渡せるランク付けされたリストです。

Outroのインサイトビューからのトップテーマの棒グラフ。キャンセルが最大の棒で、次に価格、コスト、予算、チームサイズ、製品品質、missing_features、ユーザーフィードバックが続く

これらの棒は、16件の記録された退出インタビューから抽出された実際のテーマであり、キャンセル7、価格6、コスト3、予算2、チームサイズ2、製品品質2、missing_features 2、ユーザーフィードバック2のカウントがあります。ただし、これはテストアカウントでの16件の回答に基づいているため、順序は参考程度に扱い、そこに描かれるトレンドラインの形状は無視してください。実際のアカウントでは、これらが数ヶ月にわたって蓄積されます。

各回答の要約がアクションの中心です。その実行からの2つの実際の例は、「ユーザーは小さなチームにとって価格が大きな問題であることを懸念している。」と「ユーザーはセットアップ中に混乱し、ウィジェットの埋め込みとオファーの設定に苦労した。」です。

それぞれがどこにルーティングされるかを見てください。最初のものは価格階層の問題で、おそらく非常に小さなチームにとって急なジャンプであるため、価格ページを担当する人に送られます。2つ目はオンボーディングの問題で、2つのステップが名前付きであるため、製品に送られます。どちらも「チャーンを減らす」ではありません。どちらも今週中に誰かが完了できるタスクであり、これがこの演習の全価値です。述べられた理由と実際の理由が異なる理由については、SaaS顧客がキャンセルする理由を参照してください。

Common mistakes

クライアントサイドのパラメータを信頼してオファーを実行すること。 フローが ?outro_offer=discount のような形でアプリにリダイレクトする場合、そのパラメータはブラウザから来ており、誰でも入力できます。何かを適用する前に、この顧客が本当にキャンセル中であるかを自分の記録に基づいてサーバーサイドで確認し、特定のオファーが何回まで利用可能かを制限してください。ハッピーパスが問題なく動作するため、見逃しがちです。

自発的なチャーンと非自発的なチャーンを一緒に平均化すること。 カードの有効期限切れの問題を製品の変更で修正したり、製品の問題をリトライロジックで修正したりすることになります。

自分のデータ収集でキャンセルをブロックすること。 転写、分類、またはオファーの検索が遅い場合でも、キャンセルは完了しなければなりません。誰かが去った理由を知ることはあなたの問題であり、彼らの問題ではありません。

機能が不足していると伝えた人に割引を提供すること。 クーポンは機能を追加しません。それは明確な製品シグナルを小さな請求書に変え、同じ会話をもう1か月続けるだけです。

回答を読む前にオファーを作成すること。 先にオファーを設計するチームは、支配的だと仮定する理由に基づいて構築します。録音は通常、異なる意見を示します。2〜3週間キャプチャしてから決定してください。

このプレイブックで意図的に省略していること

Failed-payment recovery : キャンセルフローではなく、請求プロバイダーによって処理されます。Outroは督促を行いません。
Health scores and usage-based churn prediction : 毎日のアラートリストに基づいて誰かが行動できる規模で役立ちます。それ以下では、アラートは未読のまま積み重なります。
Deep integration plumbing : Outroの現在の出力は週次ダイジェストとCSVエクスポートです。公開REST API、Webhook、npmパッケージ、Zapier、Make、n8n、Slackの統合はありませんので、キャンセルイベントを自動的に他の場所に送信する計画がある場合は、CSVを計画に含めてください。
Win-back campaigns : 実際の戦術であり、別のプロジェクトです。まずは退出を行ってください。それが、Win-backメールに何を記載すべきかを教えてくれます。

短いバージョン

非自発的なチャーンを分けて、請求プロバイダーに処理させましょう。解約の瞬間に1つの質問をし、人々が自分の言葉で答えられるようにします。それを小さな固定分類に分類します。停止、割引、ダウングレード、正直なノーを使って4つの理由に合わせたオファーを構築します。猶予期間の後にのみ保存をカウントします。週に1回ダイジェストを読みます。それが全体のループであり、どのステップも過剰に磨き上げなければ1週間で収まります。

Outroは、私たち自身が構築し運営しているこのバージョンであり、StripeやLemon Squeezy上でセルフサービスSaaSのための音声退出インタビュー付きの解約フローです。AI分類と理由に合わせたオファーが解約完了前に適用されます。プランは月額$0、$29、$79、$199です。上記のすべてのスクリーンショットはモックアップではなく実際の製品であり、収益回復ページの空の状態も含まれています。チャーン計算機はアカウントなしで無料で使用できます。

SaaSチャーンを減らす方法: 実践的なプレイブック