サポートナレッジベースのためのAI. サポートナレッジベースのためのAIとは、エージェントが平易な言葉で質問できる社内向けの検索ツールだ。過去のチケット、製品ドキュメント、ポリシーを1回のクエリで検索し、出典を明示した回答を返す。エージェントの背後に控えるものであり、顧客が話す相手はあくまで人間のままだ。
エージェントはシフトの半分をドキュメント探しに費やしている。自分のチームで耳を澄ませたい不満の声だ。答えはどこかにある。古いチケットの中、製品仕様書の中、1月から誰も開いていない配送ポリシーの中。探し出すことが、今や仕事そのものになっている。
なぜエージェントは時間の半分をドキュメント探しに費やすのか
答えが、互いに連携しないシステムの間に散らばっているからだ。返金ルールはポリシーのPDFにある。そのルールを崩す例外事項は、2023年に解決済みになったZendeskのチケットに埋もれている。製品の挙動は、元PMが書いたConfluenceのページにある。複雑なチケットを担当するエージェントは3か所を確認し、どれが最新かを推測し、それが当たっていることを祈るしかない。
サポートナレッジベース向けのAIは実際に何をするのか
チケット、製品ドキュメント、ポリシーをインデックス化し、エージェントが平易な言葉でひとつの質問をすると、ひとつの回答が返ってくる仕組みだ。回答は元になった文書とその箇所に直接リンクしているため、エージェントはワンクリックで検証できる。あくまで社内向けであり、顧客がこれに触れることはなく、話す相手は人間のままだ。
重要なのは出典の部分だ。出典のない回答は、エージェントが結局確認しなければならない推測にすぎない。出典箇所にリンクした回答は、エージェントがワンクリックで確認できる事実であり、そのまま返信に貼り付けられる。まさにこの理由から、私たちはすべての回答を出典元の文書に紐づけている。
初回応答時間にどう影響するか？
説明のために、顧客ではなく、仮定のミッドマーケットのeコマースのサポートチームを考える。過去のチケット、製品ドキュメント、配送ポリシーを1回のクエリで検索する検索ツールが最も効くのは、エージェントが以前は6つのタブを開いてからようやく書き始めていた難しいチケットだ。この立場のチームなら、複雑なチケットの初回応答時間を導入の前後で測定するだろう。
単純なチケットは元から速い。パスワードのリセットや、注文はどこ、といったものだ。ボトルネックは、ポリシーの例外ケースと過去の解決事例を必要とする複雑なチケットにある。そこでの検索時間を削れば、平均が動く。カスタマーサポートのユースケースページに設計の全体像がある。
自分のサポートリードからこの言葉を聞いたなら、返信ツールよりも先に、検索レイヤーから始めるべきだ。
これは結局、顧客向けチャットボットなのではないか
We are
私たちは、エージェントの背後に控える検索レイヤーを構築する。人間が出典付きの回答を読み、確認し、自分の言葉で返信を書く。
We aren't
私たちは、すでに気分を害している顧客の前で、ポリシーを正しく理解できているかどうかも分からないまま単独で回答する顧客向けチャットボットは構築しない。
顧客向けのボットは、ブランドと怒っている顧客との間にモデルを置いてしまう。そこで返金の回答を間違えれば、それは公になるミスだ。検索レイヤーは一歩後ろに控える。エージェントが出典付きの回答を受け取り、エージェントが判断し、エージェントが返信する。リスクが最も高い部分には人間が関わり続け、単に手間のかかる部分だけをモデルが引き受ける。
エージェントの画面に表示されるもの
- キーワード入力欄ではなく、平易な言葉で質問できる検索ボックスがひとつ。
- チケット、ドキュメント、ポリシーを同時に横断して導き出された回答がひとつ。
- すべての回答に、出典箇所へリンクする引用が付く。
- 顧客がこれに触れることは一切ない。チャットボットではなく、エージェント支援ツールだ。
このツールは、あなたの構造化されていない過去の資料をそのまま読み取る。PDFの配送ポリシー、スレッド形式の解決済みチケット、Wikiページの製品ドキュメント。事前に整理したり作り直したりする必要はない。これこそが、新たなナレッジベースを手作業で構築し、永遠に最新の状態に保ち続けるのではなく、検索という手法を選ぶ理由だ。こうした案件はジャーナルでも紹介している。
エージェントが回答するより検索している時間のほうが長いなら、何かを構築する前に、まずあなたの知識が実際にどこにあるのかを洗い出すべきだ。30分のディスカバリー通話を予約してほしい。チケット、ドキュメント、ポリシーを一緒に確認し、検索レイヤーが初回応答時間をどこで動かし、どこでは動かさないのかをお伝えする。
