SaaSのカスタマーサポートを立ち上げた話
ある日、ビッグボス @3sykとの1on1 で、「STORES レジ 」のカスタマーサポート立ち上げてから半年以上経ったな〜、という会話をしていました。
その中で「それnoteに書いたら…」とささやくような声で投げかけをもらい、今回の経験をとおして得た、SaaSプロダクトのカスタマーサポート立ち上げについての ”自分なりの理解” を、震えながら書いてみました。
この記事はこんな方向け
■ SaaSプロダクトのカスタマーサポート1〜2人目
■ これからSaaSプロダクトリリースに関わる方
■ VOC（Voice Of Customers）を源泉にプロダクト開発をしていく方針のもと、これからカスタマーサポートメンバーと協働する予定がある方
はじめに
幸いなことに、現在携わっているプロダクトのカスタマーサポートとしてはスムーズな立ち上がりができました。そこで、この文章では、自分なりに重要な分岐点だったのではないか、と思う要素をカスタマーサポートの視点から書き起こしています。
これまでカスタマーサポートの経験はあるにせよ、私にとってはこれがはじめての「SaaSプロダクトの」カスタマーサポート立ち上げです。
「はじめから意図して順調にできたぞ〜」と言えたらかっこよかったか…とも思いますが、そうではありませんでした。
だからこそ、これからプロダクトリリースを迎える方には、よりよいスタートが叶いますようにという願いを込めて、したためてみることにしました。
はじめまして。hey（ヘイ株式会社）という会社でカスタマーサポート業をしています、ひやしみず と申します。
STORES レジ とは
世の中に、ネットショップと実店舗の両方を運営する小売店オーナーさんが珍しくなくなって久しい現在、「ネットショップと店舗の商品・在庫データをそれぞれ管理する煩雑さ」という課題が存在しています。
私が現在携わっている「STORES レジ」は、このような課題の解決を目指した、ネットショップサービス由来のPOSレジシステムです。
heyでは、中小企業や個人事業者のオーナーさんがこういった煩雑さから解放され、より大切にしたいことに集中できるよう、2021年6月15日に、実店舗もネットショップもまるっと管理できる、無料のレジアプリ「STORES レジ」のリリースに至りました。
※heyは、STORESプロダクトをご利用いただくお客さま（ストアオーナーさま）のことを、親しみと敬意を込めて「オーナーさん」と呼称しています
リードタイムに恵まれて
話を戻します。私が「STORES レジ」のプロジェクトにカスタマーサポート1人目として参画したのは、リリース予定の4ヶ月も前のことでした。
（それまではネットショップ開設サービス「STORES」のカスタマーサポートをしていました。）
当時はっきりとは認識できていなかったことですが、正しく表現するならば、
「幸いなことに！4ヶ月も前に！カスタマーサポートメンバーを？！
プロジェクトに！呼んでもらえた…！」
です。
（早くに呼んでくださったのは当時のプロダクトオーナーのあやさん@ayanadesuです。感謝しかないです、、本当にありがとうございます。）
いま振り返れば、カスタマーサポートが、プロダクトリリース前の早い段階でプロジェクト参画し、未来の利用オーナーさんを助けるために必要なリードタイムに恵まれたことは、プロダクトの「信頼」を積み上げていくスタートを切る上でとても重要なポイントだった、とわかります。
それがわかったのは、直近 2ヶ月のC-Sat（顧客対応満足度）平均95％という、高評価結果を目にしたことがきっかけでした。
※C-Satは、サポート対応の都度にお客様への満足度評価アンケートを依頼し、回答いただくことで確認できる指標です。
ユーザーがいかに安心してプロダクトをご利用いただけているかという一つの指標でもあり、一般的には80〜85%を超えると優良パフォーマンスとなる指標です。
振り返ると、リリース後半年ほどのタイミングでこのような高評価に到達できたのは、リリース時点で以下のような状態を作れたからでした。
●オーナーさんが必要な情報にアクセスできる環境の用意ができていた
（ヘルプ記事を数十個程度ではなく、カスタマージャーニー上で起こりうるひととおりのQ&Aを100記事くらいで用意。）
●オーナーさんが自己解決できないときのセーフティネットを用意できていた
●カスタマーサポートメンバーがプロダクトをよく理解していた
●「問い合わせ対応にかかりっきりで社内へのVOCフィードバックがおろそかに…」というありがちな状況にならない体制でスタートを切れた
●不具合・障害発生時のフローが決まっていて、問題解決プロセスに混乱や無駄が少なく、スピーディな対応ができる体制だった
●受け止めたVOCは淀ませず、鮮度高く毎週フィードバックをおこなうことで、スピーディーにプロダクトが改善されていった
そして、突き詰めて考えればこれらはすべて、「カスタマーサポートメンバー”も”、プロジェクトの一員としてリリース前に仕込み期間を持てた」という要素に集約されます。
ゆえに、カスタマーサポートがリリースの前段階でプロジェクト参画する意義は、おおいにあったと思っています。
自分自身は過去カスタマーサポートとしての経験はあっても、SaaSプロダクトのカスタマーサポートをゼロから立ち上げた経験はこれがはじめてでしたが、聞けば、リリースのこんなにも前（4ヶ月前）からカスタマーサポートメンバーがプロジェクト参画して体制を整えるケースはそんなに多くないのだということを知りました。
リリース直後から、カスタマーサポートが破綻することなく機能し、順調に立ち上がった要因としては、努力だとか工夫というよりも、リリース前の早い段階でプロジェクトに参画できた「タイミング」、この一点に尽きるのではないかとさえ思っています。
リリース前にやったこと
特殊なことはやっていないですが、前談のとおりリリース前「早い段階で」とりかかれたことは功を奏したのではないかと思っています。
時系列を追って書けば、カスタマサポートとしては（1名で）、以下のようなことをやっていました。
＜3〜4ヶ月前＞ 主にWhy/Who/Where/When部分をインプット
●プロダクトがうまれようとしている課題背景を知る
●STORESレジが目指すことを理解する
●POSレジ外部環境を知る
●（コロナ渦につき）フルリモートでリリース前のプロダクトにアクセスする環境を整備
●ヘルプページのツール選定議論
●仕様関連ドキュメント類の読みこみ
●カスタマージャーニーごとに想定される疑問・問題の洗い出し
●エンジニアチーム、PdMと共同で、Q &Aごとの正しい仕様情報などを延々と確認
●カスタマーサポート体制づくりのWBSつくる
＜2ヶ月前＞ 主にWhat/Howに取り組む
●情報が揃ったコンテンツからヘルプ記事を作りまくる
●ヘルプページ作成にあたっての担当デザイナーアサイン相談
→コンテンツを作ることができても、ヘルプページのUI、その実装まわりまでは自分で完結できないので、ここはデザインチームを頼りました。
●問い合わせチャネル設計と準備
●テスト版アプリを手元で使い、具体的な仕様を理解
＜1ヶ月前＞ 主にWhat/How の具体詳細に取り組む
●FixしたUIからヘルプ記事用の画面キャプチャなどを取得
●この頃から出社してハードウェア系周辺機器に触れ、iPadとの接続でつまづきそうなポイントをつかむ
●ヘルプ記事100こほど、PdM・エンジニアにレビュー・修正の繰り返し
●のちに合流するメンバー2名の迎え入れ体制準備
●問い合わせ対応環境に最低限必要な参照用データベースの改修依頼
→問い合わせ対応をはじめるうえで重要なアジェンダの割に、気付いたのがリリース直前でした。エンジニアチームに影響がある項目のため、理想としては2ヶ月くらい前にはアジェンダとしてあげておくべきものだった、という反省点がありました。
●障害や不具合発生時のフロー・各チーム役割のすり合わせ
リリース後と、いま
2022年2月現在、「STORESレジ」リリース後から約8ヶ月が経過しました。
そして、ありがたいことに日々お問い合わせでいただくご意見・要望は、しっかりと開発チームに鮮度高く届けることができていて、これを源泉に、スピーディなプロダクト改善・開発が行われています。
一方で、現在に至るまでの初期においては、問い合わせ量自体が、定量化するほども多くない期間が一定存在し、このタイミングにおける「定量」情報が、果たして拠り所として足り得るのか、難しい段階が続いていました。
また、そのような期間を経たことによる次のような気づきもありました。
定量情報が必要である前提は変わらないとしても、初期段階のSaaSプロダクトにおいては、相対的には定性情報のほうが、原動力になっているのかもしれないということです。
週に一度の、エンジニア／PdM／デザイン／マーケ／オンボーディング／サポートが一同に集まるVOCミーティングの場所で、文脈や背景をもって「再現性あるペイン」を私たちに気づかせ、理解と具体改善を促してくれるのは、いつも定性情報だからです。
（とはいえ、後から定量的変化の推移を振り返ることができるよう、問い合わせ情報の定量化も継続していました。）
そしてこのように、見落とされるべきではないと感じる、”オーナーさんを理解するための機会”や、"見えてなかったことを教えてくれる声"が、初期段階の定性情報にはあまりに多すぎると感じます。
ゆえに、いまこの初期段階においては、「問い合わせ対応の直接的な自動化」や「お問い合わせ数の抑制」のような、効率化の観点で有効な施策の持ち込みは、時期尚早さが否めず、その発動時期はもうすこし見極めたいな〜と思っているのが現在の正直なところです。（これが正しいかは、まだわかりません。。）
カスタマーサポートがプロジェクトに早期参画するメリット
前談までのとおり、カスタマーサポートメンバーがプロダクトリリース前に早期参画したことは、思いのほかその後の運営をスムーズにすることに寄与しました。
改めて、そのメリットを書き出すと以下のとおりです。プロダクトにとっても、オーナーさんにとっても、いいことばかりです。
リリース後、お問い合わせ対応以外にも、有益な時間投資ができる
（たとえば）お問い合わせ対応にとどまらず、アカウント登録前（検討）〜利用開始〜運用段階に至るまでのジャーニー一環で、オーナーさんへプッシュ型のヒアリングコミュニケーションができた
ハイペースな開発を支える源泉、定期的なVOCフィードバックのための時間をしっかり持てた
お問い合わせで発生する機能要望のカテゴリーに関して、分類の切り口をPdMと協議できた（以後そのカテゴリーで分類した機能要望をレポートしています）
仕込みをしておいたヘルプページが、リリース後はチームの同僚となりサイレントなオーナーさんを助けてくれる
改善サイクルが早期にまわり、プロダクトとオーナーさんの信頼関係構築の足がかりとなれた（継続利用オーナーさんが増加）
今後、プロダクトリリースを迎える予定がある方に、このような効能があったことが、僅かばかりでも参考になれば幸いです。
また、状況がゆるすようなら、リリース前段階からカスタマーサポートメンバーの1人目がプロジェクトに加わることも、ぜひおすすめしたいです。
おわりに
「お問い合わせ」にはオーナーさんの本音がふんだんに含まれている。
私はそう思っています。外からのはたらきかけに対して反応をしているのではない、「自ら任意のタイミングで話しはじめる」ことに本音があらわれる、と常々感じます。
そういった意味でカスタマーサポートには、組織の中で相対的に受け止め型の、やや特殊な存在であるがゆえにキャッチできている唯一無二の情報の集まりがあると考えています。だからこそ、そこで受け止めた声は淀ませずに、ちゃんと社内に還流することも、カスタマーサポートの大事なミッションです。
SaaSプロダクトの初期段階では、ユーザーの眼前に起こっている、疑問や要望・問題を抱えるに至った「文脈」「意図」「感情」といった数字以外の事実にも目を凝らさない日はないはずで、そういうときこそが、わたしたち、地味なカスタマーサポートの真価の発揮どころではないか、という想いを胸に、今日も今日とて、オーナーさんの声に耳を傾け続けています。
お知らせ
heyでは、多くの職種において新たな仲間を募集しています。（カスタマーサポート@仙台も募集しています。 iOSエンジニアさんも募集しています！他にも…）エントリーをお待ちしています！
よかったらこちらもどうぞ
カスタマーサポート以外の視点からみた「STORESレジ」誕生についても、これまでに素敵な記事がかかれています！よかったらみてください😃
#SaaS
#カスタマーサポート
#立ち上げ
#やってみた
#CS
#テクニカルサポート
この記事が気に入ったらサポートをしてみませんか？