Kyash カスタマーサポートチーム (以下、CSチーム) のすーもです。KyashのCSチームでは、お客さまからのお問い合わせ応対後にサービスやプロダクトへの満足度の回答を受け付けています。 この記事では、取得した「満足度評価」をどのようにして活用しているか紹介します。
Kyashでは「満足度評価」はCSAT(Customer Satisfaction)と呼んでいます。問い合わせ対応後のお客さまに「サポートに満足しましたか？」の質問を通知しています。質問に対して「満足」または「不満」を選択後、自由記述欄で回答を受け付けています。
CSATの回答はGoogle Apps Scriptによって自動で収集が行われています。毎日朝と夜に2回更新されるので、CSチームでは定期的にスプレッドシートを確認し、改善策を検討しています。具体的な取り組みについては後述します。
「不満」評価の分類
「不満」の理由
不満評価を選択した際に不満の理由も選択いただいています。選択肢には「解決ができていない」、「回答内容が間違っている」、「回答が遅かった」などがあります。
中でも「解決ができていない」の理由に対しては優先的に対応をしています。Zapierという自動化ツールを使ってSlackで担当したCSメンバーにメンションと該当の問い合わせが通知されます。
CSチームのKPIのひとつに「問い合わせ解決時間」があります。KyashではSLA(Service Level Agreement)と呼び、設定した時間内に問い合わせを解決できるように取り組んでいますが、「解決ができていない」という評価理由に対しては、SLAを問わず優先して対応しています。
「不満」の種別
前述の不満の理由はお客さまに選択いただきますが、私たちもサービス改善のために評価を分類しています。これを「不満種別」と呼んでいます。
不満種別には大項目と小項目があります。大項目は「カスタマーサポート起因(以下、CS起因)の不満」と「プロダクト起因の不満」です。前者は問い合わせの回答内容に誤りがある、回答が遅い、などのサポートを原因とした不満を指します。後者はアプリの使い方がわからなかった、決済・入出金ができなかった、などのプロダクトを原因とした不満です。
CS起因かプロダクト起因かを判断するのは担当したオペレーターですが、判断が属人化しないように判断基準表を用意して、迷ったら表を見て決定をしています。
小項目はCS起因とプロダクト起因をさらに踏み込んで分類します。前者なら「回答内容」や「応対時間(の遅さ)」、後者なら「アプリの操作感」や「返金」、「本人確認」などに分けます。小項目の判断で迷った時も前述の判断基準表をもとにすることで属人的な判断を防いでいます。
分類から行動へ
CS起因の場合
不満種別でCS起因と判断したものは、CSチーム内で再発防止に向けた改善の取り組みをします。具体的には、根本原因を特定し回答文の元となるテンプレート(以下、マクロ)の見直しや案内したヘルプページに誤りがないか、社内マニュアルやオペレーションに不備がないか、などを点検します。
取り組みを行うにあたりチーム全員で心がけているのが、不満評価を個人の責任にしないことです。Kyashの組織文化(Kyash Value)のひとつである”One Team”にならい、どんな理由であれ必ずチームの課題として取り組みます。
マクロの見直しやヘルプページ、社内マニュアルの修正はチーム内で担当者と期日を決めて取り組みます。担当者はいつ、何を修正したかを管理シートに追記し”進行中”、”完了”といった進捗を管理します。
また、毎週行っているCSチームの定例会議において「Good・Kaizenシート」と呼ばれているスプレッドシートを用いてチームに問い合わせ対応を共有する仕組みもあります。
「Good」は名前の通り「良い対応」を記するシートで、主に満足評価を受けた問い合わせを共有しています。こちらについては後述します。
「Kaizen」は「もっと良くなる対応」を記すシートで、主に不満評価を受けた問い合わせの中でも、複雑な事象やイレギュラーな対応を共有しています。将来的なマニュアル化を見据えて、めずらしいケースをチーム全体に周知するねらいがあります。
プロダクト起因の場合
プロダクト起因の不満評価に関しては、「お客さまの声」を起点としたサービスの継続的改善の記事で触れているように、Slackの「#all-users-voice」というパブリックチャンネルやAll Handsと呼ばれる全社ミーティングで共有する手段があります。このような共有方法とは別にバックログとして提案する手段を紹介します。
プロダクト起因の小項目は、現在10個ほどの選択肢があります。集計する中で特定の項目が増えていた場合は未確認のバグや不具合の可能性、またはある機能のニーズや改良が高まっているのではないかと仮説を立てます。
そしてタスク管理ツール「JIRA」を用いて調査や機能改善を提案します。他のプロジェクトの状況も鑑みて全体を見ながら優先順位を決めるのはプロダクトマネージャーです。
CSチームとしては是が非でも通したいと考えている提案であっても、CSの帰納的アプローチがサービス全体やあるべき姿に沿わないこともあります。
そこで必要なのが定量データです。提案した調査を行うことでサービスや利用者にどれくらい影響があるのか？を伝えることが求められます。CSチームとしては試行錯誤を重ねている点ではありますが誰がみても納得しやすい提案を心がけています。
「満足」評価はチームのモチベーションに
有難いことに「満足」の評価をいただくことも少なくありません。中には感謝のお言葉を添えていただけるお客さまもいます。私たちとしては「問い合わせを送る」というコストをかけさせてしまっているにも関わらず、感謝の声をいただけることを嬉しく思っています。
前述した「Good・Kaizenシート」の「Good」は、満足の評価を受けた本人以外のメンバーから共有しています。オペレーション上、お互いの問い合わせ対応に触れる機会が多いため、気付いたメンバーが「○○さんの応対が良かった」と発表します。
組織としてはどうしても不満評価への改善に目を向けがちですが、満足評価にも目を向け、称え合うことでチームのモチベーションアップに繋がっていると考えています。
たくさんのご意見や要望をいただけることに感謝しつつも、サービスやプロダクトに反映できていないことに歯痒さを感じています。
抽象的な話になりますが、本質的な「満足」とは問い合わせが発生しないことと言っても過言ではありません。つまりは「？」が生まれても自己解決ができるサービスであり、もっと言えば 「？」が生まれない状態を目指すべきだと考えています。
加えて、お客さまの大切なお金を扱っている金融サービスとして、伝統的な銀行やカード会社と同水準のサポートが求められる一方、「新しいお金の文化」の創造を目指すデジタルウォレットアプリを、より多くの方に理解・安心して使っていただく使命もあると考えています。
CSチームではお客さまからのお問い合わせに情緒性と機能性を兼ねた応対を行う反面、問い合わせの削減に向けた思考やアクションも求められています。
そんなCSチームでは一緒にはたらく仲間を募集しています。カスタマーサポートの枠にとらわれないサービス改善、さらには人々のライフスタイルに寄り添ったサービスづくりに興味がある方はぜひご覧ください。 herp.careers
