ENTRY TYPE · framework

カスタマー成熟度モデル

By Marius Bughiu Last updated 2026-06-06 Customer Success

カスタマー成熟度モデルとは、アカウントが製品をどれだけ深く使っているかをステージごとに示すマップ（典型的には crawl、walk、run）であり、CS チームが各カスタマーの正しい次のアクションを定め、拡大のタイミングを計るために使います。これは health score ではなく（health は今この瞬間のリスクを示し、成熟度はアカウントが完全な価値に向けてどこまで進んだかを示します）、customer journey と同じものでもありません（journey はライフサイクルの瞬間の連なりであり、成熟度はその中での採用の深さです）。このモデルは、book にあるすべてのアカウントについて 1 つの問いに答えるために存在します。このカスタマーが次にすべき、最もインパクトの大きい 1 つのことは何か。

crawl / walk / run フレームワーク

各ステージは、観察可能な製品の挙動と、カスタマーが到達した outcome で定義します。カスタマーである期間の長さではありません。時間は弱い proxy です。1 つの feature で止まっている 6 か月のアカウントは、中核の workflow を毎日使う 6 週間のアカウントより成熟していません。

crawl — オンボード済みで稼働中。 カスタマーは setup を完了し、主要な admin がログインし、少なくとも 1 つの中核 workflow が成功して動いています。採用の幅は 1〜2 個の feature で、使用は浅く admin 主導です。ここでの CS の仕事は time-to-first-value です。feature の幅ではなく、アカウントを最初の本物の outcome へ導きます。
walk — 1 チームで採用済み。 中核の workflow が 1 つのチームまたはユースケースで習慣化しています。週次のアクティブ使用は安定し、2 つ目の feature が動き、カスタマーは自分の言葉で価値を説明できます。CS の仕事は、champion の交代を生き延びるよう outcome を深め文書化し、次のチームを見つけることです。
run — 組み込まれ拡大中。 複数のチームまたはユースケースが製品に依存し、使用はロールをまたいで日次で、アカウントはそれをインフラとして扱います。CS の仕事は採用から拡大とアドボカシーへ反転します。新しい seat、新しいモジュール、複数年の更新、リファレンスです。

ステージゲートのキャリブレーション

汎用的なステージは埋め草です。各ゲートを、product analytics（Pendo、Amplitude）や CS プラットフォーム（Gainsight、Vitally、Planhat）から取得できる 2〜3 個の測定可能な閾値でキャリブレーションします。コラボレーションツールの具体例です。

ステージ	幅（採用した feature）	深さ（WAU / ライセンス seat）	到達した outcome
crawl	6 個の中核 feature のうち 1〜2	20% 未満	最初のプロジェクトを出荷
walk	6 個のうち 3〜4	20〜50%	1 チームが週次で使用
run	6 個のうち 5〜6	50% 超	2 チーム以上、彼らのプロセス文書に記載

閾値は自社のデータから選びます。最も retention が良く NRR が高い cohort を取り、拡大する前にどの幅と深さに達していたかを見て、run ゲートをそのすぐ下に設定します。ゲートは製品固有です。他社の数字をコピーすると目的を損ないます。

成熟度を使って拡大を推進する

成熟度は play のためのルーティングルールであり、見栄えのダッシュボードではありません。各ステージを、アカウントを前進させる唯一の play にマップします。

crawl のアカウントには採用 play を与え、決して upsell しません。 first value に到達していないアカウントに seat を売ることは、churn を製造する方法です。まだ使っていないものを多く買い、その後どちらの更新も失敗します。Guard: 拡大の motion は、walk ゲート未満のどのアカウントでも無効にします。
walk のアカウントには、深め 2 つ目のチームを獲得する play を与えます。 ここで拡大の pipeline が作られます。クローズされるのではありません。2 つ目のチームを加える walk アカウントは、自ら run へ昇格しています。
run のアカウントには拡大 play を与えます。 マルチチームの依存に加えて 50% 超の深さは、持っている中で最も強い拡大シグナルです。これは在籍期間や契約額よりはるかに良く NRR と相関します。upsell の会話のタイミングは、更新カレンダーではなく、アカウントが run ゲートを越えた瞬間に合わせます。

複利の便益として、成熟度は RevOps に予測可能な拡大 pipeline を与えます。今四半期に walk ゲートにいるアカウント数は、来四半期に拡大対象となるアカウントの先行指標です。

よくある落とし穴

成熟度と health の混同。 run ステージのアカウントが不健全なこともあり（champion が辞めたばかり）、crawl のアカウントが完全に健全なこともあります（順調で、ただ早期なだけ）。Guard: 両方をトラックし、高い成熟度ステージが churn リスクのアラートを抑制しないようにします。
時間ベースのステージ。 「90 日 = walk」は成熟度モデルではありません。カレンダーです。Guard: 各ゲートは製品の閾値か outcome で定義し、経過時間だけでは定義しません。
降格のないゲート。 アカウントは後退します。組織再編で champion が消え、使用が落ちます。Guard: ステージを health と同じ頻度で再計算し（週次が典型）、walk の深さ閾値を下回ったアカウントが戻って採用 play に再び入るようにします。
crawl アカウントへの upsell。 上で扱いました。このモデルが防ぐよう設計された、最もコストの高い誤りです。

フレームワークが崩れるとき

3 つのステージは、採用の表面積が広い製品には粗すぎ（20 個のモジュールを持つプラットフォームは run の中にサブステージが必要）、「稼働中」が唯一の意味あるステートであるトランザクション型や単一 feature の製品には細かすぎます。ステージの数は crawl/walk/run の慣習ではなく、自社の採用の表面積に合わせてキャリブレーションします。使用量ベースの pricing では、成熟度と revenue が自動的に一緒に動くため、拡大 play は営業の motion というより、より深い使用の摩擦を取り除くことに重きが移ります。