初回応答時間を40%短縮、チャットボットなしで

エージェント側の検索. 顧客の前ではなく、サポートエージェントの後ろに控えるツールです。エージェントは平易な言葉で質問し、1回の検索で出典付きの答えを得ます。顧客向けのボットはありません。エージェントはチケットの中にとどまり、返信を送ります。

私たちはこれを、ミッドマーケットのeコマースCXチームのために構築しました。複雑なチケットの初回応答時間は40%短縮されました。この記事はその証拠です。何を構築し、何が動き、何が動かなかったのか。

クライアントは匿名化しています。40%という数字は、/ai-for/customer-supportで説明しているカスタマーサポート関連の取り組みに基づく、この案件で実際に達成された成果です。もう一つ最初にお伝えしておくと、これはエージェント支援のみです。どの段階でもチャットボットが顧客と話すことはありませんでした。

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

答えは存在していました。それを見つける作業がスケールしなかったのです。複雑なチケットとは、エージェントがZendeskの履歴、製品ドキュメント、配送ポリシーのPDFを開き、答えを手作業でつなぎ合わせることを意味していました。4年分の過去のチケットには前例が眠っていました。しかし顧客が待つ時間の中で、4年分のチケットを検索できる人はいませんでした。

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

実際に何を構築したのか

3つの情報源を横断する、1つの社内検索ツールです。4年分の過去のチケット、製品ドキュメント、配送ポリシーのPDF。エージェントは、先輩の同僚に尋ねるような感覚で質問を入力します。答えは出典付きで返ってくるので、顧客に届く前にエージェントが確認できます。

• 4年分の過去のチケットを、タブを切り替えることなく1回の検索で横断できる。
• 答えには出典が付くので、ブラックボックスを信じるのではなく、エージェントが情報源を確認できる。
• 答えは、例外的なルールが実際に記載されている配送ポリシーのPDFに基づいている。
• エージェントはチケットの中にとどまる。ツールが自ら顧客に返信することは決してない。

サポートチームのトレーニングは、最後に引き渡す作業ではなく、構築の一部として組み込みました。動かすと合意したKPIは、複雑なチケットの初回応答時間でした。導入前後で計測したところ、40%低下していました。

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

違います。そしてその違いこそが本質です。問い合わせ削減の手法は、顧客に直接答えることでチケット件数を減らそうとします。今回動かしたのは別の数字です。指標は初回応答時間で、それは検索機能をエージェントの後ろに置くことで実現しました。顧客は引き続き人間と話していました。

Zendesk AI、Intercom Fin、Gorgiasの提案機能といったツールは、それぞれ自社の壁の中で動きます。マクロ、ヘルプ記事、保存済みの返信テンプレートです。私たちは、その外側にある残りの部分を横断する検索を構築しました。過去のチケット、製品ドキュメント、配送ポリシーのPDF、運用手順書。複雑なチケットの答えは、そこに隠れています。

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

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

適合するかどうかの判断は単純です。答えはすでに存在しているが、検索に時間がかかる場所に置かれていませんか。4年分のチケット、大量のポリシーPDF、変わり続ける製品ドキュメント。複雑な返信を送るたびにエージェントが探し回って数分を失っているなら、その数分こそ検索機能が取り戻してくれるものです。

この構築は私たちのコンサルティングの取り組みに含まれ、サポートチームのトレーニングはトレーニング側から組み込まれています。全体がどうつながるかを見たいなら、ジャーナルに他の事例も掲載しています。

複雑な返信を送るたびにエージェントが答えを探し回っているなら、それはまさに今回私たちが追い求めた40%です。何を構築しようとしているかをお聞かせください。検索機能が有効な手段かどうか、正直にお伝えします。