見出し画像

カスタマーサクセスが担う”運用体験”の改善 ＃SaaSLovers

こが
■このポストについて
・この記事はブログリレー企画、 #SaaSLovers の3日目の記事です✍
・SmartDriveでカスタマーサクセスを担当している古賀が書いてます🙇
・結局カスタマーサクセスがやるべきことはプロダクトへのコミットだよね、という話です🔥

この1年間、カスタマーサクセスチームのマネージャーとして自社SaaSに関わってきました。先日Tweetもしたのですが、結局大事なのはサービスを利用した際のユーザー体験が良いものになっているのかどうか、に収斂されてくるなと感じています。

「ユーザー体験」という言葉には、営業担当とのコミュニケーションなどに起因するものもあるけれど、一番深く、そして長時間発生するのは運用であり、だからこそ運用が自然と馴染むSaaSがユーザーからより高い評価を受けるのは間違いないはずです。

そんなことを考えながら僕がカスタマーサクセスの立場からどのようにユーザーの運用体験の改善にチャレンジしたのか、そこで感じたことなんかをつらつらと書いていきたいと思います👨‍💻

SaaSビジネスの大前提

もはや書くほどのことでもないですが、SaaSビジネスにとってプロダクトと運用はセットであり、その2つをもってサービスが成り立つ、切っても切り離せないもの。多くのSaaSベンダーのカスタマーサクセスチームがオンボーディングを主要KPIに据えるのも、運用がユーザーのオペレーションに乗らないと即座にチャーンされることを身に沁みて理解しているからです。

ただし、ベルフェイス小林さんが2018年時点で記載しているように

Product is King，CustomerSuccess is Queen

であり、良い運用体験が担保されるか、その大部分はカスタマーサクセスなどの努力というよりもプロダクトそのものに掛かっていると感じています。

運用に関わる機能改善の難しさ

一方で、運用の体験を改善する機能開発はなかなか優先順位をつけにくいもの。SaaSがスクラッチではなくいわばパッケージとしてデザインされている以上、ユーザーがSaaSに合わせてオペレーションを設計・運用すべきという論も正しいし、どこまでどう対応するの、というのはリソースが有限である以上人や立場によって異なる、というのが正直なところです。

画像4

ただ、提供しているサービスがどのようなものであろうと、機能開発の優先順位は右上の領域だろうし、その点から考えると、
・運用に関わる機能で発生するペインの頻度は間違いなく多い
・強度さえ判断できれば、機能実装もより行いやすくなる
はずです。
そして運用においてこの右上に位置するのは何か、を社内で誰よりも理解できているのは間違いなくカスタマーサクセスのメンバーだと思います。

カスタマーサクセスとしてどう働きかけるべきか

そう考えると、最前線にいるカスタマーサクセスのミッションはもちろん個社ごとのサクセスは前提として、そこから得られたイシューの整理、抽象化、とりまとめであり、その知見をもって1からnに向けた運用体験の改善に繋げること、と定義できるかなと。

PdMやPMMがこうした機能、ミッションを持つケースは多いと思いますし、もちろん僕たちもそうではあるのですが、「お前のKPIは俺のKPI※」という前提に立ってCSがプロダクト側のKPIを持つことが重要と思っています。
※これは僕の言葉ではなく、尊敬する　dotD APAC CEO佐々木さんの言葉です。

実際にこの1年間を通して僕が取り組んだなかでCSがやることに強みを出せるのは以下の領域だと思います。

・ユーザーに生じているペインの理解とイシューの整理
・イシューに基づくソリューション案の策定・提案
・リリースまでの伴走

ユーザーに生じているペインの理解とイシューの整理

ユーザーペインが何で、どこでどうして発生しているのか、を理解することが改善にむけたファーストステップではあるものの、言うは易しというやつでパワーがかかる最大のポイント。カスタマージャーニーを作っている会社は多いと思いますが、個人的にはよりドリルダウンしていかないとなかなか明確な答えは出ないと思っていまして、そういう観点からユーザー行動フローをより丁寧に洗い出していくことが重要だと思います。

ここは日々数多くのユーザーとの接点を持っているCSが一番貢献できるポイントで、基本となるユーザーの行動を1つ1つ書き出し整理していくことによって無駄な負荷が発生しているポイントを社内のメンバーが俯瞰的に理解してくことができるようになります。

