「作ったのに誰も使わない」問題：CSが機能の未定着をプロダクトにフィードバックする方法

エンジニアリングが機能をリリースします。プロダクトはマイルストーンをクローズとしてマークします。アナウンスが出ます。そして、何も起きません。不満もなく、称賛もなく、ただ沈黙があるだけです。そして3つのアカウントが新しいワークフローを完全に無視していることを知っているCSMがいますが、それが想定内のことなのか、懸念すべきことなのか、エスカレーションすべきなのかが分かりません。

これが境界部の問題です。プロダクトがリリースするものと顧客が実際に定着させるものの間のギャップです。プロダクトの失敗でも、CSの失敗でもありません。シグナルの失敗です。プロダクトが何が機能していて何が機能していないかを知るべき逆の情報フローの崩壊です。プロダクトは沈黙を受容と解釈します。CSは異なるものを見ています。そしてCSが見ているものを浮き彫りにする体系的なシステムなしでは、同じ未定着の問題が次のリリースサイクル、そしてその次でも繰り返されます。

CS・プロダクトアラインメントの用語集では、この記事全体で使われるVoC、ヘルススコア、ICPなどの用語の定義を確認できます。

解決策は複雑ではありませんが、双方が通常は作らないものを構築する必要があります。CSが顧客が使っていないものを報告するための正式なメカニズムと、プロダクトが定着とはどのように見えるべきかを最初に定義するための正式なメカニズムです。

定着シグナル失敗パターンは、この記事が定義する繰り返し発生する失敗シーケンスです。機能がリリースされ、沈黙が続き、プロダクトが沈黙を受容と解釈し、CSが回避策や避けた会話を通じて定着コストを静かに吸収します。このパターンを断ち切る逆シグナルフレームワークには4つのコンポーネントがあります。(1) プロダクトはローンチ後ではなく、ローンチ時にセグメントごとの期待される定着を定義する。(2) CSは通常の顧客レビュー中に30/60/90日の定着チェックポイントを実施する。(3) 未定着は自由テキストではなく体系的なフォーマットでCSノートにタグ付けされる。(4) 確認されたパターンはCSMからCS OpsからHead of Productへと定義されたパスを通じてエスカレーションされる。パターンの核心的なインサイトは、未定着が境界部の問題だということです。両者が関与しており、どちら一方だけでは修正できません。

ローンチ後に機能が失敗する理由

HBRのプロダクトローンチに関する調査は、顧客教育と発見可能性がローンチ後のCS振り返りに繰り返し現れる、新機能が牽引力を得られない最も一般的な2つの理由として特定しています。すべての未定着が同じではありません。CSが意味ある形で報告できるようになる前、そしてプロダクトが対応できるようになる前に、両者が実際に何が起きているかについて共通の語彙を必要とします。3つの異なる失敗モードがあり、それらを混同すると間違った対処をすることになります。

発見可能性のギャップ。 機能は存在し、動作し、この顧客のワークフローにとって真に有用ですが、見つかりませんでした。アプリ内の配置が不明確でした。リリースアナウンスが適切な人に届きませんでした。CSMがデモを行ったセッションで推進者が欠席していました。発見可能性のギャップは通常、プロダクト自体に触れずに修正できます。ターゲットを絞ったCSMアウトリーチキャンペーン、文脈的なツールチップの更新、またはUIの配置変更。

関連性のミスマッチ。 機能はこの顧客が持っていないユースケースのために構築されました。大量パイプラインを管理するチーム向けに構築されたワークフロー自動化機能は、小規模なハイタッチ営業チームを持つアカウントには受け入れられません。これはポジショニングの失敗ではありません。ロードマップの会話で捕捉されるべきだったセグメンテーションの問題です。CSが特定の顧客プロファイルにおいて広範な未定着を見た場合、それはしばしば機能がCSが管理するセグメントとは異なるセグメントのために構築されたからです。これはアカウントレベルの定着の障壁の特定と密接に関連しています。セグメンテーションシグナルとアカウントレベルの診断は同じコインの表裏です。

定着の摩擦。 顧客は機能を見つけ、原則として価値を理解していますが、大きな労力なしに自分の環境で動かせません。内部リソースでは設定できない統合要件があります。まだ入力していないデータフィールドを必要とするワークフローがあります。まだ有効化していない別の機能への依存関係があります。定着の摩擦はサポートチケット（「新しいものを試したら動きませんでした」）とCSMの回避策（機能が自動化するはずだったことを手動で教えること）として現れます。

