← エピソード一覧に戻る Episode 255 Chapter 1
Chapter 2
Chapter 3
Chapter 4
Chapter 5
0:00 / 0:00
スクリプト
Chapter 1 オープニング
タカシ
皆さんこんにちは、タカシです。今日は SaaSサポートの品質保証を扱います。Brooklinen では CSAT と生産性を見ていたのに、実は policy miss が隠れていました。満足度が高くても、良い対応とは限らない。ここが今日の出発点です。
ミカ
ああ、それは怖いですね。数字は良く見えるのに、運営の中では危ない対応が積み上がっているわけですよね。私もつい CSAT や返答の速さだけで安心しそうなので、かなり耳が痛いテーマです。
タカシ
SaaS では一回の雑な対応が、その場で終わりません。月額課金なので、活用低下、更新見送り、アップセル失速へと後から効いてきます。だから品質保証は、サポート部門の細かい管理ではなく、継続売上を守る経営テーマなんですね。
ミカ
なるほど。今日の話は、親切にしようという精神論じゃなくて、何が良い対応かを定義して、ズレを見つけて、直す仕組みの話なんですね。サポートを信頼の生産ラインとして見る感じがします。
Chapter 2 品質保証は何を見ているのか
タカシ
Intercom と Klaus の調査では、品質評価で最も重視されるのは解決策の妥当性で約 86 パーセント、続いて product knowledge が約 80 パーセント、internal process が約 78 パーセント、tone と empathy も約 84 パーセントでした。
ミカ
面白いですね。感じの良さだけじゃなくて、ちゃんと正しく解決したか、社内ルールを踏んだかまで含めて品質なんだ。しかも tone や empathy も同じくらい見られているから、冷たく正しいだけでも足りないんですね。
タカシ
その通りです。品質保証は、正しさと伝わり方の両方を揃える仕事です。Zendesk でも rating categories から Internal Quality Score を作る設計で、何を採点するかを決めること自体が運営の骨格になります。測れない品質は、改善も再現もできません。
ミカ
ここ、経営者が見落としがちかもしれませんね。速く返せ、CSAT を上げろだけだと、現場は最短で気持ちよく終わる返事に流れやすい。でも SaaS は契約や設定や権限が絡むから、短期の満足が長期の正解とは限らないわけです。
Chapter 3 良いスコアカードと calibration
タカシ
ただし、スコアカードは細かければ良いわけではありません。Klaus の 2023 年ベンチマークでは、評価カテゴリ数は平均 14、中央値は 8 でした。多すぎると review が回らず、少なすぎると粗い。致命傷になる論点を絞るバランスが大事です。
ミカ
たしかに、二十項目もあると reviewer ごとに見方がぶれそうですし、agent も何を直せばいいか分からなくなりそうです。逆に三項目しかないと、SaaS 特有の権限や課金や障害案内のミスを拾いきれない気がします。
タカシ
そこで効くのが calibration です。Zendesk では複数の reviewer が同じ会話を採点し、baseline review と比較できます。これを回さないと、agent の品質差ではなく reviewer の甘辛が点数に出てしまう。品質保証は agent だけでなく採点者も整える仕組みなんです。
ミカ
なるほど、点数の前に物差しを揃えるんですね。しかも Zendesk の AutoQA では、人と自動採点の一致度が 75 パーセント超なら high accuracy と見なす。AI は reviewer を置き換えるより、全件の傾向監視を広げる役として使うのが良さそうです。
Chapter 4 SaaS運営で効く具体例
タカシ
Brooklinen は QA を入れて chat flow の詰まりを見つけ、pre-chat survey を追加しただけで 30 日以内に AHT を 25 パーセント削減しました。品質保証は、遅い agent を叱るためではなく、運営の摩擦を特定して全体を速くするためにも使えるわけです。
ミカ
それはいいですね。QA という名前だとチェックと減点の印象がありますけど、実際はボトルネック発見装置でもあるんだ。サポートの会話って、プロダクト、ヘルプセンター、運用設計の欠陥が全部集まる場所ですもんね。
タカシ
MeUndies の例も分かりやすいです。ブランドらしい声で対応したか、という曖昧な項目を四つの特徴へ分解し、QA チームが毎週 hundreds of interactions を見て、L&D に月次レポートを渡していました。採点がそのまま育成設計につながっていたんですね。
ミカ
ここが重要ですね。品質保証が嫌われる会社って、点数だけ返して終わる気がします。逆に、教材更新やマクロ改善までつながれば、agent から見ても自分たちを助ける制度になる。受け止め方がかなり変わりそうです。
Chapter 5 明日から整える実務
タカシ
明日からやるなら五つです。第一に、解決の正しさ、プロセス順守、トーン、次の一歩の明確さなど六から八項目で scorecard を作る。第二に、weekly の random sample と escalation を両方見る。第三に、monthly で calibration を回すことです。
ミカ
加えて、CSAT だけでなく IQS、再オープン率、escalation 率、AutoQA の一致度も並べたいですね。速いけど危ない対応と、難しいけど正しい対応を見分けるには、一つの数字だけだとどうしても足りません。
タカシ
その通りです。SaaSサポートの品質保証は、丁寧な人を褒める制度ではなく、良い対応を再現可能にする制度です。会話レビューを L&D、help center、product 改善までつなぎ、品質の定義、採点の一致、改善の循環を止めないことが核心になります。
ミカ
今日は SaaSサポートの品質保証を見てきました。CSAT が高いだけでは安心できない、だからこそ良い対応を言語化して、同じ物差しで見て、育成と改善へ戻す。ぜひ皆さんの組織でも、QA を監視ではなく学習装置として設計してみてください。