画像2

※ユーザー行動フロー取りまとめのイメージ
地味な話ではありますが、ユーザーに飛んでいるオンボーディング用のメール原稿、なども気を抜くとプロダクトチーム側は誰も知らない、みたいなこともあると思っていて、そうした情報の窓をこうした資料の中においておくと情報格差が埋まっていき全体の目線が合うのでおすすめです。

もちろん、社内の各メンバーとユーザーとの接点をつくるのも発生しているペインの整理においては重要な要素です。直接ユーザーからあがってくる生の声によって具体的に理解が深まりますし、洗い出したペインの強度、みたいなものはCSとして聞いている声をこちらからフィードバックする何倍も伝わるはずです。特に2020年は活動がオンラインに移り、Webを通じて顧客接点を創出しやすくなったのはとてもいい機会だったと思っています。

イシューに基づくソリューション案の策定・提案

上記のようなことから解決するべきイシューが定まったとしてもその解決方法はいくらでも考えられます。

SaaSとして提供する機能は利用するユーザーに拠って定義されていくもの。
であるならば、そのソリューション（※ 実装方法ではなく、運用体験としての機能のあるべき姿）もユーザーを理解するCSがコミットしていくべき領域だと思います。

画像3

オンボーディングプロセスのなかで多くの企業様に発生する体験改善（またその機能改善）に取り組んだ際には具体的なケースのボリュームなどから必要性を整理、具体的にどのように変えていくべきなのかをCS側で取りまとめて提言していきました。

これはユーザーの運用体験を改善するために必須のアクションであり、放棄してはいけない領域だと感じています。もちろんこの後は開発側のメンバーも含めてディスカッションを行い最終的な形を作り上げていきましたがこのスタート地点にCSが立つのはめちゃくちゃ意義があると思っています。

リリースまでの伴走

ここは言うまでもないことですが、リリースに向けて社内外での伴走を行うこともカスタマーサクセスとして取り組むべき領域です。

機能をリリースするまでには

・要件、実装方法のFix
・実装
・リリース（＋改善）

という3ステップがあり、それぞれのステップで社内外の合意形成を取りながら進めることによってユーザーの求める機能とズレのない状態にしあげていくことが可能です。

僕たちの場合、カスタマーサクセスの担当が開発のデイリーミーティングに参加しつつ、開発担当してくださるエンジニアの疑問や相談にクイックに対応しつつ、合間合間でのユーザーへのヒアリング調整や本リリースにむけた検証調整などを行っています。

ちなみに、ユーザーからの声をポジティブな部分もネガティブな部分も積極的にシェアしてくSlackチャンネルの運用は個人的にやってよかったチャレンジの1つでもあります。特に機能改善に伴うポジティブなフィードバックは自分自身も、社内のかたがたにとってもモチベーションに繋がるのでこうした声を拾っていくのもCSのアクションとしてめちゃくちゃ重要かなと思っています。

画像4

We are Hiring!

ここまでつらつら書いておきながら最後は結局それかい、という感じかもしれませんがスマートドライブのCSはこのような思想を持って業務に取り組んでいます。実は僕はこの4月からスマートドライブのCS業務も持ちつつ、自分で会社を始めていまして、CSポジションでこうした領域を一緒に取り組んでくださる方をめちゃくちゃ募集してます。

個人的にこうした体験を今のスマートドライブの規模感でチャレンジできることはCSとしての幅を広げることにも繋がるはずで、CS経験のかたにとってもやりがいがあるのではないかなと思っています。
ぜひご興味あればTwitterなどでDMいただければ！

Day4のお知らせ

Day4はScalebase (※)を提供されているアルプの代表、伊藤( @itokin )さんが担当です！Scalebaseでチャレンジされている領域、個人的にはかなり興味があるのでブログも楽しみにしてます。

※Scalebase
商品・契約・請求管理オペレーションにおける複雑性を解消し精度の高い情報に基づいた、正しい経営判断を支援するサブスクリプションビジネス効率化・収益最大化プラットフォーム
https://scalebase.com/

---

おすすめの書籍

この1年間、プロダクトに関わるようになって、めちゃくちゃ自分の学びになった本を3冊ピックアップして終わります。ご覧いただきありがとうございました！


この記事が気に入ったらサポートをしてみませんか？