スクリプト
Chapter 1 オープニング
今日は SaaS サポートの一次解決率です。Unity は問い合わせ急増のなかでも、特定のチケット種別を九五パーセント one-touch で処理し、年間八千件近いチケット削減と百三十万ドル相当のコスト回避につなげました。
九五パーセントはかなり強いですね。でも一次解決率って、言葉は分かるようで意外と曖昧です。最初の返事が早ければいいのか、それとも本当にその場で片づいたかを見るのか、どっちなんでしょう。
見るのは後者です。一次解決率は、最初のやり取りだけで顧客の問題が解消した割合です。SaaS では往復が増えるほど、顧客の手間、業務停止時間、サポート原価が同時に膨らむので、かなり経営的な指標なんです。
なるほど。初回応答時間が入口の速さだとすると、一次解決率は一回目で出口まで行けたかを見る感じですね。今日は、どう測ってどう上げると筋がいいのかを知りたいです。
Chapter 2 一次解決率は何を測るのか
Zendesk では、電話なら一度の会話、メールなら一度の返信で解決できた割合を一次解決率として整理しています。Explore の one-touch resolution も、担当者の返信が一回で済み、その後に再オープンしていないことが条件です。
ということは、担当者がチケットを閉じたから解決、ではないんですね。顧客があとでまた連絡したり、実は諦めて別の人に聞いたりしたら、社内では解決に見えても、顧客側では未解決のままかもしれません。
そこが重要です。SQM Group は、社内のクローズ率や再入電追跡だけで測る内部指標は、顧客アンケートなどの外部測定より一〇から二〇パーセント高く出やすいと指摘しています。測り方が甘いと、改善余地を見誤るわけです。
たしかに、再問い合わせが来なかった理由が満足とは限らないですもんね。面倒で放置したのかもしれないし、営業や CS に横から聞いたのかもしれない。一次解決率は顧客視点で見ないと危ないんですね。
Chapter 3 高い一次解決率を作る仕組み
Unity の例が分かりやすいです。広告不正の問い合わせで必要情報を Web フォームで先に集め、担当エージェントがすぐ判断できる形に変えたことで、その種別の九五パーセントを one-touch で処理できました。入口設計で勝っているんです。
つまり、優秀な人が一人で頑張ったというより、最初に必要情報がそろうようにしたから、一往復目で判断まで行けたわけですね。問い合わせフォームって地味ですが、かなり経営インパクトが大きいですね。
Esusu も面白いです。月一万件規模の問い合わせを扱いながら、音声とメール、社内連携をまとめ、Slack 連携やサイド会話で専門部署につなぎやすくした結果、一次対応の前後が速くなり、one-touch response rate は八〇パーセントまで上がりました。
一次解決率って、フロント担当の話だけじゃないんですね。請求や開発やデータ担当につなぐ道が詰まっていると、一回目で答え切れない。裏側の連携速度まで含めて設計しないと数字は上がらないんだなと分かります。
Compass はさらに、問い合わせ内容を NLP で適切な専門チームへ振り分け、問い合わせ種別をナレッジ記事やテンプレートに対応づける設計を進めました。その結果、六五パーセントの one-touch resolution rate と九八パーセントの CSAT を両立しています。
高い一次解決率って、結局は三つですね。最初に必要情報が入ること、正しい人に最短で届くこと、そして担当者がすぐ使えるナレッジがあること。人の気合いだけで作る数字じゃないです。
Chapter 4 よくある失敗パターン
失敗は大きく四つあります。まず、閉じたチケット数だけで満足すること。次に、すべての問い合わせへ同じ目標を置くこと。三つ目に、表面質問だけに答えて顧客の本当の目的を聞かないこと。最後に、専門部署への接続が遅いことです。
特に二つ目はやりがちですね。パスワード再設定みたいに一回で終わるべきものと、障害調査みたいに時間がかかるものを同じ一次解決率で見たら、現場は無理に閉じる方向へ引っ張られそうです。
その通りです。Zendesk も、理論上一度で解決できる問い合わせに対象を絞ってよいと説明しています。無理に数字だけ追うと、顧客が次に困ることを想像せず、その場しのぎの返答をしてしまい、結果的に再問い合わせが増えます。
一次解決率は高いのに、なんだか顧客の不満が消えない会社って、たぶんそこですね。数字はきれいでも、顧客努力や再発防止まで見ていない。経営側が評価設計を間違えると、現場の行動も歪みます。
Chapter 5 明日からの実践
明日からやるなら五つです。まず、一度で解ける問い合わせ種別を定義する。次に、その種別ごとに必要情報をフォームで先に取る。三つ目に、専門家へ即相談できる導線を作る。四つ目に、ナレッジとテンプレートを更新する。最後に、CSAT と再問い合わせ率とセットで見ることです。
今日は、一次解決率はサポートの器用さではなく、入口設計と連携設計とナレッジ設計の総合点だと分かりました。皆さんもまず、自社で一回で終わるはずの問い合わせが何往復しているかを洗い出してみてください。それではまた次回。