← エピソード一覧に戻る Episode 243 Chapter 1
Chapter 2
Chapter 3
Chapter 4
Chapter 5
0:00 / 0:00
スクリプト
Chapter 1 オープニング
タカシ
今日は SaaS サポートの解決時間です。Atlassian は AI 強化された問い合わせで、平均 customer contact resolution time を八日から九分未満へ縮め、しかも CSAT 九六・一五パーセントを維持したと公表しました。
ミカ
八日が九分未満ですか。かなり衝撃ですが、そもそも解決時間って何を指すんでしょう。返事が来るまでの速さとは違うんですよね。
タカシ
違います。解決時間は、問い合わせを受けてから顧客の問題が実際に片づくまでの時間です。SaaS では返答が速くても、顧客が仕事を再開できなければ価値は半分なんです。
ミカ
なるほど。初回応答時間が玄関の早さだとすると、解決時間は家の中までちゃんと案内できたかを見る感じですね。今日は、その測り方と縮め方を知りたいです。
Chapter 2 解決時間は何を測るのか
タカシ
Zendesk は、最初に解決した時点までを first resolution time、最後に完全に解決した時点までを full resolution time と分けています。再オープンがある SaaS では、経営判断では後者を見るほうが実態に近いです。
ミカ
たしかに、一回 solved にしても、そのあとまた顧客が戻ってきたら終わってないですもんね。数字だけ閉じていて、現場ではまだ火が消えていない感じです。
タカシ
その通りです。さらに Zendesk の定義では、requester wait time、agent wait time、on-hold time も別で持てます。つまり解決時間は一つの塊ではなく、誰待ちで伸びているかを分けて初めて改善に使えるんです。
ミカ
全部まとめて平均だけ見ると、サポートが遅いのか、顧客から追加情報が来ないのか、社内保留が長いのか、ぜんぶ混ざってしまうわけですね。ここを分けないと責任の置き場所を間違えそうです。
Chapter 3 正しく測らないと数字が嘘をつく
タカシ
Zendesk の公式レシピでは、full resolution time から pending と on-hold を差し引いた指標を別途作る方法まで案内されています。顧客返答待ちや保留時間を含めたままだと、改善の打ち手を誤りやすいからです。
ミカ
たしかに、顧客が三日間返事をくれなかった案件まで、サポートチームが三日遅いと判定されたら現場はたまらないですね。しかも夜や土日まで足すと、さらに長く見えます。
タカシ
そこで Intercom は、time to resolve を waiting on customer や snoozed 状態で一時停止できるようにし、二〇二六年四月には office hours ベースの resolution metric も追加しました。夜間や週末で数字が膨らむ問題への対応ですね。
ミカ
つまり SaaS の解決時間は、総時間だけでなく、チームが制御できる時間を別に持つのが筋なんですね。測り方が粗いままだと、改善しても成果が見えないし、悪い評価も出やすい。
Chapter 4 短い解決時間を作る運営
タカシ
Wrike は面白くて、全顧客へ二十分以内に返す体制を作ったあと、管理軸を first response time から full resolution time へ移しました。しかも顧客セグメントと問い合わせ種別ごとに目標を変えています。
ミカ
一律の速さ競争をやめて、誰の何の問題をいつまでに終わらせるかへ変えたわけですね。経営っぽいです。声の大きい問い合わせに全部引っ張られなくなりそうです。
タカシ
Esusu も、月一万件規模の問い合わせでチャネル統合と社内連携を進めた結果、初回返信時間を六四パーセント、full resolution time を三四パーセント改善しました。解決時間は後工程との接続速度で大きく変わります。
ミカ
サポート担当が優秀かどうかだけじゃなく、請求、データ、開発にどれだけ早くつながるかまで含めて設計しないと縮まらないんですね。フロントだけ磨いても限界があると分かります。
タカシ
そして Atlassian の事例が示すのは、ナレッジ、ルーティング、実行権限がつながると、解決時間は人海戦術ではなく設計で縮められるということです。速さと CSAT は両立し得ます。
Chapter 5 よくある失敗と明日からの実践
タカシ
失敗は五つです。初回応答だけを見て安心すること、顧客待ち時間まで全部チーム責任にすること、全案件へ同じ SLA を当てること、平均値だけで判断すること、そしてルーティングとエスカレーションを後回しにすることです。
ミカ
明日からやるなら、まず full resolution time と顧客待ちを分ける。次に、問い合わせ種別と顧客セグメントごとに解決時間目標を切る。さらに中央値や再オープン率も一緒に見る、この三つから始めたいです。
タカシ
その順番が良いです。解決時間は、速く返したかではなく、顧客をいつ前に進めたかを見る指標です。皆さんも、自社のダッシュボードが総時間だけで終わっていないかを見直してみてください。それではまた次回。