Botiumで始めるAIボットの品質改善|試験データと運用の育て方
AIボットの品質は、公開前に一度試せば終わりではありません。問い合わせ内容や業務資料が変わるたびに、確認すべき条件も変化します。Botiumを活用した試験を続けるために、データ・指標・役割分担をどう育てるかを説明します。
AIボットの品質は、公開前に一度試せば終わりではありません。問い合わせ内容や業務資料が変わるたびに、確認すべき条件も変化します。Botiumを活用した試験を続けるために、データ・指標・役割分担をどう育てるかを説明します。
Cisco Webex Contact Center、Five9、NICE CXone、Salesforce、Avaya。主要コンタクトセンター基盤は機能比較こそ多いものの「品質をどう保証するか」の視点はあまり語られません。フロー設計、変更管理、テスト自動化の観点で5製品を整理します。
Cisco Webex Contact CenterのFlow Designerは、ノーコードでフローを変更できる手軽さが魅力です。一方で、手軽に変更できるからこそ品質リスクも生まれます。変更時に起きやすい問題と、それを防ぐテスト設計の考え方を解説します。
Five9はクラウドネイティブなCCaaSとして定期的に機能更新が行われます。ベンダーのリリースや自社のIVRスクリプト変更の前後で、顧客体験が変わっていないかを確かめるための10のチェック項目をまとめました。
NICE CXoneのStudioは柔軟にスクリプトを作り込める一方、小さな改修が想定外の経路へ波及することがあります。改修時の影響範囲の見極め方、優先して試験すべき経路、回帰試験を定着させる運用のコツを解説します。
Avayaのオンプレ基盤からCisco Webex Contact Center、Five9、NICE CXoneなどへ移行する際、最大の難所は「今と同じ動き」の証明です。現行IVRの棚卸しから切替後の監視まで、動作同等性を検証するためのチェックリストを紹介します。
FAQやプロンプトを直したら、別の質問に答えられなくなった。こうした変更による影響を調べるのが回帰試験です。Botiumの活用を念頭に、AIボットの変更前後を比較する準備、判定方法、失敗時の切り分けを説明します。
自動テストが失敗したとき、すぐに試験対象の不具合と決めつけると調査が遠回りになります。Velocityの試験結果を読む場合も、どの段階で何が期待と違ったのかを確認し、対象システム、試験環境、期待結果を分けて調べます。
CI/CDは、変更を統合し、テストや提供までの手順を継続的に進める考え方です。電話サービスでも、変更のたびに必要な試験を実行できれば、問題を早い段階で見つけやすくなります。Velocityを組み込む際の設計事項を整理します。
電話システムを移行するときは、「新環境へ電話がつながった」だけでは確認が足りません。案内、分岐、営業時間、外部連携など、利用者がたどる流れを旧環境と比較します。Velocityを使う場合も、同じ条件で比較できる準備が重要です。