なぜほとんどの企業チャットボットは期待外れなのか—そして代わりに何を構築すべきか

チャットボット導入の落とし穴と成功への道

企業はチャットボットを購入し、ウェブサイトや社内ヘルプポータルに実装します。2週間ほど試用した後、3ヶ月目には、好奇心のある従業員や電話番号を見つけられなかった顧客の少数の利用者しか残らず、利用が低迷します。

このような状況は頻繁に起こるため、その原因を特定する価値があります。問題はモデル自体ではなく、現在のモデルよりも優れた実装にあるのです。失敗の形はシステムの設計に起因します。

チャットボットとビジネスの閉鎖

チャットボットの目的を尋ねると、一般的には「製品に関する質問に応答する」または「従業員がポリシーを見つけるのを助ける」という回答が返ってきます。確かに有用そうに聞こえますが、実際にはそうではありません。

誰かの仕事は回答を提供することではなく、返金処理や購入注文の承認、設置スケジュールの変更、保証請求の確認、または契約書の法的審査などを行うことです。回答はタスクの中間段階に過ぎないのです。回答のみを提供するシステムは、仕事を元の手に戻してしまいます。

そのため、顧客が遅延した注文について質問すると、ボットは配送ポリシーを説明し、顧客は人間とのやり取りを求めます。なぜなら、ポリシー自体が問題の根源ではなかったからです。ボットは設計された機能を果たしましたが、それでも失敗したのです。

3つの失敗パターン

最も失望させる実装にはいくつかの共通点があります。

ライブシステムへのアクセスがない。 ボットは文書に基づいて訓練されます。顧客の質問は自分の注文や請求書、口座に関するものです。ライブ注文システムにアクセスできないボットは、一般的な情報しか提供できず、FAQページで既に得られる情報と同じです。
行動する能力がない。 答えを知っていても、それを実行できません。会話は常に人間への引き継ぎで終わり、作業の効率化には繋がりません。
「完了」の定義がない。 事前に良い結果の定義が合意されていないため、システムのパフォーマンスを評価することはできません。利用者数は増加し、コールセンターの問い合わせ量は減少しません。プロジェクトは静かに議論されなくなるのです。

これらの3つすべてには、プロジェクトが「チャネル」としてではなく「容量」として定義されたという1つの決定が根底にあります。

タスク完了型システムを構築する

代替案はより単純なものです。より狭く、深く焦点を当てたものです。

高頻度のタスク1つを選びましょう。「配送の再スケジュール」ではなく、「物流に関する質問」ではありません。月数回発生し、分かりやすい手順に従うタスクです。

システムに2つの重要な機能を提供します。真実を保持するシステムへの読み取りアクセスと、タスクに必要な1つまたは2つのアクションへの書き込みアクセスです。配送を検索し、実際のスケジュールを提供し、予約を変更できるのであれば、電話による問い合わせを置き換えることができます。ポリシーを説明するだけでは何も置き換えられないのです。

さらに、システムがタスクを完了できない場合にどのような対応を取るかを定義しましょう。これはほとんどのプロジェクトが省略する重要な部分ですが、信頼を築く上で大きな役割を果たします。低信頼度、異常な口座状態、または金額が一定以上の取引など、システムが人間に引き継ぐべき条件を設定し、引き継ぎ時に顧客が同じことを繰り返さないように十分な文脈を提供しましょう。1件のタスクをきれいに完了してから人間にエスカレーションするシステムは、100%のタスクを試みてそのうち50%を間違えるシステムよりも優れています。

最後に、構築前に数値目標を設定しましょう。再スケジュール要求の完了率、エスカレーション時の平均処理時間、48時間以内の再連絡率などです。月前のデータと比較して、改善が見られない場合は、安価に早期に学ぶことができます。

計画への影響

このようにスコープを設定すると、プロジェクトは小さくなり、統合作業が大きくなります。これはチャットボット購入を期待していた人にとっては不快な状況です。会話層は今や簡単な部分です。システムの権限、システムアクセス、監査証跡、エスカレーション経路などの地味な作業が重要なのです。

それが狭い方が優れた理由もここにあります。1つのタスクを完全にこなしたシステムは、2番目のタスクを追加する権利を獲得します。40のトピックを浅くカバーするシステムは何の価値もありません。なぜなら、誰かが指を指して「このタスクが以前に比べて4分短縮された」と言えるような単一のタスクがないからです。

私たちは後者のシステムを構築します。前者は導入しやすいですが、維持するのは非常に難しいのです。