ケリーさんの記事「優秀なカスタマーサクセスマネジャーを採用し、育成し、活躍し続けてもらう方法」は反応がとてもよく、改めてカスタマーサクセス人材への注目の高さを再確認しました。

そこで、私の愛読するケリーさんの記事をもう１つ紹介します。

サポートとサクセスの関係についてですが、よく耳にする従来の比較論（前者は受け身、後者は攻め...）とは全く内容が異なります。一歩先をいく賢い組織の実務を踏まえた「両チームの補完関係を築くことでカスタマーサクセスのレベルを上げるべし」という内容です。

特に、サポートチームで活躍してるエンジニアの方に是非（何度も！）読んでほしい記事です。

注：著者John Kelly氏の許可を頂き原文の和訳を紹介します

カスタマーサクセスのためにサポート部門を最大限活用する方法

カスタマーサクセスは今や大勢から注目を集める存在で、特にカスタマーサクセスが契約更新で重要な役割を果たすSaaSの世界では注目度もウナギ上りです。

一方、カスタマーサポートは、カスタマーサクセスに比べ、受動的で魅力が薄く、壊れたものを直す部署、と未だに認識されています。

組織構造上、カスタマーサポートはカスタマーサクセスと別チームの場合が多いですが、カスタマーの成功を実現するという目的において、カスタマーサポートはカスタマーサクセスと等しく重要な役割を果たす存在です。その点を理解し、組織間の壁を打破しようとしている賢い組織は、カスタマーサクセスのレベルアップに成功しています。

オンボーディング

企業の成長段階に応じた、カスタマーサポートとカスタマーサクセスの遍歴について見てみましょう。

スタートアップでは通常、１つのチームがカスタマー対応を担当し、オンボード中のカスタマーに関する苦情処理から契約更新まですべて行います。企業が大きくなり、新しい組織やプロセスが追加されるに従い、それぞれの役割を担う正式なチームが編成されていきます。

SaaS企業がある規模に到達すると、すべてのカスタマーと接点を保ち、すべてのリスクや機会を管理することは不可能になります。

そこで、カスタマーサクセスチームが組成され、カスタマーがプロダクトの価値を確実に享受できるようにします。つまり、より積極的に契約更新を得る仕組みづくりをするのです。

一方、サポートチームは、カスタマーから寄せられた問題を解決するチームとして組成されます。両チームに個別の重点領域と専門性をもたせることで、カスタマーサクセス活動のスケールを利かせていこうという発想です。

問題は、両チームがサイロ化することで、チームワークや協調性の点からトレードオフが生じてしまうことです。

最大のリスクは、補完関係の効果が消滅し、カスタマーサクセス視点の共有目的を見失うことです。各チームの責任者が別になったり、それぞれが異なる指標やプロセスをもったり、究極はカルチャーまで違ってしまうと、このサイロ現象は更に悪化します。

一方、賢い組織はカスタマーサクセスためにサポート部門を最大限活用します。時にはサポートとサクセスを統合までします。

サクセスチームへは大きな期待が寄せられます：
サポートエンジニアリング部隊は毎日カスタマーとやりとりし、サクセスツールキットを改良し、様々な視点からカスタマーへ成功をもたらすための計画を改良するようつとめます。

サポートチームへも期待が寄せられます：
壊れたら直すという要対応案件数を極力減らし、サポートチームの意見や知見を聞き、サポートチームメンバーの他部門へのキャリアパスが検討されたりもします。

両チームはそれぞれ専門分野が別なものの、"カスタマーの事業での成功を支援する" という共通目標の上に課題を整理することで、強力な補完関係が可能になるのです。

なぜカスタマーサポートは存在するのか？

「なぜ、組織は存在するのか？」

これは、著書『ザ・アドバンテージ　なぜあの会社はブレないのか？』の著者、パトリック・レンシオーニ氏の問いです。同時に、ミッションや意味づけを重視するすべての組織にとって重要な問いです。

カスタマーサポートリーダーにとってその答えは、「カスタマーの問題を早く解決するため」であり、可能な限り短い時間で問題解決するのが理想です。

この視点に立つと、観察すべき指標は一般的に、応答に要した時間、解決に要した時間、当初見積り時間の修正割合、CSAT、NPSスコアなどです。これらの指標は決して悪いものでなく、実際、多くのサポート部門で役に立ち続けています。

しかし、カスタマーサクセス視点、つまりカスタマーを虜にするという視点に立つと、このような指標は果たしてベストなものでしょうか？

指標に「カスタマーの成功体験を手伝うこと」や、「カスタマーがその商品への投資から期待した価値を得る手助けをすること」を加えてみましょう。すると、サポートチームのミッションが拡大し、カスタマーの時間がとられることで生じる事業への悪影響を最小化するという目的にあらゆる活動が向かいます。

