サポート返信向けAI——編集して送信するのはエージェント

カスタマーサポート返信向けAI. カスタマーサポート返信向けAIは、担当エージェントのために最初の返信を書く下書き・レビュー型のツールだ。開いているチケットを読み、過去の返信、製品ドキュメント、ポリシーから引用し、チームの声で下書きを書く。エージェントがそれを編集して送信する。チケットには常に人が関わる。

12人のエージェントは、毎回空白の入力欄から返信を書き始めている。これが足かせになっている。答えはたいてい過去のチケットや配送ポリシーのPDFの中にすでにある。それを今週100回目に、正しいトーンでもう一度書き起こす作業が、シフトの時間を食いつぶしている。

下書き・レビュー型の返信アシスタントは実際に何をするのか

書くのは最終的な返信ではなく最初の下書きだ。チケットが届くと、アシスタントがそれを読み、過去の履歴とドキュメントから該当する答えを見つけ、書き上げた返信をエージェントの返信欄に入れる。エージェントはそれを読み、誤りを直して送信する。顧客がモデルと話すことは一切ない。話す相手は自社のエージェントであり、そのエージェントは今や、空白の行で点滅するカーソルではなく下書きから始められる。

この違いこそが設計のすべてだ。顧客向けボットが返金について誤った答えを出せば、それはすでに不満を抱えている相手に送られる公然のミスになる。下書きの中の誤った一文は、送信される前にエージェントが見つける。モデルは下書きを書く。人が判断する。レビューという工程はオーバーヘッドではなく、これこそが製品そのものだ。

初回応答時間にどう影響するか？

説明のために、顧客ではなく、仮定のミッドマーケットのeコマースのサポートチームを考える。過去のチケット、製品ドキュメント、配送ポリシーのPDFから下書きを作るアシスタントが最も効くのは、エージェントが以前は6つのタブを開いて読んでからようやく書き始めていた難しいチケットだ。この立場のチームなら、複雑なチケットの初回応答時間を導入の前後で測定するだろう。

単純なチケットは元から速い。パスワードのリセットや、注文はどこ、といったものだ。ボトルネックは、ポリシーの例外ケースと、チームが実際に使う言い回しを必要とする複雑なチケットにある。その最初の下書きを作れば、平均は動くはずだ。下書きにエージェントがこれまで掘り起こしていた出典が付いてくるので、品質も上がりうる。

テストは単純だ。エージェントは空白の入力欄から始めなくなったか。代わりに編集して送るだけになったなら、その下書きは役目を果たしている。

#これはZendesk AIやIntercom Finと同じではないのか

Zendesk AI、Intercom Fin、Gorgiasの提案機能は、それぞれ自社のマクロとヘルプセンターの記事から下書きする。簡単なチケットには役立つ。だが難しいチケットには、2023年に解決した過去のチケットや、1月以来誰も開いていないポリシーPDFが必要になる。全履歴を読み込む下書きと、マクロ一覧しか読まない下書きとは、まったく別のツールだ。

構築後、返信アシスタントは誰のものになるのか

• コードはあなたのものになる。AI導入の仕事では、永遠に借り続けるツールではなく、アシスタントとリポジトリそのものを引き渡す。
• エンゲージメント内のトレーニングで、サポートチームが私たちを呼び戻すことなく、運用し、声のトーンを調整し、新しいドキュメントを追加できるようになる。
• アシスタントはエージェントの後ろに位置するので、返信の読み口を変えたくなった日には、ベンダーのロードマップではなくエージェントが下書きを編集すればいい。

引き渡しの狙いは、私たちが去った後もツールが劣化しないことだ。エージェントが毎日新しいチケットを投入し続けるので、実際に送信された返信からチームの声を学び続ける。この返信アシスタントは、カスタマーサポートの取り組みの中でエージェント向けに構築したいくつかの仕組みの一つだ。同じエージェントの後ろに位置する検索やトリアージとも、無理なく組み合わさる。

12人のチームが返信量に埋もれていて、顧客の前にチャットボットを置くことなく初回応答時間を短縮したいなら、一緒にマッピングすべきだ。30分のディスカバリー通話を予約してほしい。1行もコードを書く前に、チケット履歴とドキュメントを確認し、下書き・レビュー型のアシスタントが正しい解決策かどうかを見極める。