カスタマーサクセスの立ち上げというと、ローンチ後、プロダクト成長に合わせて行われるケースやローンチと同時というイメージが強いのではないでしょうか。
私が携わったカスタマーサクセス事例ではプロダクトローンチのスケジュール変更もあり、ローンチ前からのCS立ち上げ準備をすることになりました。
その事例を通して見えたプロダクトローンチ前に考えておきたいカスタマーサクセス立ち上げのポイントについて解説します。
今後プロダクトローンチを計画・予定している方のお役にたつ情報になれば幸いです。
PMF（プロダクトマーケティングフィット）を目指したヒアリング準備
ローンチ後、最初にCSが目指すことはPMFです。
PMFを達成するためにはプロダクト提供過程にてヒアリングを実施し、収集した顧客フィードバックをもとに開発側へ最適なプロダクトフィードバックを行う必要があります。
ローンチ直後から質の高いヒアリングを行い、プロダクトに対する適切なフィードバックを開発に行うため以下のポイントをプロダクトローンチ前から考えて置く必要があると考えています。
①プロダクト理解を高める
ローンチ前にはプロダクト理解を高めることが重要だと考えています。
プロダクト理解とは具体的に「プロダクトの仕様」「プロダクトの提供価値」を理解することです。
「プロダクトの仕様」
顧客から最適なフィードバックの収集を行うためにはプロダクトを正しく利用してもらえるようなサポートが必要です。
顧客からフィードバックを収集するうえで、顧客がプロダクトを正しく利用していないことには適切なプロダクトフィードバックを収集することはできません。
プロダクトによっては顧客ごとに導入目的が変わり使用する機能と使い方、各種設定等が変わってきます。
そういった状況で顧客ごとに最適な使い方でプロダクトを利用してもらえるよう、サポートを行うためにはプロダクトの仕様を理解する必要があります。
またローンチ直後はその時点では備わっていない顧客からの機能要望が多々でてきます。
その中で案件によっては契約の獲得、継続利用をしてもらうためにその時点で備わっている機能を用いて、できるだけ顧客要望に近い形を実現できる代案を考えなければいけないケースがあります。そのような状況になった場合、プロダクトの仕様を細かく理解していると要望により近い形での代案を検討することができます。
私の場合、「プロダクト仕様」を把握するために
-
- とにかく隅から隅まで操作する
- 顧客が実際に使った際に起こりうることをイメージしてシステムを操作する
- 「今顧客が行っている業務フロー」を可能な限りそのまま実践する
ことを意識して行動していました。
特に「今顧客が行っている業務フロー」をそのまま実践してみたことはよかったです。
この作業によってイメージしているときでは気づかなかった今の業務でミスが発生しやすい場所や面倒なことがより細部まで見えてくるため主要なプロダクト仕様や応用的な使用方法を把握することができました。
「プロダクトの提供価値」
リリース直後は「今の仕様で修正してほしいこと」や「この機能があったら便利」など様々な要望、意見がでてきます。
その中で収集したフィードバック全てを開発に反映させることはスタートアップの開発リソース上厳しい上に全ての要望が市場のニーズにマッチした要望とは限らないです。
そのため、収集したフィードバックの要不要と優先度を精査する必要があります。
その際、プロダクトの提供価値（顧客のどのようなペインに対してどのような成果を提供するプロダクトか）を把握しプロダクトの提供価値を軸に判断する必要があります。
なぜならプロダクトの提供価値が何かによって機能の要不要と優先度が変わってくるからです。
ローンチ前から完璧に把握することは難しいですが、大まかに把握するだけでも、顧客から収集するべきことは何か、顧客からの各機能要望に対して本当に必要な機能とは何か等を適切に判断できるため、PMFに向けてより適切なプロダクトフィードバックを行うことができます。
②業務理解を高める
顧客の業務手順上どんな操作仕様になっていると使いやすいか、どんな画面構成だと良いか
など、顧客が必要とするシステムとはどんなシステムなのかをヒアリングし、把握するためには業務の手順、毎月発生する定常業務、業界特有のプロセス、顧客ごとに変わるインプットとアウトプットは何かなど顧客の業務に関して深く理解する必要があります。
またPMFを目指すうえでプロダクト継続利用の鍵となる顧客の作業は何か、継続利用の鍵となる顧客の作業に向けて必要なオンボーディングフローはどうすべきかなどを考えるうえで顧客の業務に関して深く理解する必要があります。
私の場合「業務理解を高めるため」に
を心がけていました。
顧客に直接聞いたほうが自分で調べて学ぶよりも解像度が上がります。
その為、プロダクトローンチ前は可能な限り営業に同行して気になることを顧客に直接聞いていました。
また業務フローを資料に可視化することで頭の中で漠然と捉えていた業務理解の解像度があがり、自社のプロダクトを通して具体的な業務レベルでどんな価値提供が可能かを把握することができます。
③顧客へのヒアリング項目を整理しておく
顧客へのヒアリング時に「フィードバック内容の背景まで聞く」こと「多方面の関係者に聞く」ことを念頭に置いてヒアリング項目を整理することが重要だと考えています。
「フィードバック内容の背景まで聞く」とは
例えばある機能要望を頂いた場合
-
- どういう業務で要望機能が必要になるのか
- 日常的に支障が出るくらい業務頻度は高いのか
- 現在は対象業務に対してどのような方法、手順を行っていてその際どこに不満を感じているのか
などを確認し要望だけを聞いて終わりにしないことです。
顧客の声をそのまま開発に伝えると本質的に顧客が解決したいことに対する解決策ではないケースがあります。
要望の背景、今の業務フローを確認してみると機能追加を行うよりも今の作業や管理項目を見直したほうが顧客にとってメリットがあるケースやマーケット需要、自社のターゲット、機能実装にかかる社内リソースを考えたときに機能追加を行わず特定業務に優れた別システムを並行して使う方が良いケースがあります。
また機能追加を検討する場合、適切な仕様を決めるためには要望機能を利用する業務時に発生する様々な処理のパターンを把握する必要があります。
その為、顧客から頂く声の背景まで深ぼって聞くことが重要だと考えます。
「多方面の関係者に聞く」とは
会社上層部、現場の方などそれぞれの関係者の意見を聞くことです。
-
- 上層部では〇〇のデータを出力したいため、現場には工数が多少増えるが出力に必要な〇〇を管理してもらう予定
- まずは現場の作業工数削減を優先して上層部が必要な帳票出力は後回しにする
などトップダウンの会社、現場の意向を優先する会社など様々な組織体制の会社があります。
この多方面へのヒアリングによって業界特有の市場ニーズをつかめるケースがあります。
その為、特定の立ち位置の方からのみヒアリングを行うのではなく、自社のプロダクトに関連する人物を特定し、多方面の方からヒアリングを行う必要があります。
上記2点を押さえたヒアリング準備をローンチ前から把握しておくと、ローンチ直後からPMFに向けた適切なプロダクトフィードバックを行うことができます。
テクニカルサポートを想定したデバッグを行う
ローンチ後、様々なバグが発生し多くの「バグによるUXの低下」が発生します
バグ対応をスムーズに進めるため、ローンチ前にデバッグ業務を行うことを推奨します。
推奨理由は以下になります
-
- 事前にバグに対する対応策を用意することができる
- 一部のバグを顧客よりも先に見つけられるようになる
事前にバグに対する対応策を用意することができる
ローンチ前に発生しているもしくはローンチ後発生する可能性のあるバグを把握していないとスムーズな顧客対応ができません。自分が携わっていた事例では修正したはずのバグがローンチ後何度も発生するといったことがありました。
発生する可能性のあるバグを把握しておくことで事前に対応策を用意でき、バグに関する問い合わせ対応、操作レクチャー時のバグが起きた際の対応をスムーズに行うことできます。
一部のバグを顧客よりも先に見つけられるようになる
顧客の多くはバグを見つけるとバグの報告をせずに自然とシステムを利用しなくなります。
そのような事態をできるだけ防ぐために大事なことは可能な限り先にカスタマーサクセスでバグを察知することです。
デバッグ業務を通してどんな場所でバグが起きるかを把握すると、他に「〇〇の部分でもバグが起きるのではないか」となんとなくあたりがつくようになります。
それによってバグを事前に察知することができ、解約阻止に向けた動きを先回りして各顧客に行うことができます。
実際に顧客からバグの問い合わせを頂いた際に、「〇〇でバグが起きているのであれば〇〇の部分でもバグが起きているのではないか」と他のバグ部分を事前に見つけることができました。
内部チームでの情報共有方法を決めておく
営業⇔CS、CS⇔開発での情報共有方法を事前に決めておくことを推奨します。
ローンチ直後は顧客から様々な要望、質問がでてきます。
その中で適切にプロダクトフィードバックを回すためには活発に部署をまたいだコミュニケーションが発生します。
その情報共有の際、各情報の共有方法をある程度決めておかないと情報が乱立してしまいます。
実際に自分が携わっていた事例では各情報の共有方法が定まっておらず、様々な場所に情報が乱立していたり、各部署で必要な情報が明確化されていませんでした。そのため、特定の情報を抽出することに時間がかかってしまったり、判断に必要な情報が収集できていなかったことに後から気づくといった状況が起きていました。
そのため、各部署とどんな情報をどのように共有するかを事前に決めておくことを推奨します
まとめ
実体験からCS立ち上げに関わる人材にはプロダクトマネージャーの目線が必要だと感じました
-
- プロダクト提供価値の把握、特定
- 市場ニーズのリサーチ
- 必要機能優先順位の明確化
- 部署をまたいだコミュニケーション
などCS立ち上げ時に発生する業務は様々であり上記はプロダクトマネージャーに求められる業務かと思います。
そのため早期のPMF達成に向けてプロダクトマネージャーの目線を持ちながらCS立ち上げの準備を行うと良いかと思います。
