想定事例: サポートチームのためのエージェント側検索

想定事例. これは説明用の想定事例であり、顧客の実績ではありません。サポートチームも数字も仮定です。エージェント側検索とは、顧客の前ではなくサポート担当の後ろに置くツールです。担当者が普通の言葉で質問し、出典付きの回答を受け取り、チケットに留まったまま自分で返信を送ります。

チケットの中でも複雑なものの初回応答時間を改善したい、中堅のeコマースCXチームを思い浮かべてください。この記事では、設計が何で構成されるか、何を測るか、何をしないかを扱います。結果は報告しません。背後に顧客がいないからです。

チームは架空であり、ここで期待されそうな数字もすべて同様です。設計は、/ai-for/customer-supportで説明しているカスタマーサポートの取り組みを土台にしています。最初にもう一点。これは担当者支援に限ります。顧客と話すチャットボットは、どの場面にも登場しません。

エージェントの足を引っ張っていたものは何か

答えは存在しています。見つけるのがスケールしないのです。複雑なチケットでは、担当者がZendeskの履歴、製品ドキュメント、配送ポリシーのPDFを開き、手作業で答えをつなぎ合わせます。過去数年分のチケットに前例があるのに、顧客が待つ時間内にそのアーカイブを検索できる人はいません。

そのため、エージェントが探し回っている間、最初の返信はキューに滞留していました。この待ち時間こそ、サポートリードが問われる数字です。チケット件数ではなく、初回応答時間です。

設計は何で構成されますか?

三つの情報源にまたがる社内検索ツールが一つあります。過去のチケット、製品ドキュメント、配送ポリシーのPDFです。担当者は、経験豊富な同僚に聞くのと同じように質問を入力します。回答は出典付きで返るため、担当者は顧客に届く前に確認できます。

• 過去のチケット全体を、タブごとではなく一回の検索で調べられます。
• 出典付きの回答なので、担当者はブラックボックスを信じるのではなく出典を確認できます。
• 例外ルールが実際に書かれている配送ポリシーのPDFに根拠を置いた回答です。
• 担当者はチケットに留まります。ツールが自分で顧客に返信することはありません。

サポートチームの研修は設計の一部であり、最後の引き渡しではありません。合意すべきKPIは、複雑なチケットの初回応答時間で、導入の前後に測ります。何がどれだけ動くかは、この記事ではなくあなた自身のデータが答えます。

これは、いわゆる問い合わせ削減ボットと同じではないのか

いいえ。その違いこそが要点です。ディフレクション施策は、顧客に直接答えることでチケット量を減らそうとします。この設計が狙うのは別の数字、初回応答時間であり、担当者の後ろに検索を置くことで実現を目指します。顧客は引き続き人と話します。

Zendesk AI、intercom fin、gorgiasの提案などのツールは、自社の壁の内側で動きます。つまり、あなたのマクロ、ヘルプ記事、保存済み返信です。この設計は、それ以外の部分に検索を広げます。過去のチケット、製品ドキュメント、配送ポリシーのPDF、ランブックです。複雑なチケットの答えが隠れているのはそこです。

私たちが動かすKPIは、複雑なチケットにおける初回応答時間と解決品質であり、人員数ではありません。それを初日に伝え、実際に計測します。

私たちのサポートチームにも通用するのか

適合テストは単純です。答えがすでに、検索しにくい場所にありますか。数年分のチケット、ポリシーPDFの山、変わり続ける製品ドキュメント。複雑な返信の前に担当者が何分も探し回っているなら、検索が取り戻そうとしているのはその時間です。

この設計は私たちのAIコンサルティングの取り組みに属し、サポートチームの研修はAIトレーニング側から組み込みます。各要素のつながりを見たい場合は、ジャーナルにこうした想定事例がほかにもあります。

複雑な返信の前に、担当者が答えを探し回っているなら、この設計が狙うのはその遅れです。何を作っているか教えてください。検索が効くレバーなのか、そうでないのかをお伝えします。