AI Knowledge Builder

解決済みチケットを
ナレッジベースの記事に。

Knowledge Builderは、チームがすでに解決したチケットを読み取り、エージェントが検索できる記事として書き起こします。同じ質問をした2人目のお客様には、数秒で答えが届きます。

無料トライアルを開始ドキュメントを読む

解決済みチケットクローズ · 2024年3月

#18402 · 注文品が5日間輸送中のまま

対応者：Priya · 返信4件 · 2時間40分

お客様

火曜日から追跡情報が更新されません。「輸送中」と表示されたままです。木曜着の予定でした。

Priya · 社内メモ

配送業者のポータルを確認。最終スキャンは発送元デポで、引き渡しスキャンなし。デポで積み残しになった様子。調査を待たずに再発送する。

Priya · お客様へ

デポで積み残しになっていたため、本日、代替品を速達で発送し、配送料を返金しました。追跡番号は1時間以内にお送りします。

きちんと解決した。そして誰も見つけられない場所に保管された。

生成された記事編集可能

追跡情報が更新されないとき、注文品の所在を確認するには？

何が起きているか

発送元でのスキャンはあるが引き渡しスキャンがない場合、輸送中の紛失ではなく、デポでの積み残しであることがほとんどです。

解決方法

配送調査を依頼せず、速達で再発送します。調査には5〜7日かかり、結局は再発送になるのが通例です。

お客様への補償

デポ側の過失であれば配送料を返金します。商品自体は、お客様のご要望がない限り返金ではなく交換対応です。

チャンク化・ベクトル化済み編集可能 4件のチケットを統合

チケットが1件入れば、記事が1本できます。四半期分の解決済みチケットに向ければ、チームがすでに行った仕事だけでナレッジベースが完成します。

最良のドキュメントはアーカイブの中に眠っている。

輸送中に止まった注文のチケットは、デポのスキャンを確認すべきと知っている担当者によって、一度はきちんと解決されます。しかしクローズされた瞬間、その知識は会話とともに失われます。同じ問題を抱えた次のお客様は同じ列に並び、また一から同じ調査が繰り返されます。

それを記事にまとめる時間は誰にもありません。だから書かれることはなく、翌月にも同じ2時間が費やされます。Knowledge Builderはその執筆作業を、アーカイブ全体の規模で肩代わりします。

注文品が5日間輸送中のまま

2024年3月

決済時に割引コードが適用されない

2024年4月

再試行後に二重請求

2024年6月

30日を過ぎた保証請求

2024年8月

解決済み4,812件 · 検索可能0件

当然の疑問

ほぼ同じ記事が4,000本できてしまうのでは？

いいえ。記事は保存前に比較されます。生成された記事はベクトル化され、そのソースにすでにある記事と照合されます。意味的に近いものがあれば、新しい項目を作らずにその記事へ統合されます。

その結果、同じデポ問題に関する40件のチケットは、40本のほぼ重複した記事ではなく、回を重ねるごとに良くなる1本の記事になります。重複だらけでは、置き換えたはずのアーカイブより検索しづらくなってしまいます。

#18402 注文品が5日間輸送中のまま起点

#19117 月曜から追跡情報が更新されない 0.91

#19640 荷物が動かず、デポに留まったまま 0.89

#20233 1週間、配達スキャンなし 0.87

1本の記事

注文が「輸送中」のまま、追跡情報に動きがない

4件のチケットを統合 · 類似度0.85以上

実際に出てくるもの。

他と同じ普通のソースとして、AI Knowledge Builder のタグ付きでソース一覧に並びます。各記事のタイトルはお客様が実際に尋ねる質問の形です。そのほうが見つけやすいからです。

8月の解決済みチケットナレッジベース

Zendeskのチケットから作成

AI Knowledge Builder 42件の記事

注文品の現在地を確認するには？編集可能

ワークフロー実行後にWebhookが発火しないのはなぜ？編集可能

期限を過ぎた返金依頼にはどう対応する？編集可能

大型商品の配送料はいくら？編集可能

