曖昧な申告から、原因を絞る
オペレーターは、何を確認すべきかを考え、操作を案内し、その結果から原因を判断しなければなりません。
応対に埋もれた判断の根拠やノウハウを組織に残し、定型対応から例外への対処まで活用する。通信系コンタクトセンターでの事例をご紹介します。
通信サービスの技術サポートでは、顧客が問題を正確に説明できないことも多く、オペレーターが質問と操作案内を重ねながら原因を絞り込む必要があります。特に複雑なトラブルは熟練者へ集中しやすく、採用・教育が難しくなる中で、事業を拡大するうえで大きな制約になっていました。
本事例では、約1年間、お客様と実際の手順書、技術資料、過去通話を用いて改善を重ね、通常問い合わせの自動化と、例外時のオペレーター支援を組み合わせた運用モデルを構築しました。
お客様のサポート対象は、機器が相互に関係する複雑なサービスです。利用者には機器に詳しくない方や高齢者も多く、「映らない」「動かない」といった曖昧な説明から対応が始まります。
オペレーターは、何を確認すべきかを考え、操作を案内し、その結果から原因を判断しなければなりません。
「この症状なら何を疑うか」「この答えなら次に何を聞くか」。その多くは通話の中で使われるだけで、体系的な文書として残りませんでした。
高度な問い合わせは一部の熟練者に依存。採用・教育の負荷が高まり、難しい案件はベテランへ集中していました。
標準的な問い合わせではSOPに沿って対応を進め、想定外の状況では技術資料や過去事例を参照できる仕組みを構築しました。
標準的な問い合わせでは、SOPに沿って確認と操作案内を進めます。通常ケースは、AIが主導して応対します。
想定外の状況では、技術資料や過去事例を参照。判断が難しいケースは、人へ引き継ぎます。
実際の通話から、熟練オペレーターの判断や例外対応を抽出し、再利用できるナレッジとして蓄積。現場でしか得られなかった経験を、AIと他のオペレーターが使える組織の資産に変えていきます。
応対品質を確認しながら、自動化の範囲を検討する運用モデルです。
標準的な問い合わせの多くを、SOPに沿ってAIが応対します。
判断が難しい場面では、AIがオペレーターを支援し、必要に応じて引き継ぎます。
利用が認められた通話から改善候補を抽出し、レビュー・テスト・承認を経て適用。対応範囲を広げます。
約1年間の共同開発を通じて、実際の手順書、技術資料、過去通話、テストケースを使って改善を重ね、実業務への適用に向けて応対と処理を検証しました。通常問い合わせの多くを自動化し、例外ケースではAIがオペレーターを支援することで、本事例の運用モデルでは、コンタクトセンター全体の業務量について約40〜45%の削減を見込んでいます。
実際の手順書・技術資料・過去通話・テストケースで改善を重ねました。
通常問い合わせの自動化と、例外時の支援を組み合わせた運用モデルです。
通話から改善候補を抽出し、レビュー・テスト・承認を経て適用します。
約40〜45%は、本事例の運用モデルにおける見込みであり、本番運用で実測した削減率ではありません。実際の効果は、対象業務、自動化の範囲、人による監視・例外対応などの条件によって異なります。お客様名は非公開としています。
難しい案件の判断材料を共有し、経験の浅い担当者でも対応しやすくします。
個人の経験を組織で再利用し、教育に必要な時間と依存度を下げます。
定型対応はAI、例外は人という役割分担で、無理な完全自動化を避けます。
応対そのものを、新しいナレッジを増やす活動に変えます。
問い合わせの種類や件数、応対手順、引き継ぎの課題をお聞かせください。
支援と自動化を、どの業務から始めるか一緒に整理します。