これは、単に壊れたウィジェットを直す以上のことを意味します。つまり、サポートエンジニアは、追加したツール、知識、アドバイスなどの経験を生かし、同様の問題の再発防止に努めるようになるからです。

こうしてサポートの役割は、"壊れたら治す"から、専門知識でカスタマーを支援したり、問題の再発防止をしてカスタマーの事業への影響を最小化したり、カスタマーを支援するのに必要ならあらゆる行動が取れる権限が与えらえたり、と徐々にシフトしていきます。

まさに、サポートにとっての改善、サクセスにとっての改善、そしてカスタマーにとっての改善です！

カスタマーサクセスはバケツリレー？

典型的なカスタマーサクセスのプロセスは、オンボード、アダプション、エクスパンション、契約更新と続きますが、一般的にこれらのプロセスはバケツリレー的に進むと思われています。

しかし実際のカスタマージャーニーはカスタマーごとに全く異なりますし、あなたの会社のプロダクトの使われ方やサクセスチームとの関わり方も各社各様です。

そのような多様な道中、様々な課題に直面する中で成果を出すため、サクセスチームはサポートチーム含むあらゆる部門と連携する必要があります。

「賢い組織はカスタマーサクセスのためにサポートチームを最大限活用する」と先ほど述べました。ではサポートチームをどう活用すればカスタマーサクセスを最適化できるのか、具体的に見ていきましょう。

1. 組織的な連携

TSIA社のサービス組織調査2015によると、サービス系グローバル企業の中で "カスタマーサクセス" という言葉は既に市民権が確立され、サポート部門はその40％超の時間をカスタマーサクセス部門に対しレポートする関係にあることが明らかになりました。

単に組織を統合しただけでは不十分です。

両チームがシナジーを発揮するには、サポートチームの業務プロセスや１人ひとりの行動様式を変える必要があります。決して大規模な変更を行わなくても効果は出ます。

まずはプロセスや役割を小さく変更し、指標に現れる反応を評価し、それを何度も繰り返して微調整し、最終的にある規模の改善効果が出るまでそれを何度もやり続けてみてください。

2. オンボーディング

サポート依頼案件の分析は、通常、効果不透明なトレーニングに帰結しがちですが、実はオンボードの標準プロセスに追加すべきなほど有用な情報源です。

分析結果は、トレーニングの効果評価だけでなく、オンボード実務をより良いものへ改善していく動機づけにも使えます。

オンボーディングで最も頻繁に起こる問題についてサポートエンジニアに聞いてみると、一歩先をいく洞察が得られます。

そうした洞察から、予期される問題をカスタマーと事前共有しましょう。そうすれば、カスタマーはダウンタイム（注：不具合等でシステムが一時的に稼働停止する時間）の潜在リスクを理解してオンボードに臨みます。

また、サポートエンジニアの洞察をオンボードで用いる教材に反映しましょう。そうすれば教材は想定ターゲットがより明快な内容へと昇華され、トレーニングがより実践に結びついたものになります。

実際、最高のオンボードトレーニングを設計する方法は、サポートエンジニアに対し、彼らの見立てに基づくサポートデータの提供協力をお願いすることです。そうすれば、カスタマーは起こりえる問題の予防方法を知ることができ、サクセスチームは効果的なトレーニングを提供することができ、サポートエンジニアはサポート依頼数を減らしつつ自分たちの仕事に新しい視点を取り入れることができるのです。

オンボード教材や成功事例の共有

サポートチームに対し、オンボードのトレーニングスケジュールとトレーニング教材の保管場所を、いつでも参照できるよう共有しましょう。

サクセスチームがそういった詳細データやデモ資材などをサポートチーム会議で共有すれば、サポートエンジニアの巻き込みは容易に進みます。

サポートエンジニアから成功事例を教えてもらうと、カスタマーは、トレーニングで新しい知識を得て実務へ生かそうという気になります。サポートエンジニアはそういう人たちです。

また、カスタマーとサクセスチームがより良い関係になるよう、あるいは事前に関係構築できるよう、必要ならサクセスチームにカスタマーを紹介までしてくれる人たちです。

3. アダプション

人は基本的に変化が嫌いです。物事がうまく進んでいる時ほど特にそうです。

カスタマーにある新しい機能を試してもらうには、多面的アプローチや新たなメリットが必要でごく小さなステップの形をとります。

リリースさえすれば、カスタマーが新しい機能を必ず使ってくれるという保証は一切ありません。カスタマーが新機能にあなたほど興味を持つことはまずありません。

実際、新しい機能でなく別の目的であなたのプロダクトを買ったカスタマーなら、なおさら、なぜ新機能を使う必要があるでしょう？

