CSのオペレーション設計と運用について
突然ですが、私が普段何をしてご飯を食べているかというと、CS（カスタマーサポート）チームのマネジメントというものが主です。
気がつくとトータル10年弱ほどこの職種なのですが、マネジメント業務の一つにオペレーションの設計と運用というものがあります。
これについて割と初期段階の作業をしている最近の私自身の状況もあり、noteに書いてみようと思いました。
具体的には以下を指します。
1. 業務の手順を決める
2. その手順で行えるように指示をする
3. 実際に行われているか＆今後も継続して行えるように運用を管理する
4. 何か問題が無いかを確認し改善していく
これぐらいの粒度だと「そりゃそうだろ」的なPDCAな見た目なのですが、それぞれの箇所に注意点があって、雑に構築してしまうとチームのパフォーマンスがとてつもなく落ちて、それにより増員せざるを得なくなり、CSはコストセンターと呼ばれ、効率の悪い手順のためメンバーも死んだ顔でルーチンワークをこなし、余裕の無い状態で対応しているため、するべき改善も行えず…
という悲しいチームになりがちです。
そうならないために注意点を以下にまとめてみます。
CSにおいて理想のオペレーションとは
まずは理想が分からないと設計が出来ません。
オペレーションという単語自体には色々な意味がありますが、ここでは「ある目的を達成するための作業」とします。
となると、その目的を一番良い形で達成できるのが理想のオペレーションです。
CSは様々なお問い合わせに返答するのが主な仕事の一つですが、その中に「〇〇が出来ない」といったお問い合わせがあると思います。
この場合は「〇〇を出来るようにする」というのが目的の一つになりますが、理想は「〇〇が出来ない」という問題自体を発生させない事だと思います。
理想としては上記があるものの、それは難しいケースもあるでしょう。
となると次点は、より迅速にその問題を解決する事です。
つまり、オペレーションの設計においては解決までの時間（リードタイム）を考慮する事が重要になります。
1. 業務の手順を決める
発生した問題を解決するための手順ですが、例えば「〇〇が出来ない」の場合は、それが何故出来ないのかを把握する必要があります。
ここで仕様の理解に誤解があると本来すぐ解消出来る問題なのにも関わらず、関係部署に適切に情報がいかず、CSが個別に問い合わせ対応し続ける…
という事態になる可能性もあります。
そのため、初見の問い合わせが発生するたびに関係部署へ共有し相互に仕様を理解し状況をまとめ対応するのが望ましいです。
この段階でその問い合わせが単発のものなのか、複数発生する可能性のあるものなのかを切り分け、複数発生するものの場合は次回以降の作業を効率化するため、オペレーションの手順を設計する必要があります
その際の注意点としては以下4点です。
- 問題解決可能なヘルプページなどは用意されているか
解決可能なものはユーザーに解決してもらいましょう。もしヘルプページが用意されているなら、その問題が発生してから問い合わせまでに該当ページの導線が用意されていない事が問題かもしれません。
問い合わせ対応のオペレーションも設計する必要はありますが、本質的なのは問題解決手段をサービス上に用意する事で、こちらも並行して進める必要があります
- MECE（重複が無く、漏れがないか）であるか
何も知らない人が手順を見て対応できる必要があるので、内容に漏れがあるといけません。また、すでに同様のオペレーションが無いか、一部重複しているものが無いかもチェックが必要です
- 必要の無い手順が含まれていないか
システムで代替え出来る事に多大な時間を消費（例えば1000行のコピペを1行ずつとか）するのは問題なので、そもそも時間がかかる場所への疑いが必要です。
- 致命的なリスクがある手順が含まれていないか
様々なものがありますが、例えば多くのカスタマーサポートは個人情報を扱っています。その個人情報を適切に扱っているかどうかは常に注意が必要です。
2. その手順で行えるように指示をする
手順が固まったらそれを言語化（マニュアル化）して対応者（メンバー）に伝える必要があります。マニュアルの作成にあたっての注意点としては、このマニュアルはどのタイミングで誰がどの程度使用するのかです。
少しどのようなマニュアルの優先度が高いか話をさせてください。
使用するタイミングは新人研修時、定常的な作業時、等ありますが、新人研修の際には簡単な説明で一度教えてしまえばその後は全くフォローしなくても問題の無い基本的なツールの使用方法みたいなものも多くあると思います。
作成のコストも考慮に入れる必要がありますが、リソースが無い状態では使用回数が1回のみのマニュアルの作成優先度は下げて良いと思います。
（ただし、新人が定常的に入る大きいセンター等の場合は細かいエスカレーションの負担を減らしたり、共通理解の基を多く用意する必要があるので、ここにも力を割くべきですし、メンバーが少数であっても勿論マニュアルが完備されていた方が望ましいです）
まず必要なマニュアルは、定常的に発生する案件へのマニュアルです。
このマニュアルの精度が高ければ、新人でもほとんど研修を行わずに対応してもらう事が可能です。
そのため、どのタイミングで誰がどの程度使用するかによってマニュアルの細かさを変えた方が効率的です。
例えば、何度もメンバーから質問が来るといった案件はマニュアルの作りが悪い事がほとんどです。
どういった質問がどのメンバーから何回来ているか。
という部分も見ないとなので、単に網羅的なマニュアルであれば良いのかというとそうではありません。
見づらいとマニュアルに書いてある事でも質問が発生するのはあるあるなので、各ブロックをファーストビューに収まる形で作っていくなどの工夫が必要です
雑だったり複雑なマニュアルで対応した場合はメンバー毎の差が生まれやすく、理解に時間がかかるのでコストがかかります。
そのため、マニュアルはコストカットやリソース確保の面でも大きな役割を持っています。
これは組織やサービスの規模が大きくなるほど顕著です。
もう一つ、定常的な問い合わせ対応において重要なのが、テンプレートの用意です。
問い合わせをテンプレートで返答していると言うと不快感を覚える方もいるかもしれませんが、テンプレートは問い合わせ者と対応者、双方にとって重要です。
用意されてないと以下の問題が発生します。
- 対応者毎に別のスタンスで返答する恐れがある。
- 文面が統一されておらず、別の解釈をされる恐れがある
- 案内に抜けが発生する恐れがある
- 統一されてない対応のため、同じ案件なのに問い合わせ者毎に別の対応をする恐れがある
- 一から文章作成をするので時間がかかる
- テンプレートが登録されているか探す時間も発生する
- 過去案件の返信例を探す時間も場合によっては発生する
- 過去案件の返信に誤りがあった場合は継続して誤った案内をする恐れがある
誤解の無いように補足しますと、テンプレートは返信の土台になるものなので、テンプレートを使用している = 手書きを全くしていない という事では無いです。
あげればキリが無いほどテンプレートが用意されていない弊害は大きいのです。
また、テンプレートがあったとしても、使えないと意味が無いので、マニュアルと連動してどのテンプレートを使用するかを明示するのが重要です。
※テンプレートがゲシュタルト崩壊しそうなほどテンプレートと書いてしまった…
3. 実際に行われているか＆今後も継続して行えるように運用を管理する
マニュアルとテンプレートを作成したら、それを対応してもらうメンバーに共有しそのマニュアルを基に対応してもらいます。
実はここが肝な作業な気がします。この作業段階でよくあるケースでは「言ったのにやってくれない」「マニュアル通りに作業してくれない」等です。
ここはそれまでの企業文化の内容であったり、対応するメンバー、そして監督しているマネージャーにかなり左右されるところです。
どうすれば良いかはシンプルで
1. やってくれない場合はなぜやってくれないかメンバーにヒアリング
2. ヒアリングした内容を基にマニュアルを改善、もしくはメンバーに詳細を説明し次回からやってもらうようにする
の繰り返しです。優秀なメンバーであればマニュアルに含まれている問題を指摘してくれた上でマニュアル通りに対応してくれると思います。
気をつけないといけないのは、ここでメンバーに極端な心理的負荷が発生していないかの確認です。
自分がどういう要求をしているのか、出来れば依頼している作業内容を自分でも体験してどのような心理的負荷がある作業なのかを理解する事です。
めんどうな業務は負荷が高く、運用継続の大きなハードルになるので、長期間アサインするとメンバーの離職などのリスクも発生します。
つらい業務を任せる場合は、どの程度の期間メンバーにその対応を我慢してもらうか等のコンセンサスを取る必要があります。
つらいかどうかは個人差が激しい部分なので、普段からメンバーと関係を構築して有効なヒアリングが行えたり、エスカレーションが自然と上がってくる体制にする方が大事です。
不透明な依頼は依頼された側に負荷をかけます。
マネジメントレイヤーの人間はメンバーに明確にディレクションしてパフォーマンスを発揮出来るようにサポートしていくべきだと考えます。
ちなみにメンバーがエスカレーションをしなくなる一番大きな原因はそのエスカレーションが無駄だったと思う事だと思います。
行った改善提案が明確なロジックのある説明も無く受け入れられなかったり、ひどいケースでは無視されたり、、、誤った返答をされた上にその事後処理をさせられたり、、、こんな状況では誰もエスカレーションなんてしたくなくなりますよね。
4. 何か問題が無いかを確認し改善していく
定常化している案件対応が標準化した段階では、理想である「〇〇が出来ない」という問題自体を発生させない事にもう一度向かいあった方が良いです。
ある程度の期間をおいてから考えると、状況も変化している事が多く、問題自体を解消できる場合もあります。
また、標準化した段階において改めてメンバーにヒアリングする事で効率化のアイデアをもらえる事もあります。
一番その対応がわかっているのは、普段その業務を行っているメンバーなのです。
そのアイデアは何が今問題であるかを含んでいるので、それを改善する事により、迅速に問題を解決する事に繋がります。
マニュアルやテンプレートの整理の仕方
マニュアルやテンプレートが増えると、それ自体を検索する事にコストが発生して来ます。これを解消するためには色々やり方はあるのですが、階層化して管理するのがおすすめです。大カテゴリ＞中カテゴリ＞タイトル みたいな形に整理する方法です。
テンプレートの場合は例えば ログイン＞出来ない＞方法が不明 といったものなどがありそうです。ちなみにタイトルはお問い合わせの内容にした方が使用時に直感的に理解しやすいものになります。
これを図にすると以下のようになります。もしログイン関連のお問い合わせが多いようであれば、このフローに則った案内を導線に用意する事でお問い合わせの数を減らせるかもしれません。
マニュアルの場合はもう少し粒度は大きい方が良く、基本的には大カテゴリの「ログイン」というページを用意して網羅的に集めた方が良いです。
情報量が多く見づらくなるなら階層は ログイン＞出来ない 程度に留めて、その「出来ない」のページ内に「方法が不明」「メールアドレス紛失」の説明を入れるとコンパクトに収まります。
どういった研修を行うかによっても変わりますし、マニュアルをどのタイミングでどう検索してもらうかにもより、使用しているツールによってもベストプラクティスが多少変わりますが、このように整理されていたらフェーズが変化した際の最適化もそれほど苦では無いと思います。
例えば、先ほどはマニュアルの階層はあまり無い方が見やすいと説明しましたが、wiki形式の場合は階層をファーストビューに収まる形でリンクで作っていけば目的のマニュアルへの到達が早くなりそうです。
お気づきの方もいると思いますが、この運用をする場合は事前に大カテゴリや中カテゴリの設計を行っていないと大変です。
ここを雑にしてしまうとせっかく作ったマニュアルやテンプレートが無駄になってしまうので、気をつけたいところです。
固定されたカテゴリの中で運用を継続できれば、メンバーからも自然に「〇〇カテゴリに〇〇といったテンプレートを追加してほしいです」といったようなコミュニケーションが生まれ、その時点でまた問題に気付けるという良い循環も生まれて来ます。
なお、マニュアルが作成されないまま、カテゴリやテンプレートが新たに追加される状況は属人化を生むので避けなければいけません。
また、階層化してカテゴリを管理するというのは、ある部分では管理コストがかかるのでサービスの規模や問い合わせの種類や規模に応じて臨機応変に設計する必要があります。
自動で推奨テンプレートやマニュアルが出てくるシステムやすごく頭の良いAIや分かりやすいヘルプページがあるのが理想ではありますが、ゆくゆくスムーズにシステム化出来るようにデータベースを作るという観点で考えると、予め階層化して管理しておくというのが、様々な面で楽だと思っています。
KGIとKPI
様々な改善を行うための分析に必要なので、マネージャーは数値管理も行います。
何を指針にするかは企業ごとに大きく異なりますし、経営層とのコンセンサスが大事になっていくところです。
ここでキーになるのは、その企業のミッションやバリュー、内部で公開されているKGIなどの目的の部分なのかと思います。
その配下になるKPIはCSのマネージャーが設計する事も多いと思いますが、シンプルにどこのCSでも見てて、なおかつ効果が高いのは解決までのリードタイムだと思います。（何を解決と定義するかも大事ですね）
NPSや顧客満足度やその回答率、問い合わせ率もCSのKPIにはなると思いますが、CSの理想としては冒頭に述べたものになると思うので、何も無い状況であれば、まずはここを追うのが間違いが無い気がします。
最後に
何も無いところから設計する場合は自分1人しか対応者がいないとかもあるあるなので、1人で運用してる方も多いと思います。
実務をしながらオペレーションを設計・運用するというのは、大変な事も多いと思いますが、基礎が全て、細部に神が宿ると信じているので、デッドラインは引きながら、焦らず丁寧に基礎工事すると後で楽が出来るはずです。
繋がる事として、組織的な理想としては自分が明日死んだとしてもオペレーションは滞りなく回る状態にしておくのが管理者としての責務かなとも思います。
また、CSの理想はユーザーが誰も困ってなくてCSが必要無い事という、どこのCSメンバーも抱えるジレンマがあったりするのですが、これはUIやUXをいかに改善していくかという話に繋がるので、仮に問い合わせが来なくなったとしてもそこに到るノウハウを持ったCSメンバーというのは別の仕事も出来るだろうし、CSとしても引く手数多であると思うので、そこを目指していきたいものです。
という事で実はnoteに転職して3ヶ月目の私です。
CSという職種柄この間何をしたかはセンシティブなので割愛します…！！！
多少話は変わりますが、私がCXOの深津さんの記事をじっくり読んだのは↓が初めてです。
当時漠然と頭の中にあった良いバランスを「こんな分かりやすく言語化出来るの！？」とかなり衝撃を受けました。（しかも私の頭の中より遥かに高精度に…）
こんな人がCXOの組織なんて面白いに決まっている！と勝手に思ったのもnoteに応募したとても大きな理由です。
オペレーション構築してチームをマネジメントしていくという業務をされている方にとっても必見の内容だと思います。
応募した後に↓の動画も見て、これはもう確実にこの会社面白いやろ…とか思ってました。是非ご覧になってください。
noteにはCEOとCXOに手軽に相談出来るslackチャンネルもあり、簡単に意見を聞けるのも素晴らしいと思います。
CEO加藤さんとCXO深津さんは「全く忖度のない組織にしたい」と言っていたので、可能なうちは私もどんどんぶつかって行きたいと思っています…！
そして、宣伝です。noteは新しいメンバーを募集しています！
note楽しいですよ
息子のおもちゃ代になる予感です