Stailerのサポートの価値を考え続けた半年間 ~チームで見つけたある答え~
この記事は 10X 創業6周年アドベントカレンダーの17日目の記事です。
昨日は、エンジニアリング本部のkosakoさんのアンラーニングのススメという記事を公開しています。（勉強になりました）
ちなみに社内では「kosakoさんはksakoさんだから」というキャッチフレーズ（？）で親しまれています🫰
はじめに
メンバー紹介
現在、10Xのサポート部には僕含め3名のメンバーがいます。
以前からそれぞれ関わりがあった3名が10XにCSとして集結し、ネットスーパー・ネットドラッグストアのサポートに日々向き合っています。今後、どうぞお見知りおきを。
ugazin
2021年12月に10X入社。サポート部の部長。
現在の10Xサポートの基礎を作ってくれた人。
去年末のアドベントカレンダーで公開した入社エントリ↓
oga
2022年8月に10X入社。ugazinのリファラル採用。記事を書いている僕。
去年末のアドベントカレンダーで公開した入社エントリ↓
おかえり
2022年11月に10X入社。ugazinのリファラル採用。
TOP画像のコラ画像の人。笑顔しかできないパワフルなルーキー。
今回のアドベントカレンダーで、11日目の記事を公開しています↓
この記事について
本記事は、CSに関する知見を提供したり、実用的な事例を紹介することを目的としていません🙇♂️
サポート部のチーム3名で模索しながら「私たちなりのあるべき姿のひとつ」を見つけた記録です。
まだ運用中なので、日々ブラッシュアップし成功体験を積み上げた先に、いつか自信を持ってベストプラクティスと言える時がきたら体系化してご紹介できればと思っています。
（なので、仰々しいタイトルですが、気楽に読んでもらえると嬉しいです・・・）
CSの土台作りを経て
サポート部は3名と紹介していますが、実は初期CSの立ち上げから長らくは、現在PdMとして活躍されているaineさんが1人で担当されていました。（CS経験を活かし、昨年PdMに転向されました）
その後、現部長のugazinさんが加わり、2名体制で10XのCSの礎を築いてきました。
10Xが提供しているStailerは、スーパーマーケットやドラッグストア事業者様（以下、パートナー）にネットスーパー・ネットドラッグストアのシステムをオールインワンで提供するプロダクトですが、パートナーのお客様であるエンドユーザー様（以下、カスタマー）が注文時に使用するアプリも提供しているため、サポート対象はパートナーとカスタマーとなります。いわゆるB to B to C事業。
立場の違う事業者側のパートナーと消費者側のカスタマーを同時にサポートするため、問い合わせ内容やイシュー、対応方法がそもそも違っていることもあれば、実はつながっていることもあり、とにかく複雑な問題が多く、ワークフローとして型化するのはとても大変です。
また、プロダクトとしての複雑性から仕様把握すらも困難で、お問い合わせをいただくたびにエンジニアやPdMに都度仕様を確認し、パートナー対応ではBizDevも巻き込みながら、まさに総力戦でサポートをおこなうような状況でした。
この2人はそれぞれ役割分担をしながら、”お客様の課題を解決し、プロダクトとのギャップを解消する”をミッションに、そんなStailerサポートの土台を着実に作り上げていました。
詳細はこちらで読めます↓
主にこんなことをおこなっていました。（これを2人で作り上げるのは、、
つ、つよい…🥺）
Customer Support
お客様がStailerで提供するサービスを使いたいように使えるようにする
パートナーが満足する（店舗に負担のかからない）カスタマーサポート体制を構築する
カスタマーから得たVOCをプロダクトフィードバックし、改善サイクルを回していく
データに基づいた改善サイクルを回していく
Partner Support
パートナー企業がStailerを安定して運用できるようにする
複数パートナーのオペレーションをサポートする横串体制を構築する
ローンチ前フェーズとローンチ後の運用フェーズでのサポート連携を強化する
現場（店舗）からのインサイトを抽出し、プロダクトフィードバックをおこなう
Stailerのサポートの価値を考える
僕が10Xに入社した頃には、すでにCustomer SupportとPartner Supportのそれぞれの土台は出来上がりつつあるフェーズでした。
ちょうど同じ時期にaineさんはPdMにロールチェンジされたため、それらを引き継ぎブラッシュアップする動きをとっていました。
CSだけで見ると日に日に問い合わせ対応のワークフローは型化が進み、ナレッジもストックされていき、プロダクトフィードバックの仕組みもできて前進していました。
しかし、それよりも速いスピードで10Xという会社、Stailerという事業は前進しているため、問題も多く発生していきます。
10Xメンバーが増えるので・・・
複雑なプロダクト仕様のため、Stailerについての知識格差が広がる
知識や情報の属人化が進むようになる
情報を得るためにコミュニケーションコストがかかるようになる
プロダクトが進化するので・・・
開発が進みリリースが多くなるにつれて、仕様に関するドキュメント（社内の仕様書やパートナー・カスタマーに提供しているガイドなど）の作成や更新が追いつかなくなる
開発人数が増え、仕様確認や不具合改修などを誰に依頼すれば対応できるのかわからない状態になる（聞けばわかるが、確認に時間と手間がかかる状態）
パートナー数が増える・要望レベルが上がるので・・・
問い合わせ数も増える
少なからず存在する個社仕様の違いが増え、対応の型化の難易度が上がる
運用フェーズが進むにつれて、要望や質問の難易度が上がる（確認にかかるコストが上がる）
カスタマー数が増える、カスタマー層が広がるので・・・
問い合わせ数も増える
問い合わせ内容の難易度が上がる（確認にかかるコストが上がる）
サポート部も社内も体制は強化され、着実に前進しているはずなのに、常に課題にぶつかっている状態でした。
そのようなタイミングで、おかえりが入社してきてサポート部としての駆動力は格段に上がるのですが、やはり非効率な中でひたすら来た球を打ち返すような感覚が続いていました。
たどり着いたある答え「社内ヘルプ」
前述した状態は具体的にはこのような状況です。
BizDevメンバーが直接パートナーからStailerに関する質問を受けて答えられない場合、仕様に関する質問先が明確にわからない状態だったので、社内のSlackのいろいろなチャンネルでいろいろな関係者に広めにメンションでの質問が飛び交う
社内で非効率にコミュニケーションコストが増加していく
多くのメンバーのマインドシェアが取られてメインタスクに集中できない
社内のSlackのいろいろなチャンネルで有象無象に一問一答が繰り広げられるので、知見がストックされない
ガイドや仕様書などドキュメントが更新できない
また別のメンバーから同じ質問が飛び交うループ
ナレッジ化されないでの、サポート部としてパートナーやカスタマーからの問い合わせ業務の型化が進まない
問い合わせに回答するための情報を得るために、膨大な社内ドキュメントやSlackの過去コメントの検索に都度多くの調査コストがかかる
その結果、回答・解決するまでの時間が長くなり、パートナーやカスタマーを待たせてしまいUX棄損に繋がる
時には誤った回答をしてしまうことも…
このような状態に強い危機感を持っていたサポート部では、チーム3名に加えて近しい領域を担当するサクセスオペレーション部と協業し、ある答えを導き出しました。
それが「社内ヘルプ」機能をサポート部で運用していくことでした。
Stailerに関する質問をサポート部に集約することによって、上記の課題を解決でき、その先にはサポート部の業務効率化だけではなく、以下も達成したいという思いもあります。
要するにCustomer Support、Partner Supportだけでなく、Employee Support (エンプロイーサポート) をおこなうことで、事業全体にレバレッジが効くと考えました。
BizDezメンバーやプロダクトメンバーの非効率な時間を削減する
メインミッションに向かう時間を最大化する
事業成果に直結する
ローンチフェーズのパートナーのオンボーディングを効率化する
ナレッジベースを充実させることにより、オンボーディングコンテンツへのフィードバックをかける
パートナーやカスタマーへの価値提供を最大化させる
ナレッジベースを充実させることにより、お問い合わせ回答スピードと精度を向上させる
ガイドのクオリティが向上し、自己解決を促進する
ちなみに、社内ヘルプの立ち上げで協業したサクセスオペレーション部がどんなチームなのかは、部長のkikuchiさんが公開している記事をご覧ください↓
「社内ヘルプ」としての価値発揮
では、「社内ヘルプ」として実際に何をおこなっているのかを紹介します。
端的にいうと所謂「社内のヘルプデスク」機能です。
社内でStailerプロダクトに関して困ったことや不明点があれば、「サポート部に問い合わせをしてもらう→回答する→必要に応じてガイドに反映させる」というシンプルなサイクルです。
その中でも少し工夫しているポイントがあります。
まずは社員もガイドを参照してもらい、わからなければ問い合わせてもらう
当たり前かもしれないですが、まずは自身でナレッジベースを確認してもらいます。
ここでこだわったのは、社内のナレッジベースではなくあえて「パートナーに提供しているガイドを参照してもらい、その中に社員専用の問い合わせフォーム導線を設置する」ことです。
この狙いは以下の通り。
パートナーにどのような情報を提供しているか社員に把握してもらう
それによって、誰でもパートナーに同じ粒度で説明できるようになる
パートナー向けガイドにフィードバックがかかる
パートナーに提供しているガイドを見てもわからないことがあるということは、パートナーに提供している情報が不足しているということ
社員からの問い合わせ起点で、同時にそれも検知でき、ガイド内容のブラッシュアップにもつながる
なお、副次的だが、最近は社員がわからなかったことだけではなく、「ガイドを見ていてxxxの情報が足りないと思うので追加お願いします！」というようなアクティブなフィードバックももらえるようになった
社内で発見した軽微な不具合も問い合わせ経由で報告してもらう
仕様についての質問だけではなく、社内で検知した軽微な不具合も前述のガイド内のフォームから問い合わせをしてもらうようにしています。
それによって、サポート部で仕様との付け合わせ確認、再現確認の検証、必要に応じてQAとの連携、エンジニアへの改修依頼、関連した問い合わせへの対応、新たな仕様の発見などでガイドへの反映などが効率的に回るようになります。
もちろん、重大かつ緊急性の高いケースはこのフローに限らない場合もあります。
問い合わせ導線をガイドに集約する
今までは、困ったらまずは気軽にサポート部に聞いてほしいという目的で問い合わせ専用のメンショングループを作成してSlackでメンションしてもらい受け付ける運用も試していましたが、「ステータス管理ができない」「Slackチャンネルが分散して対応漏れが発生する」など課題が残りました。
そこで、ひと手間かかるかもしれないですが、ガイドの問い合わせフォームに集約することでこれらの課題を解決するととも、「ガイドを見てもらう習慣づけ」や「回答内容をガイドに反映する」という前述した内容とも関連するサイクルに繋げられます。
貯まった知見をもとに仕様書にもフィードバックをかける
基本的にパートナー向けガイドをナレッジベースとしているのは前述の通りなのですが、ガイドのもとになる情報は社内ドキュメントの「仕様書」です。
仕様書にはガイドに掲載するまでもないけど、ガイドを作成する上で必要な細かい粒度の仕様情報、ユーザーストーリー、開発背景やプロセスなどが記載されています。
仕様書に関してはPdMが管掌しており、アップデートがかけられていますが、PdMもやりたいことに対してリソースが足りない状況のため古い情報が残り現状の仕様と乖離があったり、実装されている仕様に対して情報不足な場合があります。
そこにサポート部からフィードバックをかけて最新情報にアップデートする動きも始めました。以前よりもPdM との連携が強化されている状態です。
PdMについての記事も置いておきます↓
問い合わせが来たらSlackで通知させる
ガイドや社内ヘルプの問い合わせフォームにはZendeskを使用しており、フォームに入信がありチケットが作成されたら、Slackの社内ヘルプ専用チャンネルに通知がポストされるようにインテグレーションしています。
それによって、リアルタイムにサポート部が検知して対応できるとともに、問い合わせたメンバー以外の社内メンバーにも広く問い合わせ内容と回答内容をオープンに公開できています。
日々上記のようなフローで社内ヘルプを回しているサポート部ですが、この活動をおこなう上で、やはり仕様に詳しくなることがとても重要です。
そのために部内で毎週「仕様書勉強会」という仕様に詳しくなる活動時間を設けています。
やり方はいろいろと試行錯誤の末、講師担当を毎週持ち回り制にして、「講師担当メンバーが事前に仕様書やガイドを読み込む→サポート部内に講師として講義する→講義を受けた生徒役メンバーは質問をする→新たな発見や解決できなかった疑問をPdMやエンジニアに確認する→ガイドや仕様書にフィードバックをかける」という形に落ち着きました。
さらにサポート部の活動に興味を持ち自主的に生徒役として参加してくれる社内の他部門のメンバーも現れてきて嬉しい限りです。
そして、もちろん社内ヘルプのパフォーマンス測定やKPI管理もおこなっており、開始半年で成果を実感しています。
定量的にも成果が出始めているのですが、社内メンバーからの嬉しいコメントから定性的にも成果を感じています！実は個人的にはこちらの方が嬉しい！
一部のコメントを紹介しますが、嬉しさのあまりたくさん掲載してしまうのでお付き合いください笑
次の答え探し
現在進行形で社内ヘルプとしてのファンクションをブラッシュアップしている最中ですが、サポート部として「社内ヘルプ」だけがStailerサポートの最適解だとは思っていません。まだまだ価値提供できる形はあるはず。
そこで10Xサポート部は隔週で「CS未来会議」なるプチオフサイト的な時間を設定していて、対面で数時間ほど日頃の業務とは脳を切り替えて、中長期的な視点でStailerサポートの課題、あるべき姿、可能性について議論しています。
「隔週で数時間ってちょっと多くない？」と思うかもしれませんが、常に未来を考えていないとまた取り残されてしまうので、10XとStailerのスピード感を考えるとこのくらい必要です。
これは10Xが掲げている10X VALUESの中のThink 10xに則っておこなっています。
Think 10x
「理想の未来」から考えよう
「探索的な一歩」を重ねよう
これからもStailerのサポートとして発揮できる価値を探求していくつもりです。
おわりに
このような10Xサポート部ですが、もちろんサポートチームだけで仕事ができるわけではなく、さまざまな部門の多くのメンバーと一緒にStailerを作り、パートナー様のネットスーパー・ネットドラッグストア事業を支援しています。
ということで、10Xではメンバーを募集しています！
ぜひ採用ページもご覧ください。
明日は、コーポレートオペレーション部のmanaさんが記事を公開する予定です。お楽しみに👋
この記事が気に入ったらサポートをしてみませんか？