チャットボットのKPI設計|利用率・回答率・解決率の計算方法
記事概要:チャットボットKPIを表示、起動、質問到達、回答、解決、離脱、有人転送の利用段階に沿って整理し、各指標の計算式と分母を示します。イベント計測と数値の読み方をそろえ、日常運用の改善に使える設計を解説します。
本記事の目次
チャットボットKPIは、回答率と解決率の分母を混同すると実態を誤って評価します。チャットボット利用率を含む各指標は、表示、起動、質問、回答、解決という利用段階に分け、どのイベントを数えたかを明示します。
利用段階を一つのファネルにする
対象ページの訪問、ウィジェット表示、起動、質問入力、回答表示、解決確認、有人転送を順に記録します。各段階の人数とセッション数を区別し、同じ利用者の再訪をどう数えるか決めます。
平均値は少数の長期案件に左右されるため、中央値と上位十分位も併記します。さらに用件、時間帯、担当グループ、新規・継続顧客で分けると、全体値の変化が需要増加によるものか運用問題によるものかを判断できます。

起動率と利用率の分母
起動率はボットが表示されたセッションのうち起動した割合とします。全サイト訪問を分母にすると、ボット対象外ページが多いサイトほど低くなるため、対象ページと表示条件を固定します。
目標を設定するときは、他社の値をそのまま採用せず、自社の基準値、顧客への影響、必要工数を使います。一つの指標を改善した結果、再問い合わせ、品質評価、担当者負担が悪化していないかを対になる指標で確認します。
回答率は質問到達を分母にする
回答率は有効な質問のうち何らかの回答を返した割合です。挨拶、誤入力、途中離脱を含めるかを決め、候補表示だけで最終回答へ到達していない場合を別に記録します。
日次では急な変化を検知し、週次では用件とチームの偏り、月次では施策の前後差を確認します。チャットボット運用担当者、Web分析担当者が同じ会議で原因と対策まで決められるよう、集計値から対象案件へ移動できる状態を整えます。
| KPI | 計算式の例 | 分母の条件 |
| 表示率 | 表示セッション÷対象ページ訪問×100 | 表示条件を満たした訪問 |
| 起動率 | 起動セッション÷表示セッション×100 | 自動起動を分ける |
| 質問到達率 | 質問入力セッション÷起動セッション×100 | 挨拶だけを除く |
| 回答率 | 回答できた質問÷有効質問×100 | 候補表示の扱いを決める |
| 解決率 | 解決セッション÷回答セッション×100 | 解決確認方法を固定 |
| 離脱率 | 途中終了セッション÷対象セッション×100 | 完了終了と区別 |
| 有人転送率 | 有人転送セッション÷質問セッション×100 | 顧客希望と未回答を分ける |
解決率は回答率と別に測る
回答を表示しても顧客の目的が完了したとは限りません。解決確認、次の行動完了、一定期間内の再問い合わせを使い、回答済みセッションのうち解決した割合を求めます。
数値が悪化したときは、担当者個人の評価へ直結させる前に、流入量、システム障害、ナレッジ、権限、配置を調べます。チャットボットのKPI設計を罰則的に使わず、改善仮説を選ぶための観測値として扱います。
離脱率と有人転送率を読む
離脱した画面、直前の質問、待ち時間を確認します。有人転送率が高くても、複雑案件を正しく渡しているなら問題ではなく、未回答後の強制転送と顧客希望の転送を分けます。
離脱率と有人転送率を読むの数値は、集計画面の名称ではなく計算式で管理します。分子、分母、除外条件、計測開始と終了、集計時間帯を定義書へ残すと、製品変更やチャネル追加後もチャットボットのKPI設計の推移を比較できます。
日常運用では用件別に見る
全体平均では、配送照会の高い解決率が解約相談の低さを隠します。用件、入口、端末、言語、時間帯、初回・再訪に分け、改善するFAQや会話フローを特定します。
日常運用では用件別に見るを改善施策へ結び付けるには、異常値を検知した後の確認順序を決めます。元データ、集計条件、用件構成、要員配置の順に確かめ、原因が特定できない段階で評価や運用ルールを変更しないようにします。
KPIの前提条件をそろえて確認する
チャットボット運用担当者やWeb分析担当者がベンダーへ確認する際は、「対応できますか」と聞くだけでなく、自社の問い合わせ件数、チャネル、権限、例外条件を示して動作を確認します。回答を標準機能、設定、オプション、開発、非対応に分ければ、導入後に必要となる追加作業も把握しやすくなります。
UdeskのSony事例では、AIチャットボット、ライブチャット、統合ナレッジを連携して運用し、公開情報では問題マッチ率80%超、解決率70%超とされています。この事例のように、KPIは利用回数だけでなく、回答が実際の問題解決につながったかまで確認する必要があります。自社でも問い合わせ内容や対象範囲をそろえたうえで、同じ条件で継続的に測定することが大切です。

検証結果と運用変更を記録する
チャットボットのKPIを検証する際は、正常に動作した画面だけでなく、操作日時、入力内容、期待結果、実際の結果、証跡まで保存します。担当者が交代しても同じ条件で再試験できる状態にしておけば、設定変更後や障害復旧時にも同じ基準で確認できます。
KPIの運用ルールも一度決めて終わりにせず、問い合わせ量、顧客行動、組織体制、製品機能の変化に合わせて見直します。変更理由と適用日を記録し、旧ルールで処理中の問い合わせをいつ新しい基準へ切り替えるかも決めておきます。
数値と実際の解決状況を合わせて見る
最終的な評価では通常時の数値だけでなく、繁忙期、担当者不在、外部サービス停止などの例外時も確認します。解決率が高くても、有人転送後の聞き直しや再問い合わせが増えていれば、チャットボットによって対応全体が改善したとは判断できません。
KPIを改善へつなげるには、未回答の質問、離脱、有人転送後の履歴、再問い合わせまで確認し、必要に応じてナレッジや会話導線を修正します。UdeskではAIチャットボットと有人対応、問い合わせ管理を同じカスタマーサービス基盤で運用し、解決率や顧客満足度などをダッシュボードで確認できるため、チャットボット単体の数値ではなく、問い合わせ対応全体を見ながらKPIを見直す構成を検討できます。
FAQ
Q:利用率と起動率は同じですか
A:名称は製品で異なるため、分子と分母を記載して比較します。
Q:解決確認を取れない場合はどうしますか
A:再問い合わせ、次ページ到達、手続完了などの代理指標を用います。
Q:有人転送率は低いほどよいですか
A:複雑案件を適切に移せているなら必要な転送であり、理由別に判断します。
》》Udesk AI チャットボットの無料トライアルを開始するにはクリックし、メリットを実際にご体験ください
本記事はUdeskのオリジナルであり、転載する際は出典を明記してください:https://www.udesk.jp/blog/news/guide/6269/

Customer Service& Support Blog



