最初の振り分けで解決速度は決まる ― SaaSサポートの問い合わせトリアージ

今日は SaaS サポートの問い合わせトリアージです。Benevity は年間三十五万件超の問い合わせを扱いながら、ネガティブ感情のチケットへの応答を五十八パーセント速くしました。鍵は、入口での切り分けでした。

そこが落とし穴です。SaaS では同じ一件でも、障害なのか請求なのか、VIP 顧客なのか、日本語か英語かで、適切な担当も急ぎ方も変わります。最初の見立てを誤ると、全部の指標が悪化します。

問い合わせトリアージは、何の問題か、どれくらい緊急か、どの顧客に起きているか、誰の知識が必要かを、受信直後にそろえる仕事です。分類して終わりではなく、正しい順番と正しい担当へつなぐところまでが本体です。

その通りです。Zendesk は intent、language、sentiment を自動判定し、さらに availability、capacity、skills、ticket priority を踏まえて routing method を選ぶ考え方を示しています。つまり SaaS のトリアージは、分類と配分の設計なんです。

だからフォーム設計が重要です。Freshdesk も、よく設計された ticket form は問い合わせ内容を説明しやすくし、Type、Priority、Group、Product などの metadata を最初からそろえると説明しています。情報不足は、そのまま再確認の往復に変わります。

Intercom も同じ発想で、plan、language、office hours などの属性で会話を分ける workflow を案内しています。Enterprise 顧客を VIP チームへ直送したり、言語ごとの team へ回したりして、最初の待ち時間とたらい回しを減らすわけです。

Intercom の自社サポートでは、assignment rules が会話の約半分を自動ルーティングし、その routed conversations の六十パーセントが最初の inbox で正しい場所に着くと公開されています。最初の一回で合う率を上げるだけで、解決速度は大きく変わります。

Benevity では、ネガティブ感情の問い合わせを senior agent に寄せる運用で、応答を五十八パーセント高速化しました。七人のリードがやっていた手動分類も、年間三百六十四時間分削減しています。トリアージは感覚論ではなく、処理能力の増強策でもあります。

Atlassian の社内サービスデスクも示唆的です。以前は十四の service desk に分かれていましたが、今は Level 1 agent が every message を triage し、repeatable な解決は runbook に追加して Level 1 で処理できるようにしています。良いトリアージは、上位チームを守る設計でもあるんです。

よくある失敗は五つあります。一つの受信箱で全部読むこと、優先度を声量で決めること、AI 分類を無条件で信じること、必須情報を集めないこと、そしてトリアージ結果を runbook やヘルプ記事改善へ返さないことです。

その順番で進めるのが堅実です。問い合わせトリアージは、サポートの入口作業ではなく、解決時間と信頼を左右する経営設計です。皆さんのチームでも、最初の振り分けが属人化していないか、ぜひ見直してみてください。それではまた次回。