サポートタイムズ

サポートタイムズはカスタマーサポートの“今”を届けるメディアです。(Powered by CallConnect)

カスタマーサポートの未来を考えよう!

Powerd by CallConnect
Twitter Facebook

システム思考でCSを効率化しよう!CS JAM #10 イベントレポート

f:id:sennba3:20170321142148j:plain

サポート担当者のみなさま、普段サポート業務をやっていて、「この作業いつもやっていてめんどくさいな」と思ったことはありませんか?

個々の処理速度を上げることも大事ですが、エンジニア視点で「仕組み化」を考えれば、いつもの作業の中で大きく効率化できる部分が見つかるかもしれません。

「システム思考でCSを10倍効率化する方法」というテーマのCSイベントがメルカリで開かれるということで、六本木オフィスまでやってきました。

今回のCS JAMでは、エンジニアやプロデューサーなどCS以外の業務も行ってきた登壇者によるライトニングトークが行われます。 具体的な業務効率化の例も聞けるようで楽しみです。

csjam.connpass.com

システム思考でCSを10倍効率化

f:id:sennba3:20170321123827j:plain

トップバッターはメルカリCSグループの松田さん。
発表テーマは、「システム思考でCSを10倍効率化」

松田 健/[メルカリ](https://www.mercari.com/jp/about/) CSグループ
楽天オークションの立ち上げメンバーとして、商品削除や悪質ユーザーの禁止処理、詐欺被害への補償を行うチームのリーダーを経験。退職後はIT業界から離れていましたが、2015年よりメルカリのCSで再度IT業界へ。好きな事、興味の持てる事ばっかり色々やってきましたが、今もメルカリで好きな事をやってます。


CSでありがちなのは「根性・とにかくがむしゃらに頑張る・残業してでも片付ける」という意識。
しかしながら、これはシステム思考ではありません。

松田さんは、パフォーマンスの高いメンバーのメソッドを一般化するのがシステム思考だと考えました。
つまり、個々のスキルだけに頼らず、全員が高いパフォーマンスを発揮できるような運用フローを構築する必要があると考えたのです。

では、具体的にどのような運用フローを構築したのでしょうか?実際に効率化した事例を紹介してもらいました。

対応範囲の拡大の事例

とある運用について、対応範囲の拡大を検討しています。

f:id:sennba3:20170321124254j:plain

・現在の対応量は300件/日。取引が長期化したものを抽出し、目視で対応していた。今回は対象期間を短くし、対応範囲を増やしたい。
・対応範囲が増えることによって、初回は一時的に6,000件の案件が発生。
・その後も6〜700件/日の新規案件が発生する見込み。
・ただし、対応リソースは2倍にしても良いという条件があった。

上記のようなお題を出された松田さんは、まず、メンバーの現状を調査してみました。すると、パフォーマンスが高いメンバーとそうでないメンバーでは“処理速度”が大きく違うことが分かったそうです。

さらに、パフォーマンスが高いメンバーがどのように案件を処理しているのかを個別に聞いたところ、

  • キャンセルというワードが出ているものだけを先に処理している。

  • その際、案件のここを見ておくといったパターンを作ることで判断を早くしている。

  • テンプレートの選択が早い。

  • 変換が早い。←予測変換をずっとやっているうちにその人に最適化されていた。

といったことが明らかになりました。

そこで松田さんは、SQLというデータを抽出する技術を勉強して、処理パターンをケース分けしていきました。
その結果、メンバーの処理速度を高めることができ、1人あたりの処理件数を最大化できました。

また、それぞれのケースごとにテンプレートを整理し直しました。これまでテンプレートを使う場合は、検索後のサジェストから選択する形式でしたが、お気に入りや過去の履歴が常に表示されているような設計に変更しました。

この施策により、溜まっていた6,000件もの案件を2.5ヶ月で処理できただけでなく、増加分にも対応することができ、安定稼働できるようになったそうです。

誰でもできるようにすること

CS部署の中だけで、こういう時はこのように対応しようといった暗黙の了解を作っても意味がありません。そういった状態では、エンジニアやデータアナリストにCSの現状を正しく伝えることは難しく、発言にも説得力を持てないことが多いそうです。
処理パターンをケース分けするなど明確化することで、情報共有もしやすくなり、また、メンバー全員が高いパフォーマンスを発揮できる環境作りにもつながっています。

エンジニアと接する極意 〜セロリに乗せて〜

f:id:sennba3:20170321123838j:plain

続いての発表は、Web制作などの事業を行っているLIGの北川パーヤンさんです。

発表テーマは、「育ってきた環境が違うから」

パーヤンさんは、CS担当者がエンジニアをはじめとした他の職種の人とうまくやるにはどういう視点を持った方が良いかということを セロリの歌に乗せて伝えてくれました。

北川パーヤン
CM制作・演劇制作・ソーシャルゲーム制作・アプリ制作を経て現在は[株式会社LIG](https://liginc.co.jp/)にてキャンペーンサイト/コーポレートサイトなどの制作を行っています。


スライド内容とともに会場の盛り上がりをご想像ください。(笑)

ましてやCSとエンジニアだからすれちがいはしょうがない
妥協してみたり多くを求めたりなっちゃうね〜

f:id:sennba3:20170321124551j:plain

相手を知ることが大事です。
恋愛と一緒ですね。

“メガベンチャーやスタートアップでエンジニアとともにプロジェクトを運営してきた経験から、「エンジニアはこういうものだ!」というのをあらかじめ知っておくと良いと考えているそうです。”

彼女を作ってよ!

例え話ですが
【お願い】
ねえエンジニア、ぼくに彼女作ってよ!

というお願いをしたら、エンジニアは考えます。

  • 彼女がいないことによる問題は?

  • 彼女?彼女がいることによって得られる効果は?

  • 作らせるにはどうしたら良いか?

  • 工数はどのくらいかかる?

  • コストは?

結果、エンジニアの回答としては
【回答】
それ優先度低くない?

といった形で断られます(笑)


では、こういう頼み方をしたらどうでしょうか?

【お願い】
ねえ、エンジニア、
ぬくもりを忘れて死にそうだから、
僕に彼女を作ってよ!

エンジニアはこう返してくれるでしょう。

【回答】
ペットを飼ったら?
キャバクラにいったら?

解決したい課題も一緒に伝えてあげることが大事だということです!
彼女を作ることは無理でも、課題解決のために複数の回答を提案してくれるかもしれません。

個々人に対して最適な対応を!

多種多様な職種が関わるプロダクト運営です。職種が変われば、人も変わります。
個々人に対して最適な対応を心がけて頑張りましょう!

つまりは単純にプロダクトのこと好きなのさ〜

黄金パターンを学べ

f:id:sennba3:20170321124005j:plain

最後はメルカリのプロデューサー永嶋さん。

発表テーマは、「仕組み化 to 自動化の黄金パターン」

永嶋 章弘
2010年、ニフティ株式会社新卒入社。ソーシャルメディア運用ツール開発、ベトナムオフショア開発マネージメントなどを経験。その後、不動産スタートアップのイタンジ株式会社へ転職。システム開発、不動産仲介営業、新規事業立ち上げなど幅広い業務を担当する。[メルカリ](https://www.mercari.com/jp/about/)に入社後は、ヘルプセンターリニューアルやバックエンドシステムの改善に携わっている。よくベトナム人に間違えられる。


永嶋さんはエンジニアや営業、CSも経験しているため、CSとエンジニア両方の視点をもっているようです。 これは期待できそうですね! メルカリではバックエンドツール開発などCSの仕組み化を進めるチームに所属しています。

10倍良くしてくれよと言われたら?

ある日上司からこう言われたそうです。
「CS業務を10倍良くする何かをやってほしい」

みなさんなら、上司に「10倍良くしてくれよ!」と突如言われたら、どうしますか?

『永嶋さんによれば、一旦仕組み化して自動化の兆しができてきたら、自動化する。
仕組み化→自動化』
この黄金パターンを見つけるのが重要とのこと。

f:id:sennba3:20170321125951j:plain

仕組み化=業務をだれでも・すぐに・効率よく
自動化=仕組み化した業務をシステムで自動処理

ここで言う仕組み化は、マニュアル化という意味ではありません。

メルカリで行われた具体的な仕組み化について、紹介してもらいました。

f:id:sennba3:20170321142453j:plain

上記はCSが見る管理画面ですが、ユーザーの画面・相手の画面・メッセージの画面がちりじりになっているので、複数の画面を見て判断しないといけません。

そこで、下記にように設計を変更し、管理画面を仕組み化しました。

f:id:sennba3:20170321142502j:plain

この仕組み化により、ユーザーのアクセス時間などの見るべき情報と、行う可能性のあるアクションの選択肢(ボタン)とをわかりやすく分けることができました。これで、マニュアルさえあれば誰でも業務を行うことができるようになります。

仕組み化の3条件に目を光らせろ

仕組み化するべき場所なのかを見極めるポイントは、以下の3つです。

  1. 非常に頻繁に行う作業である
    (1日に数千件とか)

  2. 見る項目が決まっている
    (アカウントの状況、メッセージの内容など)

  3. その後に取るべき対応が決まっている
    (特定メッセージ送信、取引ステータス変更など)

逆に判断できないのは、商品のここに傷がついているといった機械でも判定が難しいもの。システム的に判定可能なものなら自動化可能なはずと考えました。

自動化を恐れない

自動化して本当に大丈夫か?と言う声はよくあがるそうです。
本当に自動化の条件、合ってる?
変な処理が走ってしまったら?
クレームにつながったら?

しかし、実際は得られるメリットの方が大きい。メルカリには“GO BOLD”というバリューがあり、大胆にやってみようという社風なので、積極的に取り組むことが出来るとのこと。もちろん、自動で返信したものに対してはしっかりとWatchすることは大事です。最初は焦ったりすることもあるけど、最後には「良かったね!」となることが経験上多いそうです。

まとめ

f:id:sennba3:20170321131657j:plain

3人の発表後には、テーブルごとに、CSチームで困っていることについて話し合う時間が設けられました。 私のテーブルではCSはお客様に一番近い場所にいるので機能改善などを提案できるが、エンジニアや経営者を説得するのが難しいといった声があがっていました。

エンジニア×CSで拡がるカスタマーサポートの可能性

CSとエンジニアが歩み寄れば、実現できることも増えていくでしょう。

ビジネスの世界でも売って終わりではなく、ユーザーに製品を使い続けてもらうことで収益をあげる仕組み(サブスクリプション)が拡がりつつあります。継続的な収益をあげるためには、プロダクトやサポートのクオリティがこれまで以上に重要となります。つまり、プロダクトとCSは収益を支える2本柱とも言えます。メルカリのようにCSの重要性を認め、エンジニアとCSがコラボレーションできるフラットな環境を作れる企業が、今後ますます成長していくのではないでしょうか。

以上、CS JAM #10 イベントレポートでした。