SaaSが成長を続け、カスタマーサクセスという言葉や役職が流通していくなかで、従来の「カスタマーサポート」をどのような位置づけで考えるべきか、疑問の声を聞くようになった。
サービス事業者がサブスクリプションモデルへの移行でビジネスの成功を導き出す昨今の流れからすれば、スタートアップのみならず、今後は大企業も含めて起きうる課題といえるだろう。
そこで、クラウド名刺管理サービスなどを提供するSansanでカスタマーサクセスに従事し、著書『カスタマーサクセス実行戦略』を持つ山田ひさのりさんに、あらためてカスタマーサポートとカスタマーサクセスについて、その使命から始まる位置づけや役割、両者の最新トレンドまで、さまざまに寄稿いただいた。
連載初回ではテクニカルサポートとカスタマーサクセスの違いをイシューから見ていった。第2回では、テクニカルサポートを事業部内の位置づけから見直すことを勧めた。第3回は最新トレンドであるライブチャットとの向き合い方と、ナレッジベースを構築することの重要性を再考した。
迎えた連載最終回では、いよいよこれまでを踏まえた「テクニカルサポートの組織化」が提唱される。いかにして理想を描き、実現させるのか。
ーーーーー
理想的なテクニカルサポート組織を作る手順
ここまでの連載を通じて、以下のことがわかりました。
- カスタマーサクセスとテクニカルサポートの違い（＝取り扱うイシューの違い）
- テクニカルサポートのミッションは「問い合わせを発生させないこと」「発生した問い合わせを迅速に解決すること」
- テクニカルサポート組織をプロダクトとカスタマーサクセスのどちらに位置づけるのかでその後の進化が異なる
- 2021年現在のテクニカルサポートのトレンドはユーザーの「低努力」
- 「低努力」トレンドの影響もあり、SaaSスタートアップではライブチャットを活用し、かつカスタマーサクセス組織がテクニカルサポートの役割を担うことも多くなっている
- ライブチャットは手軽に始めやすい反面、後のスケールアウトに繋げにくいデメリットもある
- サービス提供側は「低努力」と「低運用負荷」を両立しなければならない
- スケールアウトに有効なのはナレッジベース（ヘルプやマニュアル、FAQ）を蓄積し、顧客自身に参照・解決してもらうこと
今回はこれらを踏まえ、私が理想と考えるテクニカルサポート組織の作り方を論じてみます。
前述のとおり、テクニカルサポート組織を作る上での大きな意思決定は、この組織の位置づけにあります。プロダクトの一部なのか、カスタマーサクセスの一部なのかを決める判断によって、のちの進化が定まるため極めて重要です。あらためてざっくり説明すると、
- 初期段階で「プロダクトの一部」とした場合は、ナレッジベースの蓄積は加速するが、顧客体験は低下しやすい
- 初期段階で「カスタマーサクセスの一部」とした場合は、早くから顧客体験を向上させることはできるが、ナレッジベースが溜まりにくい
という傾向になります。この事実を踏まえると、テクニカルサポートの事業における理想的な位置づけは、以下のようになると考えます。
カスタマーサクセスの一部（1～3年程度）
→ プロダクトの一部（4～8年程度）
→ カスタマーサクセスの一部（それ以降）
「その位置づけを継続すべき年数」は私の肌感ですが、それなりの裏付けもあります。
SaaSの初期段階ではテクニカルサポートに割り当てられる人的なリソースが少ないため、カスタマーサクセスがこの役割を同時に担い、かつ顧客体験の向上に努めながらストック収益の最大化に務めるのがベターです。
SaaSの運営が3年も経つと、提供するプロダクト・サービスの顧客も増えているため、ナレッジベースの構築が急務になってきます。このタイミングでテクニカルサポート組織をプロダクトに寄せ、ナレッジベース制作のポリシーやフローを整備し、来たるべき顧客増に備えます。
ナレッジベースの蓄積が加速し、顧客の問い合わせに対する解決スピードや正答率をKPIとすることで、「量を速く捌く」という能力が組織に蓄積されていきます。ただ、この数値の上昇は年々頭打ちになってくるので、こうなるとテクニカルサポートを再びカスタマーサクセスに寄せ、LTV（Life Time Value）の最大化と顧客体験（CX）の向上を組織の新たなミッションに加えます。
こうすることで、マンネリ化した顧客対応と組織運営に新たなスパイスを与えるとともに、SaaSのそもそものミッションに立ち返ることができます。
このように書くと「その先は？」という質問が聞こえてきそうですが、約15年の歴史を持つSansanにおいても、そこから先の景色は見えていません。ここはわれわれも常に模索中ですが、他のSaaSベンダーとの比較において、ここまでを一つのプラクティスとしてまとめることはできました。
テクニカルサポートがLTVとCXを意識するということ
今日のSaaSのテクニカルサポートの主なミッションは2点が挙げられると連載第2回で述べました。
- 顧客にファンクショナルな疑問を持たせない
- 持たせてしまった場合は迅速に調査・解決する
では、組織のミッションにLTVとCXを加えるとは、どのような意味を発揮するのでしょうか。この疑問には、以下3つが答えられます。
- 一つひとつの活動を顧客のタッチポイントとみなす
- 「点」ではなく「線」の活動と捉える（顧客ライフサイクルを意識）
- 顧客に対して「優先順位をつけた活動」とは何かを模索する
顧客からの問い合わせ対応はともすればタスク化しやすく、顧客体験を向上する機会の一つとは考えづらくなります。言い換えると、顧客の活動を逐次的に発生する作業（点）として捉えてしまっており、ライフサイクル（線）で見られていないために起こってしまうのです。
最近のカスタマーサクセスの活動においては、カスタマージャーニーや顧客ライフスタイルを定義することが推奨されています。それらの考え方に基づいた場合、「顧客からの問い合わせやヘルプをどのように見ていたか」は重要な顧客接点となりえます。そして、この線上に発生するさまざまな顧客体験を向上させていくことは、顧客のLTVの向上にも繋がります。
LTVの観点において、もう一つ重要なのは優先順位のつけ方です。これまでのテクニカルサポートはどのような顧客であっても、平等なスピード・クオリティで対応することを求められてきました。しかし、ここにLTVの考え方が入ると、「自社にとって重要性の高い顧客を優先的に扱う」という考え方になります。
この考え方に対する是非はありますが、その思想自体は妥当なものです。LTVと言うと、とかくMRR（Monthly Recurring Revenue）などの支払額の大きさ一辺倒で優先順位をつけてしまいがちですが、“自社にとって大事な顧客”の定義の正当性さえあれば、どのように意思決定しても問題ありません。これはカスタマーサクセスにおいてよく知られているハイタッチ、ロータッチなど顧客をセグメントして対応する手法と何ら変わることはないでしょう。
仮にテクニカルサポートにおいて顧客への対応に濃淡をつける場合、特別なサポートプランを用意し、そのプランに対して課金している顧客に対しては優先的に対応するなどになるでしょうか。私の周囲でもこのようなプランとスキームを用意している事業者はあまり見かけませんが、その思想には納得感があります。
自社の事業フェーズにマッチした、適切なサポートチャネルの選択
私なりの理想的なテクニカルサポートの位置づけは上述したとおりですが、それ以外にも重要なのはサポートチャネルの適切な選択です。
サポートチャネルは連載第3回で書いたように、「顧客努力」と「運用負荷」のバランスを常に考えて設計しなければなりません。下記は再掲ですが、主なサポートチャネルの特徴をコメントした図です。
ナレッジベースを整えることはITサービスにおける基本です。そして、ヘルプ・マニュアルを整えていくにあたって重要なのは、次の5点です。
- ヘルプ・マニュアルページに「記載すべきこと」と「しないこと」の整理
- ヘルプ・マニュアルページの情報設計（どの粒度の情報を記載するか）
- 用語や書式の統一
- トンマナとデザインポリシーの統一
- 制作フローの標準化
これらはテクニカルサポートをプロダクトの一部に位置づけることで加速します。「見やすい・探しやすいヘルプとは何か？」という問いに対する答えを模索することにも相当します。
ナレッジベースが蓄積されている前提においては、フォームので問い合わせ受付は「顧客努力」と「運用負荷」のバランスが最も良いチャネルです。フォームで問い合わせを受け付けるということは、顧客からの問いに非同期で対応する戦略を取ることです（これはメールも同様です）。
非同期で対応するということは、計画性を持った対応が可能であり、現場で対応するメンバーに「対応速度」「正確性」などのKPIを持たせることに繋がります。
通常、フォームで受け付けた顧客からの問い合わせは、専用のシステム（多くはSaaS）で「チケット」として管理されます。このチケットが流入してからクローズするまでの間、ユーザーと担当者の間で何度かのやり取りがあります。この「チケットのラリー回数」や「初回返信までの時間」をKPIとすることで、素早く正確な問い合わせを数値化できます。
Sansanの場合は、ヘルプページを回遊した結果、欲しい答えを見つけられずにフォームから問い合わせた、「フォーム到達率」をKPIの一つにしています。月単位など一定期間この値をウォッチすると、自社プロダクト・サービスの平均レンジがわかります。この数値低下を目標に持つことで、「問い合わせを発生させないヘルプとは何か」という目標に近づいているかも測れます（また、「フォーム到達率」ではなく「チャット到達率」にしても同じことが測れます）。
ナレッジベースが整うと、「ユーザーが正しくナレッジベースを探せば、ほしい回答にたどりつく」という一見すると当たり前のことが成り立ちます。しかし、ユーザーはそんなことはお構いなしに問い合わせをしてくるものです。このような状況に陥った次の一手としてチャットボットの活用が挙げられます。
私はチャットサービスを使うのであれば、チャットボットとライブチャットを同時に使うのがベターだと思っており、チャットボットで回答を得られなかったユーザーのみライブチャットに誘引することをお勧めしています。
チャットボットはSansanでも活用していますが、導入する意思決定をしたのは、「Sansanにおいてフォームから来る問い合わせの4割はヘルプを調べればわかることだった」という分析結果が出たからです。
つまり、ユーザーの求める答えはヘルプに存在しており、ユーザーがその情報に到達する導線を洗練させれば解決することがわかっていました。この4割の問い合わせに対し、適切なナレッジベースを案内できれば、低努力と運用負荷低減も両立できるわけです。そして、チャットボットでも回答できなかった問い合わせのみをライブチャットで対応すれば、顧客体験を高い状態でキープしつつ問題を解決できるのです。
（ちなみにSansanでは非同期での問い合わせ対応戦略とっているので、ライブチャットは使用していません）
ただし、この仕組みはナレッジベースが構築されているからこそ成り立ちます。そのような意味でも事業の成長過程でナレッジベースを整えることは大きなリターンを生みます。だからこそ、ナレッジベースの構築は問い合わせ対応の基本なのです。
まとめと謝辞
この連載ではテクニカルサポートとカスタマーサクセスの違い、そしてテクニカルサポートのミッションを改めて整理し、SaaSの事業フェーズにおいて私が理想と考えるテクニカルサポートの位置づけを説明しました。
カスタマーサクセス＋テクニカルサポートをどのように設計するかはあまり議論されておらず、私も長い間頭を悩ませてきたのですが、今回多くのSaaSベンダーのテクニカルサポートの方々にお話を聞くことで長年の疑問が整理されました。この場を借りてご協力いただいた方々に感謝申し上げます。
特にSansanのテクニカルサポートを長きにわたって牽引してくれた村松寿彦氏（2020、2021年Zendeskチャンピオンでもある）に感謝を表明します。この連載で紹介した多くのプラクティスは、彼の経験を元に私が文書化しました。
これらプラクティスが多くの方に伝わり、SaaS市場の発展へと繋がれば嬉しい限りです。
