問い合わせが減ったのに顧客は困っている――ヘルプデスクを自動化する前に決めたい、人へ渡す境界
例えば、チャットボットを導入した翌月、有人窓口への問い合わせが減ったとする。管理画面には高い自動対応率が並ぶ。一方で営業には「何度聞いても同じ案内しか返ってこない」という電話が届く。このとき減ったのは、解決に必要な仕事なのか、それとも窓口にたどり着けた顧客なのか。
ヘルプデスクの自動化で最初に決めたいのは、人を何割減らせるかではない。どの用件なら機械とのやり取りだけで完了でき、何が起きたら人へ引き継ぐかである。本稿は、担当者を支援するAIの研究と、実際のサービス指標の定義を材料に、この境界を考える。
本稿の提案は、結果を確かめられ、誤りを修正しやすい用件から自動完結を試すことだ。権限や契約の例外を判断する用件は、AIが情報をそろえ、人が決める構成から始める。これは業種共通の効果が実証された処方箋ではなく、証拠の適用範囲を踏まえた運用案である。
この記事の目次
「解決率」の中に、返事をやめた顧客が入っていないか
自動化の評価を難しくするのは、同じ「解決」という言葉でも、計測している行動が違うことだ。
Intercomの公式説明では、Finの解決を、利用者から肯定的な反応を得た場合と、一定の条件で解決したと推定する場合に分けている。さらに、有人対応へ流れなかったことを示すdeflectionには、回答前の離脱や否定的な反応後の離脱も含まれる。これは同社の製品上の定義であり、他社製品にも同じ定義があるという意味ではない。Intercom「Reporting metrics & attributes」
この違いから導かれるのは、「高い自動対応率は無意味」という結論ではない。人へ来なかった理由を、解決と離脱に分けて読む必要があるということだ。画面を閉じた人が満足したのか、諦めたのかは、その行動だけでは確定できない。
例えば請求書の再取得なら、必要な書類を利用者が取得できたことを確認しやすい。契約の解釈について質問した人が退出した場合は、同じようには扱えない。前者でも、別の月の書類を取った可能性は残るため、取得操作と利用目的の達成を同一視しないことが大切だ。
最初の報告書には、応答件数だけでなく、完了を確認できた用件、推定にとどまる用件、有人へ渡した用件を分けて載せたい。問い合わせが別の電話番号や営業担当へ移った可能性も、同じ顧客・同じ用件で追える範囲で確認する。追跡できない退出は、解決にも不満にも決め付けず「不明」と残す。測れない顧客を集計から消すと、見えている成功だけで対象を広げる判断になってしまう。
人を支援するAIの成果は、無人化の成果ではない
自動化に慎重であることと、AIの効果を否定することは違う。
Brynjolfssonらの研究では、顧客対応担当者5,172人への生成AI支援の段階的導入を分析し、1時間当たりの解決件数が平均15%増えたと報告している。経験や技能が低い担当者の改善が大きい一方、最も熟練した層では速度の小幅な改善と品質の小幅な低下が見られた。ここで参照するのは2024年11月改訂版である。Generative AI at Work
対象は米国のソフトウェア企業の顧客対応で、担当者の多くはフィリピンで勤務していた。2019~2021年のデータを使い、導入した担当者と未導入の担当者の変化を比較した分析である。人が顧客に対応する仕組みであり、直接回答するボットへ置き換えた実験ではない。日本のすべての窓口で同じ改善率になるとは言えない。
この研究を人員削減の計算へ直接使うより、まず「人へ渡した後の対応を支援する」という選択肢として読む方が、研究対象に近い。担当者に関連資料や回答候補を提示し、顧客の状況に適合するかを判断してもらう。熟練者については、提案を読む手間や不適切な提案への修正が増えていないかを別に見る必要がある。
自動完結と担当者支援は、導入段階の優劣ではない。必要な判断を誰が担うかが異なるサービス設計である。
用件の難しさより、誤ったときに何が起きるか
FAQに載っているから自動化してよい、という分け方では粗い。同じ手順案内でも、営業時間の確認と管理者権限の変更では、誤った場合の影響が違う。
以下は本稿の判断案である。機械が文章を生成できるかに加え、正しい参照先、利用者の権限、完了の確認方法を用件ごとにそろえる。
| 用件の状態 | 最初に選ぶ構成 | 人へ渡す契機 |
|---|---|---|
| 参照する情報が定まり、結果を確認できる | 範囲を限定して自動完結を試す | 結果が確認できない、同じ用件が再発する |
| 情報収集は定型だが、対応の選択に裁量が要る | AIが整理し、担当者が判断する | 判断の工程は初めから人が担う |
| 誤りの影響が大きい、例外条件が未整理 | 有人対応を入口にする | 自動化する前に判断責任と権限を整理する |
ここでいう確認は、ボットが「解決しました」と出力することではない。請求書を取得できた、申請が正しい宛先へ届いた、といった業務上の結果だ。利用者が人との対応を求めた場合に進める経路も用意する。
引き継ぎ時には、質問内容、既に試した操作、提示した資料、未解決の点を担当者へ渡す。ただし会話を丸ごと転送すればよいわけではない。必要な情報と閲覧できる担当者を決め、無関係な個人情報まで広げない構成にする。
600件を自動化しても、600件分の仕事は減らない
仮に、月1,000件の用件を人が1件10分で処理し、合計10,000分かかっている窓口を考える。以下は仕組みを説明する仮定であり、導入実績ではない。
600件をボットへ案内し、そのうち400件が自動完結、200件が人へ引き継がれたとする。引き継ぎ後は経緯確認を含め1件12分、直接人へ来た残り400件は従来どおり10分かかる。さらに、ボット用情報の整備と回答点検に月1,500分を使うとする。
人の作業は、200件×12分+400件×10分+1,500分=7,900分になる。削減は2,100分であり、ボットに案内した600件×10分の6,000分ではない。この仮定の範囲なら、自動完結した用件を維持しつつ、引き継ぎの手間を減らす方向に意味がある。
ところが、商品改定が頻繁で、情報整備と点検に4,000分必要なら、合計は10,400分になる。ほかの条件が同じなら、同じ範囲の自動化を維持する時間上の利益はなくなる。この場合は更新の少ない用件に絞るか、担当者支援へ切り替える候補になる。
この計算は利用料や顧客の待ち時間、誤回答の損失を含まない。実際の採否では、それらを別に比較する。対応が速くなり顧客の業務停止を短くできるなら、人の時間が減らなくても価値がある。一方、時間を節約しても重大な誤案内が生じるなら、時間の収支だけでは継続を決められない。
問い合わせを抑える目標から、適切に終える目標へ
試行では、用件の種類をそろえた比較を行いたい。簡単な用件だけをボットへ渡し、その結果を有人窓口全体と比べると、仕組みの効果と用件の差が混ざる。可能なら同種の用件で案内方法を比較し、難易度や営業時間の違いも記録する。
運用上の拡大判断は三つに分けられる。完了の確認と引き継ぎが機能し、利用者の負担も増えない用件は範囲を広げる。解決しているが維持費が重い用件は、更新方法や対象を見直す。誤回答や引き継ぎ不能で顧客の行動を止める用件は、自動完結を止めて人へ戻す。具体的な許容水準は、用件の影響と既存サービスの約束に照らして導入前に決める。
ボットに任せる範囲は、答えられる質問の数で広げるのではなく、結果を確かめ、失敗を人が引き受けられる用件から広げる。 問い合わせの減少はその結果として評価する。顧客が人に届かなかったことを、自動化の成功に数えない窓口を設計したい。