現場の会話からFAQを作る。商談ログとチャットログを資産化する

FAQを作ろうという話は、どの組織でも一度は出るものの、たいていは作られないまま終わります。
理由は時間で、質問を集めて答えを書いて確認する工程を回すと、20件でも数日かかります。
「作る時間がない」まま、同じ質問に個別に答え続けることになります。

今回は、商談ログをFAQ作成の元データにして、現場の会話から資産を起こす進め方について書いていきます。
社内のAIボットを共通資産にする全体像のほうは社内AIボットを共通資産にする。作成・共有・改善のサイクルにまとめてあります。

FAQを作る時間がない

工程は3つに分かれていて、「質問を集める」「答えを書く」「内容が正しいか確認する」という並びになります。
自社のFAQ作りは、どの工程で止まっているでしょうか？

最初の工程に、最も時間がかかります。
記憶を頼りに書き出すことになるので、時間がかかるうえに網羅もできません。

さらに、思い出しながら書き出すと実際に多い質問が抜けます。
印象に残っている質問と、件数が多い質問は別物だからです。
例えば一度だけ聞かれた難しい質問は覚えていても、毎週来ている単純な質問のほうは意識に上りません。
だから対処の中心は、この工程を記録から取ることになります。

商談ログとチャットログをFAQ作成の元データにする

社内には既に、質問と答えの記録が揃っています。
商談の記録には、顧客が聞いたこととそれに対して答えたことが残っています。
チャットのログには、社内で聞かれたこととそれに答えたことが残っています。
メールのやり取りには問い合わせと回答が残っていますし、サービスの資料には説明されている内容そのものが載っています。

このなかでも商談・チャット・メールの3つには、来た質問がそのまま入っています。
記憶ではなく事実として残っているということです。

答えのほうも一緒に入っています。
その場で誰かが答えた内容が記録されているので、質問を集める工程が不要になりますし、答えを書く工程も既にあるものを元にできます。
これが、最も効率的なFAQの作り方だと思います。

規程やマニュアルの側から起こす方法は規程やマニュアルからFAQを量産する。問い合わせ対応の元データ作りにまとめてあります。

商談ログ → チャットログ → サービス資料との統合

最初は商談の記録からです。
渡して、聞かれた質問と答えを抽出させます。

ここで集まるのは対外的な質問、つまり顧客が知りたいことです。
件数のほうも分かります。
同じ質問が何件来ているかが出るので、上位10件がそのまま最も価値のある質問になります。

さらに答えのばらつきも見えてきます。
同じ質問に対して、担当者によって違う答えを返している状態です。
これが最も重要な発見で、ばらつきがある質問を優先してFAQ化すると、一貫性のない回答が社外に出ている状態を解消できます。

直近3か月の商談記録から上位20件を抽出するのに、2週間を見ておきます。
複数の答えがある場合は、正しいものを1つ選びます。
ここが、人がやる判断の工程です。

商談の記録そのものを資産にする話は商談内容を全社の資産にする。文字起こし→要約→記録の自動化で扱っています。

次はチャットのログで、こちらからは社内向けの質問が集まります。
手続き、規程、システムの使い方といったところが中心になります。
同じ質問が繰り返されている箇所が分かるので、繰り返しの回数がそのまま優先順位になります。

複数の人が別々に答えていて、答えが分散している箇所も見えてきます。
また、未回答のまま流れた質問を拾えるのも重要です。
誰も答えないまま流れた質問こそが、最も見落とされている困りごとだからです。

対象のチャンネルは業務の相談が流れるものに絞って、雑談は対象外にします。
ログの蓄積が前提になるので、蓄積されていない場合はまずそこから始めます。

チャットログの蓄積そのものはチャットに流れた知見を消さない。ログを組織のナレッジに変えるにまとめてあります。

最後にサービスの資料や規程と統合していきます。
集まった質問のうち、答えが記録に残っていないものを資料から補完します。
そこでも埋まらない「資料に書かれていない質問」が残ります。
ここが最も重要な部分です。

その扱いは3つに分かれます。
説明が不足していたものは資料に追加する、資料に載せる内容ではないがよく聞かれるものはFAQとして独立させる、個別の判断が必要なものは相談先を返す形にする、という3つです。
最後を区別するのが重要で、すべてを文書化しようとすると判断そのものを文書に押し込むことになります。
資料の不足が可視化されるのが、この工程の副産物になります。

FAQは正しさと鮮度と公開範囲を確認して、四半期ごとに更新する

作った後の確認は4つあります。
「答えが正しいか」（その領域を分かる人が確認するところで、ここは省けません）「答えが最新か」（商談の記録は過去のものなので、条件や価格が変わっている可能性があります）「対外的に言ってよい内容か」「根拠が示されているか」（規程の条項、資料の該当箇所）です。
このなかでも「対外的に言ってよい内容か」が、最も注意の要る観点になります。
商談では相手との関係の中で答えた内容が、一般に公開すると問題になることがあるからです。

