グーグルのカスタマーサクセスをリードするデューダ・サタディプ氏が、カスタマーサクセスの目標設定の考え方や成功事例をふんだんにお話しくださっている動画を紹介します！
注：Successly社のAdam O’Donnell氏の許可を頂き動画の和訳を紹介します。
アダム
Google のカスタマーサクセス責任者であるデューダさんは、2011年からGoogleのプロダクトマネジメント部門で様々な役職を担当し、現職直前は営業サポート担当でした。その前は Hewlett Packardほか一流企業の経験もあります。
とても興味深いのは、デューダさんが様々な職務を経験した後にカスタマーサクセスを選んだ点です。今日はそこに注目してお話しを伺います。
早速ですがカスタマーサクセスを継続的に改善していくためどのような目標を設定しているのか、まずはカスタマーサクセスマネジメントのフレームワークを教えてください。
デューダ
カスタマーサクセスマネジメントのフレームワークはどうあるべきか？・・・とても良い質問ですね。答える前に少しだけ “ストーリー（逸話）” についてお話します。
カスタマーサクセスにはある法則があります。それはサービスサポート部門か、アカウント営業部門か、ザックリどちらかにルーツがあるという点です。そしてこの２チームが協業すると、最悪な事態を誰々が救った！という類のストーリー（逸話）が残るほど上手くいくことが多いです。
こういう逸話は大変パワフルで人を魅了しインスピレーションを与えます。ただ残念ながら、日常業務で逸話的な仕事ができるカスタマーの数は限られます。そこで何らかの構造的な対応が必要になります。
私はこれを「逸話(story)から数字(scoring things)への進化の旅」と呼びます。皆さん測定は好きですよね。何より定量目標は必要です。ちなみに私は目標は定量化されるべしと信じています。
それには何がカスタマーにとっての成功なのか理解することがとても大事です。カスタマーの成功は業界や事業により違いますし、CSATやNPスコア以上に重要な指標もあります。それが何かを特定したら、次はどれを優先すべきか、どう測定し、どんな対策が必要かを考える必要があります。
以上が「逸話から数字への進化の旅」を成功させるには定量目標が超重要という非常に簡単な説明です。
アダム
チームに定量目標を達成してもらう秘訣は？
デューダ
定量目標すべてを達成しようとせず、いくつかに絞ることが重要です。測定を始めると、何が進行中か分かりやすく見える化され、特殊ケースの数字を追いかけたり、より正確に測定したくなるのは自然ことです。ですが「目標はまずハイレベルで考えるべし」が私の哲学なので、次のような質問をします。
・この指標が改善すればカスタマーから多くの価値を得られるのか？ ? もし答えが Yesならそれは測定すべきでしょう。
・この指標を測定しないと最悪の場合どうなるか？ ? 最悪でも何も起こらないか 又は測定すること自体で安心できるというものなら、それは良い指標かもしれませんが、目標指標というよりオペレーション指標とすべきでしょう。
この２つが、私が使うハイレベルのバロメーターです。
最後３つ目に使うのは、掲げたとたんに頭の切れるチームメンバーがゲーム感覚で取り組み始めるような非常に達成困難な指標です。
例えば「週X回カスタマーと話す」と目標設定すれば、彼らはその通り1週間にX回話します。ただ実際話すのは私でなく他のメンバーなので、成功比率やファネルの脱落件数もきちんと測定する必要があります。
オペレーション指標のような指標を測定する目的は、カスタマーサクセス的に不適切な行動を回避したり、長期的に非常に重要なカスタマーバリューに貢献しない行動を回避するためです。長期的カスタマーバリューの向上に繋がる行動が取られているかどうか確認するのも私の仕事です。
アダム
あなたはTotango社のカスタマーサクセスサミットで、カスタマーサクセスは比較的新しく具体的な指標はまだ検討中とおっしゃっていました。
数週間前、私はLinkedIn社でインタビューしましたが、彼らもカスタマーサクセスマネジメントで利益指標の測定はやめ、利益と相関する行動指標の測定だけにしたと言ってました。
あなたが適切な指標をどう選択しているのか興味があります。
デューダ
前提として、企業が提供するサービスは、その機能も向き合うカスタマーの事業ニーズも多様です。
私たちGoogleの成功にとり、キャンペーンマネジメントは非常に重要な要素です。カスタマーは彼らの事業目標である”頻度”や”コンバージョン”などを達成するためにGoogleにお金を払います。なので私たちは彼らが最善の方法で最高の結果が出せるようにする義務を負っているわけです。従って利益指標は大事ですが、それ以外にも重要な指標があります。
アダムの指摘はまさにその通りで、利益と相関する行動指標は確かにあります。キャンペーンマネジメントは恐らくその１つでしょう。
現実的にもカスタマーが私たちのプロダクトを活用するほどより多くの利益を得られるのは明快です。結果としてより利益の高いターゲットを獲得できますし、より良質なユーザーを確保できるからです。
従いプロダクトが正しく活用されるようにする必要があるのですが、それには利益指標でなく他の様々な指標を用います。
基本的には以下を測定します：
・ある特定の機能が利用されているか？
・キャンペーンの何％が実際に実行されたか？
・我々の提案が実際に採用されたか？
・提案が採用されなかった理由は？
最後に重要なのは、キャンペーンマネジメントにおけるプロダクトアダプションの最後に全体エコシステムを測定する点です。すべてを社内でやろうとするとリターンが限られます。なので、カスタマーのウェブサイトやモバイルアプリケーションなどで、相互にアプリを乗り入れ、データも共有する必要があります。
簡単な例でお話ししましょう。例えばECサイトを運営する場合、モバイルサイトのスピードが遅ければ、モバイル取引が利用されない可能性が高くなります。そうなれば、モバイル取引でのコンバージョンのダウンストリーム効果は期待できないでしょう。そこでGoogleは、自社プロダクトの導入とは全く関係ないサービスも提供しています。モバイルサイトやデータマネジメントプロバイダーなど全体エコシステムを構築するためのサービスです。
アダム
その3点を理解することは非常に大事ですね。どうやってこの３点をチームの活動に反映させていますか？
デューダ
正直、そこがとても難しく、ワクワクする部分です。
プロセスを定義して必要な活動をプロセスにはめ込むという伝統的な方法はある程度までしか機能しません。私はそれ以外に方法があると思います。
１つは、カスタマーの状況をチーム全体で一元可視化するメカニズムを持つことです。
実装担当者がよい仕事をしてもキャンペーンマネジメント担当者がそれを知らず、結果として何も進展しないことが度々ありました。そうならないよう、チームの端から端まで点と点を結んで情報を行き渡らせることが必要です。チームリーダーである私はメンバー全員がこの繋がりを理解すること注力しています。
もう１つは、好奇心旺盛なカルチャーを醸成することです。
他部門を巻き込む質問をするよう私はメンバーに促します。人は事前に知っていればその人の元へ行き相談する可能性がはるかに高くなります。私たちは楽しい行事を企画しチーム間のコミュニケーションが活発になるよう努力しています。そうすれば「あのチームのあの仕事を担当している誰々だ」と分かり、その人に連絡を取りやすくなります。
自然に人と人との繋がりが生れる環境を作ることで、興味があるとか、もっと知りたいと思えば、具体的に行動を起こすようになります。そうすれば実際に問題が起きた時、あるいは問題を解決しようとしている時、マネジャーが点と点を結び付けて問題を解決しようするのでなく、チームメンバー同志が自分たちで問題解決できるのです。
マネジメントとしてはこの２点です。ビジネス文脈の共有とアドホックなフォーラムの構築を推進することで、チームメンバー１人ひとりがお互いを知る機会をもち自分たちで問題解決できるようにするのです。
アダム
実際それが機能しているかをどうモニターするのですか？
デューダ
細部のモニターは色々と難かしい部分がありますが、私はいくつか原則があると思っています。
大抵の人は、データを見ると正確さを気にするように思います。例えば、これは小数点Xレベルで絶対的に正確な数字なのか、などです。しかし実際の事業上の意思決定は通常それほどデータの正確性を要しません。
私はトレンドや方向性に注目します。例えば方向性であれば、10点から2点、9点から2点にシフトしたかなど、点の絶対的な位置より、上昇トレンドなのか下降トレンドなのかを見極めます。このように、正確さに加え方向性に注意を払うことを心がけています。
もう１つは、一般的にオペレーションのモニタリングでは平均点や中央値に注目しますが、私は上位25％値(第一四分位)、下位25％値(第三四分位)を重視します。なぜなら事業を進化させるには、何が効果的で何が効果的でないかを知る必要があり、それが最大の機会を提供してくれるからです。下位25％群を少しでも上げられれば、平均値もぐんと上がります。平均値に加え、こうした視点を取り入れると良いでしょう。
最後に、我々には大勢のカスタマー、膨大なデータがあるので、平均値には情報が埋もれがちです。大きなデータセットを別の大きなデータセットで割り算すれば、データの動きは微々たるものになるからです。
そこで私は次のような質問をします：
・すべて良く見えるのは、逆にきちんと情報を読み取れていないからでは？
・もう少しデータを細分化して見る必要はないか？
・産業別の状況を分けて見た方がよくないか？
・カスタマー歴年数別に見たり、別の指標で判断した方がよくないか？
・採用してるプロダクト数別に見たか？
なぜならデータを細分化することで改善が必要な部分をピンポイントに把握できるからです。
そして何かが上手くいっていない時はその原因を考えます。もしかしたらマニュアルが不適切なのかもしれません。そういう場合もありますね。あるいは大勢のカスタマーと話しているのかもしれません。
例えば私たちのスタッフもそうですが、10月になるとブラックフライデーの準備をするので、その時期はすべて閉鎖され、ウェブサイトはそのまま放置されます。そうした時の数値が悪いのは、プロダクトが失敗だった可能性もありますが、実際には何が起きていたかに注目すべきです。数値の上下だけに注目していると、突然失敗してしまったのだと誤解します。実際は失敗ではなく、想定内の出来事かもしれません。
アダム
チームをリードするため、より良いプロセスを導入したり、目標を設定したり、プロセスをモニタリングしたいカスタマーサクセスリーダーが考慮すべき点は？
デューダ
創業直後でどの目標が重要かまだ分からない場合、チームを２つに分けて同時に２つ別のことに取り掛かる方法をお勧めします。特にデータがない初期にデータ収集している段階は、まずはそれに集中すべきです。データを収集し「この指標は必要か」を実験なりテストしてみて初めて分かります。
我々も、ショッピングポートフォリオプロダクトのプロダクト採用戦略を練ったことがあります。最初は何が重要な指標か分からない状態でした。いくつかの指標から始めましたが上手くいきませんでした。
重要指標の１つが導入率であることは分かっていたのですが、なぜ導入率が上がらないのか原因が特定できませんでした。いくつか試してみたところ、私たちの提案内容が悪かったのではなく、一番大きな要因は、提案件数が多過ぎたということでした。
そこで提案件数を減らさねばということになり、その一環で、カスタマーがショッピングSKUに関心があることをうけ「SKUトップ100 レポート」というアイデアにたどり着きました。
売れ行きの良いSKUは利益が最大化するのでカスタマーは大変興味があります。そこで「あなたのトップ100はこれこれなので、こう変更すべきです」という提案を簡潔にまとめました。するとカスタマーは突然「これは素晴らしい！」と言い実際に導入して改善できたのです。つまり100という数が、カスタマーが理解し行動を起こせる最適数だったのです。ただそれが分かるまで四半期強の時間を要しました。
アダム
大変興味深い話ですね。そのA/Bテストのような方法は様々な分野で常に行っているのですか？
デューダ
違う分野に加え、違うアプローチだったり、違うカスタマーだったり、割と取り入れてます。私たちは大変多くのプロダクトを販売しているため、摩擦が生まれやすいプロダクト採用時には特に活用しています。
実は私たちのプロダクトは機械学習を取り入れてますが、それにはある一定期間キャンペーンを実際にやってみる必要があります。スイッチを入れたら自動的に動作するわけではありません。
例えば「X量の予算をY期間で投入するように」などカスタマーに的確な提案をする必要があります。実験的なことも必要で、インターネットトラフィックのパターンやその他色々な要素を考慮し、旅行業界はX、小売り業界はYなど、別々の提案をすることもあります。
アダム
プロセスに関して面白くかつ学びのある経験はありますか？例えば、何かに挑戦して成功すると思ったのに逆に失敗してしまったなど
デューダ
ありますよ。先ほど少し話したモバイルの事例をご紹介しましょう。
当初、カスタマーになぜこれが重要か説明し、実例を見せ、カスタマーのウェブサイトを使って詳細を提案すれば、カスタマーは提案を実践するはず、と想定しました。とても論理的で、カスタマーにも有益で、Google社もいらないほどですよね。
しかし結果は上手くいきませんでした。実践した人はほぼゼロ、極わずかでした。原因を探るため、カスタマーになぜ提案通り実践しなかったのか聞いたところ、理由は沢山ありました。
理由の１つは、ドキュメンテーションを見るとAPIが複雑すぎて誰に連絡すれば良いか分からない状態になっていたことでした。複雑化し過ぎてしまったのです。
２つ目の問題は優先順位をどう決めるかでした。日々生活の中で色々なことが起こっていて時間が足りません。とてもシンプルなことに聞こえますが、実際に実行するのに必要な時間が半分もないわけです。
私たちはこうして試行錯誤を６?８か月続けたわけですが、当然なかなか順調にいきませんでした。そしてようやく「カスタマーに何をすべきか指示することが正解ではないと」分かったのです。正解は、カスタマーと手を握って励ますことでした。そこで私たちはもっと楽しい環境を作ることにしました。
現在、モバイル “ハッカソン” イベントを開催し、Googleへ皆さんを招待しています。カスタマーは彼らのITチームやエンジニアリングチームが参加できます。私たちもソリューションエンジニアを参加させます。
そこで毎回必ず２つの感想を耳にします。
1つは、実際に考える環境がもてて嬉しい、という声です。面白いですよね、皆さん情報は沢山もってるのに考える時間がないのです。なので、まずは考える時間を作ることが大切です。楽しい時間です。
もう１つは、問題に直面した時にどうすれば上手くいく・いかないを的確に教えてくれる人が必ず周りにいて嬉しい、という声です。つまりカスタマーと私たちチームメンバーがお互いに関わり合う、楽しくて魅力的な環境だということです。その都度１人ひとりのカスタマーの元へ行ってそういう環境をつくるのでなく、小規模なイベントとして 10、15、20のカスタマーが一同に集まる場所として開催します。
開発者はこのような環境がとても好きだということを、私たちも初めて知りました。開発者は互いに話し合うのが好きで、挑戦したことや、効果的だったこと・なかったことを実際に共有できて嬉しいのです。
モバイルハッカソンイベントは、コミュニティをサポートするのに良い方法でしたが、同時に事業としても有益でした。逆に、数多くのプレゼンテーション資料や伝統的な方法は全く成功しませんでした。
アダム
そのイベントはGoogleキャンパスで半日行われるのですか？
デューダ
はい、Googleキャンパスで開催します。半日ないし、１日の４分の３ほどの時間です。大々的なものではなく、「ようこそ」といったサインを掲げるぐらいです。食べ物もピザとかソーダなど、決してホテルのような豪華なものではありません。大抵、Googleの大きめな会議室で行うので、膨大な費用がかかるものでなく、宣伝もしなければ、登録も不要です。
営業チームを中心にGoogle社員が「もしハッカソンイベントに興味があれば開催しますが参加なさいますか？」と周囲に声をかけます。そうして希望者が募られるとイベントを開催するのですが、かなり希望者は多いですね。
