CSの定量と定性

CSはユーザーと会社の間に立つ事が多いため、関係各所への報告や相談が多いのですが、どういった内容を行うのが望ましいのでしょうか。

報告＆相談内容の内訳としては「問題の概要」「量」「対策案」などが多いと思います。しかし、それぞれの粒度は事前にフォーマットを定めてない限り、案件毎にブレが生じやすいものだと感じます。

なぜ、ブレが生じやすいかはCSという業務に起因しています。
前述の通りCSはユーザーと会社の間に立つ事が多いですが、ユーザーの熱量が高いと感じると量を無視した定性的な報告をしがちになるためです。

同時に局所的に量が多いと感じた場合も量を定性的に誇張した表現で報告してしまう場面をみた事もあります。

この記事のトップ画像は内容が青い瓶が並んでいますが、この画像をもう少し引きで見ると以下の画像になります。

100%だと思ってた青色は実は50%ほどで、さらに引きで見てみるともしかしたら50%にも満たない可能性も考えられます。
しかし、トップ画像にしか触れていないCSは

えらい人「最近どんな問い合わせが目立つの？」
CS「青しか来ないですね」

といった報告をする可能性があり、これでは改善優先度などの判断を誤る危険性があります。

では、全ての量や内容を完璧に把握してそれを全て報告しなくてはならないのでしょうか？

正解は難しいですが、どこまでが定量でどこからが定性であると良いのかについて考えてみます。

報告の目的は？

何をするにしてもまず大事なのは目的だと思います。様々な場面によって必要な報告の内容や粒度は変わってきます。

ひとまず簡単な概要の共有を求められている会で全ての内容や量をこまめに説明してもナンセンスですよね。

では、それぞれのミーティング毎に報告内容を作成しなくてはならないのか？と考えるとこれもちょっと大変そうです（勿論個別作成しないといけないミーティングも存在します）

となると「事前に粒度が異なる報告を出来るようにしておく」のが良さそうです。

- 問い合わせの内容と割合
- 対応コストとチームのリソース
- 上記2項目それぞれに発生している問題
- 問題に対して今取り組んでいる施策

これらを用意しておけば、ひとまずの会話にはなると思います。

全体の量を把握する

何をするにしてもまず全体の量がわからないと、前述のように局所的に物事をみて、誤ったり偏った報告をしてしまう危険性があります。

1日の問い合わせ数、その問い合わせの内訳の割合、1日に行っている返信数、スタッフ事の返信数、案件の解決数、2報目以降まで解決しなかった数、どの問題が2報目以降までの解決しない事が多いのか、解決までの時間は…etc

などなど、個別に掘り下げると無限に出てきますが、CSの管理者としては最低でも、1日の問い合わせ数、その問い合わせの大まかな内訳割合を雑で良いので頭に入れとくのがスタートラインな気がします。

問い合わせの内容と割合の把握ですね。

問題をカテゴライズする

問い合わせの内容と割合を把握すると言っても、割合を把握するためには、内容をカテゴライズする必要があります。
では、どの粒度で内容をカテゴライズすれば良いのでしょうか。

理想としては問い合わせの対象になっている「問題」とその数をツリーなどを使用して出来るだけ細分化して階層的に把握が出来る事です。
しかし、サービスの規模やそれまでの計測の仕方によっては精緻な情報をすぐに出すのが難しい場合もあります。

という事で、何も無い状態からの始め方としてオススメなのは、少しずつカテゴライズしていく事です。

何か決済が関わるサービスがある場合は「決済」というカテゴリを作成し、他のものは「その他」に入れるというぐらいの運用から初めても良いかもしれません。最初はそれぐらいから初めて少しずつ、正確にカテゴライズできるもの（正確に定義するもの）を増やしていく方が混乱が無さそうです。

そして「その他」にある数の多い問題を順にカテゴライズしていくと、さらに全体感がわかってきそうです。
また、必要に応じて作成済のカテゴリをさらに階層化したりを繰り返していく事でも詳細な状況が掴めてくると思います。

カテゴライズするうえで気をつけなくてはいけないのは「問題の種類」をカテゴライズするのであって、ここに「クレーム」「感謝のお言葉」のようにユーザーの熱量や満足度的なところを混ぜてしまうと「問題の種類」でMECEになりません。