サポートエンジニアは定期的にカスタマーと話す役割を、技術力の高いシニアレベルのサポートエンジニアは信頼性の高いアドバイザーとしての役割を担っています。こうしたサポートエンジニアに時間をとってもらい、新機能のメリットや他社が同機能をどう利用しているかなどをカスタマーに伝えてもらいましょう。

そうすれば、カスタマーがプロダクトを使いこなすレベルが格段に向上すること間違いなしです。

4. エクスパンション

カスタマーは、サポートエンジニアとの議論の最中に時々、エクスパンションを匂わす小さなサインを出してくれます。

例えば「近々、新支店を開設する予定で、XXをすぐ解決する必要があるんだ」とか、より直接的に「御社のプラットフォームは、ネットワークモニタリングに加え、デバイスマネジメントも出来ますか？」といった発言があれば、今度は営業チームの出番です。

サポートチームは重要な参考情報を入手するだけで十分です。あとは、売るのが本業の営業チームがキッチリ仕事をしてくれます。重要な点は、サポートエンジニアに本業以外の役割を与えすぎないことです。

また、案件獲得には色々な形のインセンティブを用意すべきです。全社会議の場で功労賞などで報いる方が、案件数やコンバージョン数に基づくボーナスで報いる（これは時に期待しない行動を招く可能性があります）よりも効果的かもしれません。

5. リニューアル

サポートチームと契約更新チームが組織的にサイロ状態にあると、契約更新タイミングで事前に積極的な働きかけをする貴重な機会を取り逃がしがちです。

契約更新時期は、問題をなるべくオープンにし、大きな案件こそ、全ての利害関係者による協働と対話を絶やさず、上位者を巻き込んでいくことが理想です。

理想シナリオが現実には難しい場合、少なくとも重要な未解決案件を特定し、解決案件数を更新したり解決計画を作ったりできるようにしましょう。

そうすれば、契約更新チームは更新通知をカスタマーへ送付する前に、より積極的にカスタマーへ情報提供できるようになります。

6. カスタマーサクセス計画のレビュー

優先順位別やプロダクト別に分類したサポート案件の分析データは、サポートチームの存在価値を赤裸々にしてくれます。例えば、解決済み案件数や解決に要した時間などです。

同様に、カスタマーの行動や知識に起因する割合を含むことの多い、カスタマーへの貢献要因分析データは、カスタマーサクセスの存在価値をより明確にしてくれます。

7. 問題解決プロセス

SaaSの世界で興隆しているカスタマーサクセスは比較的新しい概念ですが、その中心にある基本概念のいくつかは実はずっと前から存在していました。

フォードの8d品質問題解決プロセスや、インテルの7ステップは、根本原因の解消を基本としつつ、対処療法として修理や応急措置ステップなども含む、構造化された問題解決プロセスの一例です。

こうした問題解決プロセスを活用し、カスタマーへより適切な対策を講じたりより迅速に対応することで、ダウンタイムの影響を最小化することが可能です。

ポイントは、こうした構造化された問題解決プロセスを用いる対策行動こそ、カスタマーサクセス視点の行動そのものだという点です。

こういう行動をとることは、根本要因が何であろうと、技術的な問題の発生に伴うカスタマーの事業への悪影響を最小化することが最も重要なことだ、という強いメッセージをカスタマーへ届けることになります。

また、こういう行動こそサポートチームの問題解決プロセスそのものであると強調することで、カスタマーサクセスの目的共有意識が強化されます。

8. リーダーシップ

経営層の強いリーダーシップは、カスタマーサクセスとカスタマーサポートが共通目標に向かいイノベーションを創出できるよう、意味ある動機づけをしたり支援をしたりする重要な役割を担います。

斬新なアイディア、画期的なプロセスや問題解決プロセス、その他あらゆる形のイノベーションは、経営層の強いリーダーシップによる動機づけや支援が無しでは決して生まれません。

9. 指標

「測定されれば注目され、注目されれば解決される」は、カスタマーサクセスの世界でも当てはまります。

もしあなたの会社のサポートチームに、技術的な問題を解決するだけでなく、カスタマーサクセスへの意識を高く持ち、サクセスチームと歩調を揃えて行動してほしいと思うなら、そういう目標と連動した指標の運用が必須です。

指標は１人ひとりの行動に影響を与えます。もし解決案件数だけ測定していたなら、あなたが手にするのは解決案件数のアップのみでしょう（そしてカスタマーにとり本当に解決したかどうかは別問題です）。

著者 John Kelly氏 について
CustomerLink社のマネージング・ディレクター。同社は、ヨーロッパを拠点にSaaS企業に向けてカスタマーサクセステクノロジー＆サービスを提供する会社であり、Natero社のEMEAにおけるエクスクルーシブ・パートナー。