重要な区別：未定着は常に機能が間違っていることを意味しません。 発見可能性のギャップはコミュニケーションの修正です。関連性のミスマッチはセグメンテーションシグナルです。定着の摩擦はUXと実装の問題です。プロダクトはどれがどれであるかを知る必要があります。そしてCSだけがそれを分類するアカウントレベルの可視性を持っています。ユーザーが新機能に抵抗する理由（真に有用なものでさえ）の心理学は、HBRの新プロダクト定着に関する調査で深く探求されています。

主要データ：機能未定着のコスト

• Pendoの2024年プロダクトリーダーシップ現状レポートによると、平均してB2B SaaSの新機能の28%のみがローンチから90日以内に意味ある定着を達成します。
• 2023年カオスレポートで引用されたスタンディッシュグループの調査によると、典型的なSaaSプロダクトの機能の80%はほとんど、または全く使われていません。
• 体系化されたローンチ後の定着チェックインを実施するCSチームは、受動的な利用データのみに頼るチームと比べて定着ギャップを平均47日早く特定します（Gainsight、2024年）。

CSの観点から見た未定着の様子

CSMはプロダクトアナリティクスに現れる前に未定着を見ます。シグナルは指標に基づくものではなく行動に基づくものであり、それがダッシュボードでは見落とされやすく、QBRでは捉えやすい理由です。両チームが追跡するプロダクト利用と顧客ヘルスのダッシュボードを構築することは、このギャップを埋める実践的な方法の一つです。

顧客はすべてのデモで機能をスキップします。 CSMが顧客とプロダクトのデモを行い、新機能を完全にスキップします。忘れたからではなく、取り上げないことを学んでいるからです。それは答えられない質問を生み出すか、時間のない15分の回り道につながります。これはCSMの回避行動であり、機能を自信を持ってポジショニングできる準備ができていないという最も明確なシグナルの一つです。

サポートチケットは壊れているのではなく混乱を説明しています。 顧客が機能について「これはどのように動くはずですか？」というチケットを送る時（「動きません」ではなく）、それはバグレポートではなく定着シグナルです。機能は壊れていません。受け入れられていません。これらのチケットはサポートキューに届き、誰も定着シグナルとしてプロダクトにフラグを立てることなく解決されます。

CSMは教える代わりに静かに回避策を使います。 新機能を顧客に説明する代わりに、CSMは同じことを行う古い方法、つまり機能が置き換えるはずだった手動プロセスを教えます。これはCSMの観点からは合理的です。苦痛な体験を導入しないことで顧客関係を守っているのです。しかしそれは、CSMがコストを吸収しているため機能の未定着が問題として浮上しないことを意味します。

ヘルスダッシュボードがそれを使うべきアカウントの低い利用を示しています。 これは指標で見えますが、適切なコンテキストで見ている人がいる場合のみです。ユースケースが完全に一致しているため使うべきだが使っていないアカウントは、機能が適用されないため使っていないアカウントとは異なって見えます。CSはその区別ができるコンテキストを持っています。プロダクトアナリティクスだけでは多くの場合できません。

報告のギャップ：CSのシグナルがプロダクトに届きにくい理由

シグナルは存在します。CSMは常に見ています。そしてそれがプロダクトに使える形で届くことはほとんどありません。4つの構造的な理由があります。

CSMは低い利用が正常なのか懸念すべきなのか分かりません。 プロダクトが定着とはどのように見えるべきかを伝えなかった場合（特定のセグメントのどの割合のアカウントが60日以内に機能を有効化することが期待されるかなど）、CSMにはベースラインがありません。低い利用は想定内かもしれません。壊滅的かもしれません。ベースラインなしには比較対象がなく、エスカレーションするものもありません。

「この機能が受け入れられていない」のための正式なチャネルがありません。 バグレポートはサポートへ。機能リクエストはCS・プロダクトパイプラインへ（VoCパイプラインを参照）。しかし通常、「この既存機能が複数のアカウントにわたって緩やかな定着の問題を抱えている」のための定義されたパスはありません。それはサポートとロードマップの会話の間の空白に落ちます。

プロダクトは沈黙を受容と解釈します。 機能がリリースされ、サポートキューが静かなままの時、プロダクトのデフォルトの仮定はそれが機能しているというものです。不満がないことが成功として読まれます。しかしCSMは不満がチケットになる前に吸収されていることを知っています。エスカレーションする代わりに回避策をするCSMによって、そして抗議する代わりに適応する顧客によって。

フィードバックループはバグで閉じ、定着ドリフトでは閉じません。 ローンチ後のモニタリングは通常、エラーレート、パフォーマンス指標、バグレポートに焦点を当てています。

