窓口とナレッジの置き場所は、作る前に決める
QA を書き始める前に、どの窓口でどのナレッジを参照させるかを決めます。個人の顧客と法人の顧客で回答が違うなら、チャットボットや FAQ の窓口をあらかじめ分け、窓口ごとにナレッジのフォルダを用意します。
＜窓口とフォルダの構成＞
窓口を分ける利点は、相手が誰かを入口で決められることです。ユーザーがアクセスした時点で相手が特定できれば、AI も対象のフォルダに絞って答えを探せます。
顧客向けと社内向けは、フォルダごと分ける
次に、顧客に見せてよい情報と、社内だけで使う情報を分けます。分ける単位は QA ではなく、フォルダです。
フォルダ | 入れるもの | 参照する AI |
|---|---|---|
顧客向け | 顧客に公開してよい情報だけ | 顧客向けのチャットボットは、顧客向けのフォルダだけを参照する |
社内向け | 判断基準・確認先など、社内限定の情報 | オペレーター向けの AI 検索は、両方を横断して参照する |
1つの QA の中で「ここは顧客向け、ここは社内向け」と出し分ける方法もあります。ただし、細かく出し分けようとすると、社外秘の情報を誤って答えてしまうおそれがあります。
入れないものも決めておきます。AI は置かれたデータを忠実に参照するので、機密情報や古い版の資料は、最初からフォルダに入れません。
答えられなかった問い合わせは、5つの原因に分けて直す
運用が始まったら、メンテナンスの周期を決めて、チャットボット・FAQ の検索・対応のログから、答えられなかった問い合わせを集めます。集めたら、まず原因で分けます。
答えられない問い合わせが出るのは、運用の失敗ではありません。支援の現場で、顧客が答えにたどり着けない原因で一番多いのはナレッジが無いことで、顧客の質問は想定よりずっと自由で幅広いからです。
# | 原因 | 打ち手 |
|---|---|---|
1 | 見つからない（答えはあるのに検索や導線で届いていない） | 検索・導線の改善 |
2 | 答えがない（該当するナレッジが存在しない） | ナレッジの作成 |
3 | 答えが合わない（内容が古い・条件に合っていない） | 内容の更新 |
4 | 答えが散らばる（似たナレッジが重複している） | 統合・整理 |
5 | 同じ問題が起き続ける（商品や業務の仕組みに原因がある） | 商品・業務の改善 |
5つのうち FAQ を新しく作るのは、2の「答えがない」だけです。1・3・4は既存のナレッジや検索を直す話で、5はナレッジの外の話です。
原因はログのサインで見分け、問い合わせ量 × 未解決 × 影響の順に直す
原因は、担当者の感覚ではなく、ログに出るサインで見分けます。
＜原因とログのサイン＞
検索ゼロ件、FAQ を見ずに問い合わせ → 見つからない
同じ質問の有人移行が続く → 答えがない
「役に立たなかった」の評価が多い → 答えが合わない
検索で複数ヒットし、回答がばらつく → 答えが散らばる
同じ不具合・不満が繰り返し届く → 同じ問題が起き続ける
具体例
返品条件の QA が3件に分かれている
検索すると3件ともヒットし、チャットボットの回答が質問ごとにばらつく。検索で複数ヒットし回答がばらつくのは、答えが散らばっているサインなので、新しく足さずに1件へ統合します。
※ 説明のための例です（数字や設定は例示）
原因が分かっても、すべては直せません。問い合わせ量（問い合わせ・検索の多さ）× 未解決（有人移行・低評価の多さ）× 影響（呼量・工数・顧客への影響）が大きい順に直します。
5つ目の原因に当たる問い合わせは、ナレッジの担当だけでは直せません。商品や業務の担当部署に、件数と内容を添えて渡します。
重複と食い違いは、追加のたびに照合する
直す作業が続くと、ナレッジの重複や食い違いも増えます。年に1回ナレッジを全件洗い出す総点検では、次の点検までの1年間に重複や矛盾がたまります。
＜重複と食い違いの防ぎ方＞
代わりに、最初に一度全体を整理し、追加や更新のたびに AI で既存のナレッジと照合します。似た内容があれば統合し、無ければ新規作成と判断し、定期的に自動の重複チェックも走らせます。
AI が案を出し、人が承認する分担で回す
ここまでの作業を、人手だけで続けるのは難しいものです。ログが膨大で読み切れない、重複や古い記載に気づけない、更新が後回しになる、という壁があります。
＜AI と人の分担＞
そこで、AI がナレッジの作成・更新・整理・削除の案を出し、人が判断して承認する分担にします。ログを読む・不足を見つける・案を作るのは AI、反映してよいかを決めるのは人です。
- 1
ログを集める
会話・検索・有人移行のログを、決めた周期で集めます
- 2
原因に振り分ける
ログのサインで5つの原因に分け、5つ目は商品・業務の担当部署へ渡します
- 3
順番を決める
問い合わせ量 × 未解決 × 影響の大きい順に並べます
- 4
AI の案を人が承認する
作成・更新・整理・削除の案を、根拠のログとあわせて確かめ、承認したものだけを反映します
- 5
反映のたびに照合する
追加・更新した QA を既存のナレッジと照らし、統合か新規作成かを決めます
チェックリスト
運用と改善の確認
＜この記事のまとめ（ナレッジ管理の運用）＞
QA の書き方は「FAQの書き方」、何から作るかは「ナレッジの作り方」の記事で紹介しています。
よくある質問
Q個人向けと法人向けで、同じ QA を使い回してもよいですか。
回答が違うなら、窓口を分けて窓口ごとにフォルダを用意します。窓口で相手が特定できれば、AI も対象のフォルダに絞って答えを探せます。
Q答えられなかった問い合わせには、FAQ を足せばよいですか。
FAQ の作成が打ち手になるのは、該当するナレッジが無いときだけです。見つからない・合わない・散らばるなら、検索や内容や整理を直します。
Q商品の不具合についての問い合わせが続くときは、どうすればよいですか。
同じ問題が起き続けるのは商品や業務の仕組みに原因があるので、ナレッジではなく商品・業務の改善につなげます。
Q重複のチェックは、どのくらいの頻度で行えばよいですか。
追加や更新のたびに既存のナレッジと照合し、それとは別に定期的な自動の重複チェックも走らせます。