上記を把握する事も重要ですが、まずは「問題の種類」をカテゴライズするところから始めましょう。切り分けた「問題の種類」に対してユーザーの熱量などの別要素はフラグやタグで紐付け出来ると良さそうです。

こうすることによって、発生しているどの問題に対して、ユーザーの熱量が高いかも集計可能になります。

コストとリソース

上記でカテゴライズした問題にどれぐらいの対応時間をかけているかで、対応のコストが測れます。もし、対応が追いついていない場合は1件あたりどれぐらいの時間がかかるかであったり、1時間でどれぐらい処理出来るかを分析する事で、想定されるコストがある程度測れます。

リソースはチームが使用出来る対応時間です。ここで注意しないといけないのは、可処分時間を想定して考える事です。多くのケースではスタッフは1日8時間の労働で契約していると思われますが、様々な要因で実務が出来ないアイドルタイムが発生します。

そのため、1件の対応時間は何分みたいな計測の仕方をすると実際とはズレる事が多いです。素晴らしい測定ツールなどを用意している訳でも無い場合は、1時間〜1日程度の枠組みで考えた方が計算はズレない事が多いです。

上記を複合的に考えて、現在のコストとリソースの状況を把握している必要があります。

定期的に観測する

全体の量、問題数、コスト、リソース、これらは簡単に集計出来るようにしておき、定期的に観測する必要があります。

当たり前ですが、1ヶ月前の情報を報告して現在の数値と極端に異なるのであれば、その報告に意味が無くなってしまうからです。

また、例えば既存会員のDAUに起因して問い合わせが増えるのか、新規会員数に応じて増えるのかなどの因果関係を併せて分析したいところです。

その因果関係によって対応する問題の優先度が大きく変わるため、どの数値にどんな因果関係があるかを把握するのはとても重要です。

大きなところから報告する

ここまでくると全体の量から、何が主に発生しているのか、それに対してどれぐらいのコストがかかっていて、チームのリソースは足りているのか、今後のDAUや新規会員数の増加が発生しても対応は問題無く出来るのか、などの状況が把握出来ていると思います。

しかし、これらの情報はCSが苦労して積み上げて蓄積した情報であり、この段階ではCSのみが把握している情報です。

報告する順序を間違えると、報告をうける人から見ると最初に例として出した「青しか来ないですね」に見えてしまう可能性もあります。

そうならないためには、以下が出来ると良さそうです。

- 問題数のツリーは社内に共有する
- 報告の際にはツリーの上から報告する
- 困ってない事、関連しない事、聞かれてない事は報告しない

なぜ、局所的な誤解が発生してしまうかは全体の前提が合っていない状態で会話が進んでしまうからなので、報告する際には一番上から報告するのが吉です。

その際にツリーもみてもらいながらするとより誤解は少なくなると思います。また、余計な情報は出来るだけ少ない方が解釈に誤解は発生しづらいのでシンプルに報告出来るように心がけます。

ここでCSの報告はどこまでを定量で、どこからは定性かというところに立ち返ると「全体の量は〇〇、量を把握出来ている範囲は〇〇までで、〇〇の量やユーザー熱量の測定は出来ていない」というのが相手に伝わる状態で報告出来るのが良いのでは無いでしょうか。

となると、把握している範囲の情報を正確に伝えるという、何か当たり前の結論にも見えますが、当たり前に把握しておかないといけない数字も見えた気がするので、このnoteを書いて良かった事にします。

本質的な改善を考える

最後に…本質的なのはカテゴライズした問題の解決策を考える事です。
CSに求められている事は問い合わせを綺麗にカテゴライズして報告する事では無く、問い合わせに返信しつづける事では無く、その問題の解決をするためのアクションをしていく事だと思います。

そして問題が解決したかどうかは、作成したカテゴリの問い合わせがなくなる事で測れます。これが成果であり、サービスが前進している事の証明になるかと思います。

そういった観点で日々カテゴライズし、分析、解決へのアクションをしている場合はおのずと苦労せずに状況報告出来るようになると思います。

なんかめっちゃ自分へのハードル上がるnote書いてしまった気がするなぁ…

・・・

宣伝

長文見ていただいてありがとうございます。そして宣伝です。
現在noteではCSメンバーを絶賛募集中です！
我こそはな方はお気軽にご連絡ください！

さらに宣伝です。私趣味でベース弾いたりしているのですが、先日音源がリリースされたので、ぜひ聴いてみてください！
（noteにバンドのページを作ってみました）