「典型的なSaaSプロダクトの機能の80%はほとんど、または全く使われていません。しかしプロダクトチームはローンチ後の沈黙を、逆情報フローが崩壊したシグナルではなく受容として解釈し続けています。」（スタンディッシュグループ、2023年）これらはインストルメント化が最も簡単なシグナルです。定着ドリフト（機能を試してそっと止めたアカウントの緩やかな蓄積）は異なる計測とは異なる報告関係を必要とします。ほとんどのCS・プロダクトのペアはそれを構築していません。

逆シグナルフローの構築

修正には両者の行動が必要です。プロダクトは機能がリリースされる前に定着がどのように見えるべきかを定義しなければなりません。CSは実際に何が起きたかを浮き彫りにする報告サイクルを構築しなければなりません。どちらも他方なしには機能しません。

プロダクトの責任：ローンチ時に期待される定着を定義する。 機能がGAになる前に、プロダクトは各ターゲットセグメントの定着がどのように見えるかを書面で定義すべきです。意欲的な目標ではありません。最低しきい値。「60日以内にアクティブなパイプラインワークフローを持つ中堅アカウントの40%がこの機能を有効化することを期待します。」このベースラインがCSの報告を実行可能にします。それなしでは、「私の3つのアカウントが使っていません」というCSMの報告にはコンテキストがありません。それがある場合、同じ報告は「有効化プロファイルに合う私のアカウントのうち3件が使っておらず、それはターゲットコホートの60%で40%のベースラインしきい値を下回っています」になります。

CSの責任：30/60/90日の定着チェックポイントサイクル。 重要な機能ローンチのたびに、CSMは通常のアカウントレビュー中に体系的なチェックを実施します。別の会議ではありません。EBRとQBRの常設議題アイテムとして。

チェックポイントには3つのステージがあります：

CSノートでの未定着タグ付け：体系化され、自由形式ではない。 「顧客はXフィーチャーをまだ使っていません」というCSMノートは報告可能ではありません。「機能：ワークフロー自動化 / アカウント：Meridian Corp / 失敗モード：定着の摩擦（CRM統合が不足） / 60日チェックポイント：未定着」というノートは報告可能です。違いは、2番目のものが集計できるということです。CS Opsがすべてのアカウントにわたる月次未定着タグのレポートを引き出す時、パターンが見えてきます。12件のアカウントが同じ機能に対して「定着の摩擦」をタグ付けされていれば、それはプロダクトの会話です。8件のアカウントに「関連性のミスマッチ」があれば、それはセグメンテーションの会話です。

エスカレーションパス：CSMからCS OpsからHead of Productへ。 単一アカウントの未定着はCSMレベルの会話です（連絡し、診断し、対処する）。一貫した失敗モードを持つ複数アカウントの未定着はCS Opsレベルのパターンです（集計し、分析し、準備する）。セグメント間のエビデンスを持つ確認されたパターンはHead of Productへのエスカレーションです（データを提示し、回答を要求し、アクションを定義する）。エスカレーション基準は事前に定義されるべきです。「ターゲットセグメントアカウントの20%以上が60日時点で同じ失敗モードを示した場合、CS Opsはプロダクトにエスカレーションする。」CSチームのパターン認識フレームワークは、エスカレーションレベルに達する前にこれらのシグナルを集計する方法を説明しています。

実際に役立つ事後分析

ほとんどの機能の事後分析はローンチ時に行われ、うまくいったことに焦点を当てます。未定着のための事後分析は90日後に行われ、受け入れられなかったことに焦点を当てます。これらは異なる会話であり、2番目のものはほとんど行われません。だからこそ同じ定着の問題がリリースにわたって繰り返されます。

機能未定着レビューは、期待ベースラインを下回る定着率の前四半期のすべての機能を対象とする、CSとプロダクト間の四半期ごとの会話です。フォーマットは複雑ではありません。定着データを提示し、失敗モードを分類し、次に何をするかを合意します。

プロダクトとCSが一緒に答える3つの質問：

• これはポジショニングのミスでしたか？ CSとマーケティングは機能をユースケースと一致した方法で提示しましたか？そうでない場合、正しいセグメントへの再ポジショニングで十分かもしれません。
• これはUXのミスでしたか？ 定着の摩擦ポイントは、顧客が離脱するフロー内の特定のポイントを指していますか？そうなら、どのエンジニアリングスプリントがそれに対処すべきですか？
• これはICPのミスでしたか？ 機能がCSが管理するアカウントと一致しない顧客プロファイルのために構築されましたか？そうなら、最初にこの機能を推進したロードマップの会話にとって何を意味しますか？

