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

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

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

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

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

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

初回応答時間は実際にどれくらい短縮されるのか

構築先のミッドマーケットのeコマースCXチームでは、複雑なチケットの初回応答時間が40%短縮された。アシスタントは4年分の過去のチケット、製品ドキュメント、配送ポリシーのPDFから下書きを作成した。効果が出たのは難しいチケットだ。以前はエージェントが6つのタブを開き、10分読んでからようやく一文字目を書き始めていたような案件だ。

単純なチケットはもともと速かった。パスワード再設定や配送状況の問い合わせなどだ。足かせになっていたのは、ポリシーの例外的なケースとチーム独自の言い回しが必要な複雑なチケットだった。その最初の一手を下書きすれば、平均値が動く。品質も上がった。下書きに、エージェントが探し回っていた情報源そのものが含まれているからだ。

うちのエージェントは、もう空白の入力欄から始めなくなった。今は編集して送るだけだ。

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

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

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

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

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

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