だから社内向けと社外向けは、答えを分けて持ちます。
同じ質問でも、出す相手によって答え方が変わってくるからです。

根拠を入れておくと、後の更新が楽になります。
根拠が変わったときに、影響するFAQをそこから特定できるからです。

根拠を参照して答えさせる仕組みそのものは回答の一貫性を担保する。社内文書を根拠にした返答の仕組みにまとめてあります。

更新は四半期に一度、直近3か月の記録から新しい質問を抽出します。
あわせて、既にFAQにある質問の件数も見ておきます。
減っていればFAQが機能していますし、減っていないならFAQが見られていないということになります。

さらに答えが変わった質問も検出します。
記録の中の答えがFAQと違う場合に、どちらが正しいのかを確認します。
たいていは、現場のほうが正しいものです。
現場は最新の情報で答えているのに、FAQのほうが更新されていない形になるからです。

更新のオーナーは、領域ごとにその根拠の資料を所管する部門に決めておきます。

この作業に使える業務ツール「FAQ自動生成」は、詳しいページでできることと使い方を紹介しています。

FAQ作りで見えてくる3つと、つまずきは7つ

FAQを作る過程では、3つのことが分かります。
「答えのばらつき」（同じ質問に違う答えを返している）「資料の不足」（説明されていない内容）「判断が必要な質問」（文書化できず、判断の基準が要る箇所）です。
なかでも答えのばらつきが、最も価値のある発見かと思います。
一貫性のない回答が社外に出ている状態が、そこで初めて見えるからです。

ばらつきが見つかった場合は、FAQを作る前に正しい答えを決めます。
ここが判断の工程で、決める人はその領域の責任者になります。
ただ、ここは推進担当が決めてよい領域ではありません。

さらに、なぜその答えにしたかも記録しておきます。
後から判断の前提を確認できるようにするためです。

つまずきは7つあります。
「質問を記憶から書き出す」「答えを新しく書く」「答えのばらつきを無視する」「商談で答えた内容をそのまま公開する」「判断が必要な質問を文書化する」「根拠を示さない」「推進担当が答えを決める」です。
どれも記録から取って、既にある答えを元にして、先に正しい答えを決めて、社外向けは別に整えて、相談先を返す形にして、条項を添えて、責任者に決めてもらえば避けられます。

作ったFAQを全社から引ける場所に置く

ここまで書いてきたとおり、FAQそのものは既にある記録から作れます。
問題になるのは、作った後をどう置くかのほうかと思います。
部門ごとに作ったFAQは、そのまま部門の中に閉じます。
営業が作った顧客向けのFAQをサポートが知らなければ、結局そこで違う答えが返るからです。

さらにFAQがどこにあるか分からないという状態も起きます。
探せないものは、置いてあっても使われないからです。

新しく入った人には、そもそも届いていません。
配布物として配ったものは、後から入った人には伝わらないからです。

もちろん、各自がコピーを持っている場合は、更新も反映されません。
必要なのは、領域別に探せて、更新すれば全員に反映される状態です。

マニュアルの側を作り続けられる状態にする話はマニュアルを作り続けられる組織になる。操作録画から自動生成するにまとめてあります。

領域別に探せる状態を作るために、私たちが提供している組織のAIポータル「AI Portalize」では、検証済みの見本と社内で作ったAIツールを、やりたいことから検索できるようにしています。
作ったが使われていない、という状態で止まっている場合は、考え方の参考になるかもしれません。

記録から起こしたFAQは、探せる場所に置いて育てる

FAQが作られないのは、質問を集める工程に最も時間がかかるからです。
記憶を頼りにすると、実際に多い質問のほうが抜けます。
対処は、既にある会話ログのほうを元データにすることになります。
商談の記録、チャットのログ、メールのやり取り、サービスの資料のうち、前の3つには実際に来た質問と、その場で答えた内容が入っています。

進め方は3フェーズです。
最初は商談ログを使い、対外的な質問を集めて、答えのばらつきを見ます。
次はチャットログを使い、社内の質問を集めて、未回答のまま流れた質問を拾います。
最後にサービス資料と統合し、資料に書かれていない質問を、資料に追加・FAQとして独立・相談先を返す、に分けます。

品質チェックは4つで、「答えが正しいか」「答えが最新か」「対外的に言ってよい内容か」（商談で答えたことが公開してよいとは限りません）「根拠が示されているか」です。

更新は四半期に一度で、既にFAQにある質問の件数（減っていれば機能しています）と、答えが変わった質問の2つを見ます。
副産物として、答えのばらつき（最も価値のある発見）、資料の不足、判断が必要な質問が分かります。
ばらつきが見つかったら、FAQを作る前にその領域の責任者が正しい答えを決めます。

直近3か月の商談記録から、聞かれた質問の上位10件を抽出すると、どんな偏りが見えてくるでしょうか。