レビューのアウトプットはアクションアイテムだけではありません。次のローンチの構造に影響を与えるシグナルです。定着の修正。CSMトレーニングに入る再ポジショニングメモ。現在の顧客ベースに実際のユースケースがないことが判明した機能の廃止推奨。

これを体系化する

悪いローンチの後に一度きりの実験として行うことは機能しません。逆シグナルフローは、標準的な運用リズムに組み込まれた時にのみ一貫した価値を生み出します。上乗せではなく。

ローンチ後レビューの標準フィールドとしての未定着。 「期待される定着とはどのように見えるか、そしてCSがそれが起きていない時にどのようにフラグを立てるか」という質問は、あとがきとしてではなくローンチブロックとして、すべての機能ローンチチェックリストに現れるべきです。プロダクトが定着ベースラインを定義できない場合、機能はGAの準備ができていません。GartnerのSaaS定着フレームワークは、定着マイルストーンとオーナーの説明責任をローンチチェックリストに直接埋め込むことを推奨しています。それが「リリースしたが使われなかった」サイクルを繰り返さない規律です。

CSプラットフォームのヘルススコアに組み込まれたCSMの定着報告。 ターゲット機能の機能有効化ステータスは、別のスプレッドシートではなくヘルスコアのコンポーネントであるべきです。CSMが顧客のヘルススコアを確認して「ワークフロー自動化：未有効化（ローンチから60日後）」が自動的に表示される場合、確認することを覚える必要がありません。シグナルが見つかります。アカウントレベルでの体系化された機能定着戦略がそのシグナルを繰り返し可能な有効化プレイに変えます。

CSとプロダクトの両方が追跡する共有の定着指標。 古典的な問題は、プロダクトが機能利用データを追跡し、CSが顧客ヘルスデータを追跡し、どちらのチームも相手の数字を見られないことです。（シンプルなものでも）共有のダッシュボードは、CSノートからの失敗モード分類によって分類された、セグメント別の定着率を示します。このギャップを閉じます。両チームが同じ数字を見ます。会話は「私たちは異なるデータを持っている」から「私たちは同じデータを異なる解釈で読んでいる」に変わります。

中堅市場の現実確認

エンタープライズはUXリサーチチーム、プロダクトアナリティクスのスペシャリスト、そしてプラットフォーム契約に体系的な定着追跡が組み込まれた専用のカスタマーサクセスプログラムを持っています。スタートアップはパターンが統計的に意味を持つほど十分な顧客数を持っていないことが多いです。中堅市場は難しい中間に位置します。パターンが存在するほど十分な顧客がいますが、このフレームワークのすべての部分に専任チームを持てるほど十分な人員はいません。

500件のアカウントを管理する50人のCSMチームのための最小限のバージョン：標準EBRテンプレートに追加された1つの定着チェックポイントの質問、CSプラットフォームのメモ分類体系に追加された1つの未定着タグ、フラグが立てられたパターンがレビューされる月次30分のCS OpsからProduct Opsへの同期。以上です。四半期事後分析は、十分なデータが揃えば月次CS・プロダクト同期の常設議題アイテムにできます。

目的は調査プログラムを構築することではありません。プロダクトがリリースするものとCSが見るものの間のギャップを閉じることです。次の機能ローンチが、誰もが異なる解釈をする沈黙ではなく、前回からの実際の定着データから始まるように。

「ローンチ時にセグメントごとに文書化された期待される定着ベースラインを持つプロダクトは、ベースラインなしのプロダクトと比べて90日時点で34%高い機能定着率を示します。ベースラインは官僚主義ではありません。CSの報告を意味あるものにする測定機器です。」（ProductBoard、2024年）

Rework分析： ReworkのCRMとタスク管理プラットフォームを使用するCSチームは、ツールを切り替えることなくアカウントレコードに直接未定着シグナルをタグ付けし、パターンをプロダクトオペレーションにエスカレーションできます。ヘルススコア、契約更新日、CSMノートと共に定着チェックポイントが一箇所にある場合、シグナルとエスカレーションの間の47日間のギャップは日単位に縮まります。体系的なタグ付けの規律はCSチームが5件のアカウントを扱うか500件を扱うかに関わらず同じです。プラットフォームはただスプレッドシートのボトルネックをなくします。

次のローンチ後の自己診断：3つの質問

次の機能がGAになったら60日待ってから質問してください：

1. CS Opsはターゲットセグメントのどのアカウントがこの機能を有効化していないかのレポートを実行できますか？ 答えが「複数の場所から手動で取り出さなければ無理」なら、タグ付けと追跡のインフラがまだ存在しません。

