StripeのMRRが落ちたとき、最初の30分でやること
Stripe売上（MRR）が落ちたときに、最初の30分で原因を分解して止血する切り分け順です。
Stripeの売上（MRR）が落ちたとき、焦って料金や導線を触るとだいたい悪化します。最初の30分は「原因を分解して、止血できるものから順に潰す」だけに集中します。
この記事は、SaaS運営者向けの“切り分け順”です。数字が戻るまでの時間を短くするのが目的です。
0. まずやらないこと（事故りやすい）
- 料金をいきなり変更する
- プランを増やす/削る
- アプリを大改修する
- 返金ポリシーや利用規約の解釈を勝手に変える
原因が分からないまま触ると、原因がさらに見えなくなります。
1. 売上低下を3つに分ける（最優先）
まず、売上が落ちた“理由”を3つに分けます。
- 新規が減った（流入・CVR・営業・紹介）
- 解約が増えた（プロダクト価値/価格/競合/不満）
- 支払いが落ちた（カード失効・支払い失敗・請求失敗）
ここが混ざっていると、打ち手が全部ズレます。
2. 最初に確認する順番（30分版）
「すぐ止血できる可能性が高い順」で見ます。
- 支払い失敗が増えていないか（回収漏れ）
- 解約が“特定プラン/特定顧客層”に偏っていないか（局所崩れ）
- 新規獲得の入口が落ちていないか（Search / Ads / Referral）
- 返金/調整が増えていないか（オペミス/誤請求）
- 計測の欠損がないか（データの穴）
3. 支払い失敗（回収漏れ）を最優先で潰す
MRR急落の“最短復旧”は、支払い失敗が原因のケースが多いです。ここはプロダクトを変えずに戻せます。
- 直近24hで支払い失敗が増えていないか
- 失敗理由が特定のカードブランド/国/決済手段に偏っていないか
- 回収（リトライ）や通知が機能しているか
支払い失敗の増加が確認できたら、まずは「どの層の失敗が増えたか」を切ります。広い変更より、局所の復旧が早いです。
4. 解約は「いつ」「どの層」で増えたかだけ先に切る
解約増は、原因究明に時間がかかります。最初の30分でやるのは“層を切る”だけです。
- プラン別（どの価格帯が崩れたか）
- 期間別（新規直後 vs 継続利用後）
- 入口別（Search/紹介/広告/直契約）
「全体の解約が増えた」と見えるときでも、だいたい局所から崩れます。
5. 新規が減ったなら、入口→料金ページ→申込の順で見る
新規の減少は、入口（Search/LP）と、料金ページの詰まりで起きることが多いです。
- Search Consoleの表示回数/クリックが落ちていないか
- GA4で入口ページが落ちていないか
- 料金ページで詰まっていないか（比較できない/不安が残る/次の一歩がない）
関連: /media/pricing-page-conversion-first-fixes
6. 30分後に「次の1時間でやること」を1つだけ決める
切り分けができたら、次の1時間は“手数を増やさない”のがコツです。
- 支払い失敗が原因 → 回収漏れの層を絞って復旧（通知/リトライ/連絡の確認）
- 解約が原因 → 崩れた層のヒアリング/ログ確認に集中（全体改修しない）
- 新規が原因 → 入口の急落を止血（主要LPの改善/タイトル調整/障害切り分け）
毎朝10分で「Search / Access / Revenue」をつなげて見る運用に落とすなら、こちらの手順が早いです。
関連: /media/daily-revenue-signal-triage
SiteOpsで初動を速くする（再発防止）
MRR急落は原因が複合しやすいので、「異常（何が起きたか）」と「変更（何を変えたか）」を同じ視点で確認できると初動が速くなります。
- まずは ダッシュボード で、売上/決済/解約のどれが崩れたかを切ります
- 相談したい場合は お問い合わせ から状況を送ってください（止血の順番を一緒に整理できます）
- 料金と導入の流れは 料金ページ にまとめています
この記事を書いた人
川原
SiteOps編集チームの公開窓口として、検索、アクセス、収益データをもとにした運営判断の知見をまとめています。
関連記事
次にやること
複数サイトの検索、アクセス、収益データをまとめて見直すなら、SiteOpsのダッシュボードでサイト別に確認できます。
料金を見る相談したい / お問い合わせ