30日間保証の対象範囲は？編集可能

一括インポート後にワークフローが遅延するのはなぜ？編集可能

記事の書き方は2通り。

多くのチケットは、そのまま書き起こすだけで十分です。中には注文内容を実際に調べる必要があるものもあります。だから実行ごとに方式を選べ、料金もそれに応じて変わります。

プロンプトモード

既定

レコード1件につきモデル呼び出し1回。高速・低コストで見通しが立ちます。答えがチケット内にすでに書かれている、アーカイブの大部分に適しています。

チケット1件につき1回の呼び出しなので、コストは線形かつ予測可能
解決内容がスレッド内に説明されている場合に最適
大量の未処理分を、たたき台となるナレッジベースに変える最短の方法

エージェントモード

高精度・低速

お客様自身のエージェントが、執筆前に各レコードを調査します。ナレッジを検索し、注文を取得し、アカウントを確認したうえで、判明した内容から記事を書きます。

チケットに書かれていない文脈を、エージェントの読み取りツールで補完
解決に実際の調査を要したチケットで、明確に精度が上がる
書き込み系ツールは除外されるため、記事生成の実行がチケットを変更することはない

バッチが各レコードに対して行うこと

チケットごとに、5つのステップを順に実行します。最初の2つは、そもそも何も生まないレコードに費用を払わずに済ませるためのものです。

処理済みか？

以前のバッチで記事を生成したチケットはスキップされるため、再実行しても安全です。

価値があるか？

生成前に、自動返信・スパム・内容の薄いスレッドを関連性フィルターが除外します。既定で有効、編集も可能です。

執筆

プロンプトモードはモデルを直接呼び出し、エージェントモードはまず調査してから結果を構造化します。

ベクトル化

タイトルと本文をベクトル化し、キーワードではなく意味で検索できるようにします。

統合または新規追加

既存の記事に近ければ統合し、本当に新しい内容であれば独立した記事になります。

似た名前の4つの機能。中身はまったく違います。

Knowledge Builderは、すでに解決した案件から記事を作成し、次回は検索して答えを見つけられるようにします。

Studies — AI分析

数千件のレコードに1つの分析を実行し、構造化された表を受け取ります。

エージェントシミュレーション

書き込みをすべて抑止した状態で、実際のチケットでエージェントを実行します。

エージェント評価

すでに発生した会話を、エージェント自身の指示に照らして採点します。

こちらについてのご質問 Knowledge Builder について。

簡潔にお答えします。記載のない点はお問い合わせください。率直にお伝えします。

ナレッジベースは知識を「入れる」場所です。ドキュメントをアップロードし、ソースを接続し、サイトをクロールします。一方Knowledge Builderは、すでに手元にあるレコードから知識を「作り出し」ます。その出力は通常のナレッジソースなので、両者は代替ではなく補完関係にあります。

記事は目の前のレコードから書かれ、エージェントモードでは読み取りツールが実際に返した内容に基づきます。すべての記事は編集可能です。最初のバッチはサンプルをご確認のうえ、残りを信頼いただくことをおすすめします。

既定では実行しません。スコープのフィルターは解決済みチケットから始まります。未解決のスレッドには、公開する価値のある答えがないためです。運用が異なる場合はクエリを変更できます。

読み取ります。本当の原因究明はそこに書かれていることが多いためです。記事はスレッドの引用ではなく、解決内容をもとに書かれます。どのフィールドを含めるかは実行ごとに選べます。

はい。各記事はリッチテキストエディタで編集でき、全体をソース一覧から閲覧できます。AI Knowledge Builder のタグが付くため、生成記事とアップロード記事を区別できます。

チームを AI で加速する準備はできましたか?

数分で始められます。ツールを接続し、エージェントを設定すれば、あとは AI が引き受けます。

デモを見る無料トライアルを開始

500 無料クレジット · 期限なし、クレジットカード不要

解決済みチケットを ナレッジベースの記事に。

最良のドキュメントは アーカイブの中に眠っている。