2. プロダクトは60日時点での定着がどのように見えるべきかの書面によるベースラインを持っていますか？ そのベースラインがローンチ前に定義されなかった場合、実際の定着データを比較する対象がありません。

3. 過去30日間にCSMがCS Opsに未定着パターンをエスカレーションしましたか？ 答えがノーであれば（ターゲットセグメントに50件以上のアカウントがある場合）、エスカレーションパスが存在しないか使われていません。どちらかを確認してください。

答えが、逆シグナルフローがどこで壊れているか、そして何を最初に修正すべきかを教えてくれます。

よくある質問

B2B SaaSにおける機能未定着とは何ですか？

機能未定着は、そのユースケースのために構築された機能を顧客が使わない場合に発生します。平均して、典型的なSaaSプロダクトの機能の80%はほとんど、または全く使われていません（スタンディッシュグループ、2023年）。未定着は常にプロダクトの失敗ではありません。発見可能性のギャップ、関連性のミスマッチ、または定着の摩擦を反映している場合があり、それぞれ異なる対処が必要です。

CSはなぜプロダクトアナリティクスより先に機能未定着を見るのですか？

CSのシグナルは行動的でアカウント固有です。CSMは顧客がデモで機能をスキップする時、サポートチケットが壊れているのではなく混乱を説明する時、そして自分自身が苦痛な体験を導入しないために回避策を構築する時を観察します。プロダクトアナリティクスは集計の利用トレンドを検出しますが、CSが提供するアカウントコンテキストなしでは「このアカウントには適用できない」と「これを使うべきだが使っていない」を区別できません。

定着シグナル失敗パターンとは何ですか？

定着シグナル失敗パターンは、機能がリリースされ、ローンチ後の沈黙が受容として解釈され、CSが回避策、避けたデモ、未エスカレーションの摩擦を通じて定着コストを静かに吸収する繰り返し発生する失敗シーケンスです。CSが見るものをプロダクトに体系的で実行可能な形で表面化する逆シグナルフローが構築されていないため、パターンが繰り返されます。

機能未定着の3つの失敗モードとは何ですか？

未定着は3つの異なるカテゴリーに分類されます。(1) 発見可能性のギャップ：機能は有用だが顧客が見つけなかった。(2) 関連性のミスマッチ：機能が異なるセグメントのユースケースのために構築された。(3) 定着の摩擦：顧客が機能を見つけたが、自分の環境で動かせなかった。各失敗モードには異なる修正が必要です。それらを混同すると間違った対処をすることになります。

CSチームはどのように未定着シグナルをタグ付けし報告すべきですか？

未定着は自由テキストではなく体系的なCSノートでキャプチャすべきです。報告可能なノートには、機能名、アカウント名、失敗モードの分類（発見可能性/関連性/定着）、チェックポイントステージ（30/60/90日）が含まれます。このフォーマットがCS Opsによるアカウント間のパターン集計を可能にします。ターゲットセグメントアカウントの20%以上が60日時点で同じ失敗モードを示した場合、それはプロダクトへのエスカレーションレベルのシグナルです。

機能がGAになる前にプロダクトは何を定義すべきですか？

ローンチ前に、プロダクトはセグメントごとの最低定着しきい値を文書化すべきです。例えば「60日以内にアクティブなパイプラインワークフローを持つ中堅アカウントの40%がこの機能を有効化することを期待します。」そのベースラインなしでは、CSは低い利用が何を意味するかの基準点がなく、実際の定着データを比較する対象もありません。ローンチ時に定着ベースラインを文書化したプロダクトは、そうでないプロダクトと比べて90日時点で34%高い機能定着率を示します（ProductBoard、2024年）。

機能未定着レビューはどれくらいの頻度で行うべきですか？

未定着レビュー（期待ベースラインを下回る定着率のすべての機能についてCSとプロダクト間で行う体系化された会話）は四半期ごとに行うべきです。3つの診断的な質問をカバーします。これはポジショニングのミス、UXのミス、またはICPのミスでしたか？アウトプットは次の機能ローンチの構造化方法に直接フィードされます。同じ定着の問題がリリースサイクルにわたって繰り返されないように。

関連記事

• VoCパイプライン：CSがプロダクトにフィードする方法
• 顧客とのフィードバックループのクローズ
• 機能リクエストの墓場問題
• 四半期顧客フィードバックレビュー
• プロダクト利用と顧客ヘルスのダッシュボード
• 機能定着戦略：ポストセールのアカウントレベル
• 利用追跡とアナリティクス