スタートアップ×CS立ち上げで大切にしている3つの思考
こんにちは！おがです。初noteです🙌
今回は【CS HACK Advent Calendar 2021】の12/13の記事として書いています！（皆さんの記事とても参考になります🥺）
拙い文章と内容ですが、最後まで読んでもらえるとうれしいです。
まずは自己紹介
ChompyのCSです
現在、株式会社Chompy(チョンピー)でカスタマーサポートを担当しています。
Chompyは【多様な食を多様に届け、「まいにちの食事」を、おいしく笑顔に。】をコーポレートミッションとして、「食」を軸とした事業「飲食店の公式アプリ/WEB無料開設サービス」と「フードデリバリーサービス」を展開しています。
僕は1人目のCSとして会社の設立半年くらいの時期にjoinし、CSの立ち上げを行なってきました。
スタートアップ×CS
今までは下記のような様々なドメインのスタートアップでCSに従事してきました。
ファッションECサイト
フリマアプリ
ライブコマースアプリ
チャットストーリーアプリ
仮想通貨関連アプリ
モビリティプラットホームアプリ
また、サブスクレンタルサービス、クリエイター支援サービス、業務効率化ツールなどのスタートアップ数社でCSのお手伝いをしたりしています。
CS HACKとの繋がり
完全に余談ですが、主催者の藤本さんとこんな話をしていた直後に立ち上がったコミュニティイベントのCS HACKの初期の運営お手伝いをしていました。当時はいろいろな企業さんのイベントスペースを借りながら毎月オフラインでリアル開催していたので、大変だけど文化祭みたいに毎回わちゃわちゃ運営していたのが懐かしい…笑
今年は久しぶりに登壇させてもらいました。
この記事について
今回はCS HACKのAdvent Calendarに参加するということで、今年3月に開催されたCS HACKに登壇した際にお話した内容を記事に再現しています。
主催者の藤本さんと同じ登壇者のカンムの平湯さんとその会のテーマについてディスカッションする中で、
・CSって複雑なオペレーションやってるよね
・サービスによっていろいろな制約やステークホルダーが複雑に絡み合っている中で、どうオペレーション作ってる？
・小川は0→1で作ること多いし、平湯さんはFintechの特有の複雑な既存オペレーションを解きほぐしながら効率化してるよね
と、最初から【オペレーション】をキーワードとしたコンセプトがサクッと決まり、藤本さんの素敵なセンスで「糸 あゝ、仕様とオペレーションが絡み合うこの素晴らしき世界」というイベントタイトルになりました。
（別案は「糸 - 仕様とオペレーションが織りなす布はCSを暖めうるのか」😊）
この時の登壇内容がオペレーションを軸としながらも、わりとCSを0→1で立ち上げる時に考えている(行っている)ことがメインになったので、本記事のタイトル通り、その視点で読んでいただけると幸いです。
💡ちなみにロジカルなナイスガイの平湯さんも素晴らしいnote書かれているので、ぜひご覧ください！僕も参考にさせてもらっています！
前提として
カスタマーサポートです
CSというと「カスタマーサクセス」を想起する方が多いかもしれませんが、本記事での「CS」は「カスタマーサポート」を指しています。
ChompyのCSについて
また、僕自身直近の数年はスタートアップでCS組織の立ち上げを行うことが多く、その中で大切にしている考えをまとめているのですが、本記事では現在所属しているChompyの事例を取り上げているので簡単にプロダクトの説明をさせてもらいます。
Chompyはフードデリバリーサービスです。
フードデリバリーはプラットフォーム側から見るとサービス内に、注文するお客さまのユーザー、料理を提供する飲食店パートナー、料理をお届けする配達クルーの3者がいるため、通常のサービスよりステークホルダーが多く、BtoC/BtoBまたはその中間の多様な要素が入り混じるサービスです。
Chompyのサポートチームは、1チームで全てのステークホルダーのサポートを行なっています。
また、Chompyでは他社のフードデリバリーサービスにはない「らくとく便」という独自の配達の仕組みで、「1注文・1配達」ではなく「まとめて注文・まとめて配達」することで持続可能な安さを実現する独自のUXを提供しています。
らくとく便：
ユーザーが1注文で複数店舗で複数商品の注文ができ、それを1名の配達クルーが複数店舗で複数商品をピックアップし中継地点に集約し、また別の1名の配達クルーが複数名のユーザーに配達するハブアンドスポーク方式の新しいフードデリバリーの仕組み
らくとく便は裏側のオペレーションは通常の配達より複雑性を増す一方で、より正確な配達時間を実現するため、CSにはこれらをリアルタイムでコントロールするという高いハードルが求められます。
その他にも、リアルにモノとヒトが動くというサービス特性上、どうしても様々なトラブルが発生してしまいます。
サポートチームは、そのトラブル時の対応含め配達時間や配達品質などChompyのUXを支えるサービス品質にコミットしているため、万一発生してしまったユーザーのネガティブ体験へのリカバリ体制やサービス改善を行うためのトラブル抑制のプロダクトフィードバックにも注力しています💪
立ち上げ期に意識している3つの思考
前置きがだいぶ長くなってしまいましたが、やっと本題です🙇♂️
スタートアップでは、CSに限らず立ち上げフェーズは非連続な成長を実現するために「限られたアセット」で「とにかくスピーディ」に「最大のインパクト」を出していくことが求められます。
そこで僕はスタートアップにおけるCS立ち上げ期のオペレーション構築では、下記の3つの思考(ポイント)を大切にしています。
👇 Chompyでの事例を交えながら解説していきます。👇
①プロダクト思考
「プロダクト思考」と書きましたが、要は「CSもプロダクトの一部と捉えて、プロダクトissueに向き合い、プロダクトの成長にインパクトの大きいことに注力する」ということです。
まずはKPIを例にとってみると、CSでは「問い合わせ率(を下げていく)」や「初回対応時間(を早くしていく)」や「一次解決率(を上げていく)などサポートならではの指標をKPIとして設定することは定石です。
もちろんこれらの指標は大切です。
ユーザーからしてみれば、問い合わせしなくてもサービスを利用できる方がいいし、問い合わせたら早く対応してくれた方がいいし、問い合わせた内容に対して早く解決してくれた方がいいのは当たり前です。
また、これらの指標が良くなればCSがいい仕事をしているとも言え、CSの健康診断にもなります。
ある程度プロダクトがPMFし、CSも対応品質に向き合うフェーズなら有効なKPIでしょう。
しかし、プロダクトがPMFする前の立ち上げフェーズにおいては、CS視点に限定せず、ユーザーがプロダクトを好きになって利用し続けてくれるための本質的なissueに貢献することに注力すべきだという考えを根底に置いて、CSも事業KPIに大きく相関性がありそれに貢献するKPIを設定すべきだと考えています。
そのためには、プロダクトのノックアウトファクターを把握し、それを排除するアクションをとり、その成果指標をCSのKPIとして設定します。
例えば、リリース当初のChompyでは下記のような事業KPIを設定していました。
・○月流入ユーザーの○回購入突破率の平均を○%以上にする
・らくとく便の○月流入ユーザーのWeekly RR＠○週目を○%以上にする
この事業KPIを達成するにはもちろん様々な要素(プロダクトのユーザビリティ、経済合理性、マーケティングなど)はありますが、KPI達成の大きな阻害要素のひとつに配達時のトラブル体験がありました。
CSはこれをノックアウトファクターと捉えて、トラブル発生率(を下げていく)をCSの最重要KPIとして設定しました。
前述したようにChompyではリアルにモノとヒトが動くというサービス特性上、様々なトラブルが発生します。
そこでCSとしてトラブル発生後の対応を行うのはもちろんですが、トラブル発生状況を分析し根本的にトラブルが発生しなくなるような改善アクションに注力することにしました。
トラブル種別を約40項目に細分化した上で集計・分析を行い、よりインパクトの大きそうなものに向き合い、オペレーション改善やプロダクトフィードバックを行いプロダクトチームと協業しながら機能開発を行なったりしました。
このように、CSだけで完結するものではなく、プロダクトに大きく影響を与えるべく全体最適のプロダクト視点で考えるといいかと思います。
また、重要度が高いissueに関しては、「オペレーションで頑張って防ぐ・改善する」よりも、早い段階から「プロダクトを良くするためにアップデートしていく」という考え方を持ちましょう。
②MVP思考
「MVP」とはMinimum Viable Productの略で、「顧客に価値を提供できる最小限の製品」のことで、リーン・スタートアップでも重要な概念です。
これはCSオペレーション構築においても活用できる考え方です。
具体的には「小さく、早く、泥臭く」、下記のようなことを意識しています。
例えば、CSでは効率的にオペレーションを行うために自社の管理画面を開発したり、オペレーション要件に合わせてSaaSのツールの細かい設定を組み上げたりしますが、初期フェーズは不確実要素が多く、何が正しいのかわからない状態です。
それに対してスクラッチで大きな開発工数をかけたりツールの設定工数をかけてしまうと、万一それの筋が悪かった場合、余分な手戻り工数が発生したり、またはサンクコストバイアスで筋悪いオペレーションを継続してしまう恐れがあります。
そのため、最初は最小限の工数で早く組み上げて細かくチューニングしていくのがいいでしょう。その結果、いい筋が見えてきたらその時点でルールや仕様を確定し仕組み化、機能化、自動化していきます。
ChompyのCSでは、複雑で多様なオペレーションを行う必要がありましたが、複雑が故にそれが最適なオペレーションなのかどうか見極めが難しいことが多々ありました。
そこで、オペレーションで使う管理画面は必要最低限の機能に抑えて、「(権限はある程度絞るが)Firebaseを直接操作する」、「監視業務に必要な項目はRedashとSlack botを組み合わせて可視化させる」「現場での集計・分析はメンバーが誰でも操作できるスプレッドシートに集約する(必要に応じてBig Queryと連動)」など、ありもののツールでサクッと運用するようにしていました。
現在は、確度が高くなった段階で管理画面に落とし込んで効率化を進めています。
また、トラブル原因や改善点のヒントはやはり現場に向き合うのが1番です。
インバウンドで対応するイメージの強いCSですが、実際に現場に出向き、その目で観察し、ステークホルダーにインタビューを行います。
③チームドリブン思考
スタートアップでは、立ち上げ初期は少ない人数でたくさんのタスクをこなさなければいけません。メンバー1人ひとりが多くの個人作業を行わなければいけない状況ではありますが、前述した通り不確実要素が多く、何が正しいのかわからない状態では、個人で進めていたものをつけ合わせてみると合わなかったということが往々にして発生します。
また、厳しい局面も非常に多いので1人で戦っている感覚が続くと気持ちが折れてしまうかもしれません😫
そのため、根底の部分でもメンバー同士の熱量・思い・考えが擦り合っていてチームとして信頼関係が構築されている、またそのチームで進んでいく・戦っていく共通認識を持つ必要があると考えています。
まずは信頼関係と共通認識を醸成する。そのために非効率でも口頭のコミュニケーション(できれば対面)を大切にしています。
これが進んでいくと、メンバーが自然とオーナーシップを持つようになります💪
Chompyはサービスの営業時間が長いかつ、リアルタイムにCSがサポート対応をおこなわなければいけないため、一部の業務をアウトソースしていますが、同じCSチームメンバーとしてコミュニケーションをとっています。
最後に
「プロダクト思考」「MVP思考」「チームドリブン思考」
まるでどこかのスタートアップのValueみたいですね。(自分では結構気に入ってます 笑)
会社、プロダクトドメイン、規模感、アセットなどが違えばもちろん取るべきアプローチも変わってきますが、ここで書いた3つの思考は抽象化するとわりとスタートアップであればどこにでも活用できる考え方なのではないかなと思っています。
これから誕生する、もしくは今まさに壁にぶち当たっている立ち上げ中のCSチームの方々の参考になればうれしいです😊
そしてChompyではCSはもちろん、いろいろな職種で積極採用中です💁♂️
カジュアルに意見交換したい方もぜひ！
最後までお読みいただきありがとうございました！
それでは、皆さんまた〜👋
この記事が気に入ったらサポートをしてみませんか？