「FAQを作ったのに、問い合わせが全然減らない」
社内の問い合わせ対応を効率化するために、ExcelやSharePointなどでFAQを作ったものの、結局は詳しい担当者への問い合わせが続いている。
こうした状態は珍しくありません。
FAQの件数を増やしたり、内容を充実させたりしても、なぜか使われない。
その原因は、FAQそのものではないかもしれません。
FAQがあることと、組織のナレッジが活用されていることは別です。
重要なのはFAQを作ることではなく、日々の問い合わせ対応によって生まれた回答が、自然に蓄積・整理・再利用される仕組みを作ることです。
今回は、FAQを作っても問い合わせが減らない理由と、社内ナレッジを「使われる仕組み」に変えるための考え方をご紹介します。
FAQを作った。でも結局みんな人に聞いている
例えば、社内で問い合わせが多いテーマについてFAQを作ったとします。
担当者が過去の質問を整理し、一つずつ回答を書き、ExcelやSharePointなどへ登録する。
最初は順調に見えます。
しかし、数か月すると次のような状態になりがちです。
- 新しい問い合わせへの回答がFAQへ反映されていない
- FAQに書いてある内容が古くなっている
- 検索しても欲しい回答が見つからない
- どの回答が正しいのか分からない
- 結局、詳しい人へ聞いた方が早い
すると利用者は、FAQを見ることをやめてしまいます。
一度「FAQを見ても分からない」と感じると、次からは最初から人へ聞くようになります。
つまり、FAQを作っただけでは、問い合わせ対応の業務プロセスそのものは変わっていないのです。
FAQが使われなくなる5つの理由
1．FAQへの登録が「別の仕事」になっている
問い合わせへ回答したあとに、担当者が改めてFAQへ転記する。
この運用では、FAQへの登録は本来の問い合わせ対応とは別の追加作業になります。
忙しいときほど後回しになり、徐々に更新されなくなります。
2．メール・電話・口頭の回答が残らない
社内問い合わせは、必ずしも一つのチャネルから来るわけではありません。
メール、電話、Teams、対面など、さまざまな経路で質問が届きます。
その場で回答して解決すると、貴重な知識が担当者のメールボックスや頭の中だけに残ることがあります。
3．検索する言葉とFAQに登録された言葉が違う
FAQを作成する担当者は、正式名称や社内用語を使って登録する傾向があります。
一方、質問する人は別の言葉で検索します。
情報自体は存在していても、検索する言葉と登録された言葉が違えば、利用者から見れば「FAQにない」のと同じです。
4．更新されず、FAQそのものが信用されなくなる
制度、商品、社内ルール、システムなどは変わります。
FAQだけが更新されなければ、古い回答が残ってしまいます。
利用者が一度でも古い情報を見つけると、
「FAQより担当者に聞いた方が確実」
という行動に戻ってしまいます。
5．「FAQを増やすこと」が目的になっている
FAQが使われないと、「情報が足りないのではないか」と考えて件数を増やしたくなります。
しかし、100件のFAQを1,000件に増やしても、必要な情報へたどり着けなければ問題は解決しません。
FAQの問題を「コンテンツ不足」とだけ考えると、使われないFAQをさらに増やしてしまう可能性があります。
問題はFAQではなく「回答後の業務フロー」にある
従来の問い合わせ対応をシンプルにすると、次のようになります。
問い合わせ
↓
担当者が調査
↓
回答
↓
終了
この最後の「終了」が問題です。
担当者が調査して回答を作った時点で、組織にとって価値のある知識が一つ生まれています。
ところが、メールを送って終われば、その回答は個人の仕事として完了しても、組織のナレッジにはなりません。
そこで問い合わせ対応を、
問い合わせ
↓
回答
↓
蓄積
↓
整理
↓
検索
↓
再利用
まで一つの業務として設計します。
問い合わせ対応そのものからナレッジが育つ仕組み
この構造に変えることで、FAQを人が別途作り続けるのではなく、日常の問い合わせ対応そのものをナレッジの原材料にできます。
「FAQを作る」のではなく、「FAQが育つ仕組み」を作る
Microsoft 365を利用している企業であれば、例えば次のような構成が考えられます。
OutlookやFormsなどで問い合わせを受付
↓
SharePoint Listsへ問い合わせを記録
↓
担当者が調査・回答
↓
回答内容もデータとして蓄積
↓
整理・レビュー
↓
次回の問い合わせで検索・再利用
必要に応じてPower Automateを使い、受付時の登録、担当者への通知、ステータス更新などを自動化することもできます。
ここで重要なのは、
「回答する仕事」と「ナレッジを作る仕事」を、できるだけ別々の仕事にしないこと。
です。
担当者が普段の業務を行うことで、その結果が次の問い合わせ対応に使える形で残る。
この状態を作ることが、継続できるナレッジ運用につながります。
実際にSharePoint ListsとPower Automateを使い、メールで終わっていた問い合わせ回答をナレッジとして蓄積する考え方については、「メールで終わる問い合わせを組織のナレッジへ。SharePoint Listsで照会回答業務を再設計した事例」でも紹介しています。
問い合わせ管理とFAQを別々に考えない
問い合わせ管理とFAQを、それぞれ別のシステムとして考えてしまうケースがあります。
しかし、実際には日々の問い合わせデータこそFAQの原材料です。
例えばSharePoint Listsなどで問い合わせを管理する場合、次のような情報を持たせることが考えられます。
| 項目 | 内容 |
|---|---|
| 質問 | 問い合わせの内容 |
| 回答 | 実際に回答した内容 |
| カテゴリ | 問い合わせの分類 |
| ステータス | 未回答・対応中・回答済みなど |
| 回答者 | 回答を担当した人 |
| 回答日 | 回答した日付 |
| 公開可否 | ナレッジとして再利用できるか |
| キーワード | 検索・再利用のための言葉 |
こうした設計によって、「業務を処理するための記録」と「次回利用するナレッジ」をつなげることができます。
SharePoint Listsで業務システムを作る際のデータ設計については、「SharePoint Listsで業務システムを作るなら、最初に『列』を作ってはいけない」でも詳しく解説しています。
すべての問い合わせをFAQにする必要はない
ここでもう一つ重要なのが、何でもFAQとして残せばいいわけではないという点です。
例えば、
- 一度しか発生しない特殊な個別案件
- 個人情報や機密情報を含む問い合わせ
- すでに廃止された制度についての回答
- 極めて特殊な例外処理
などまで大量にナレッジ化すると、今度は不要な情報が増え、検索しにくくなります。
そのため、例えば、
回答済み
↓
ナレッジ候補
↓
内容をレビュー
↓
公開・再利用
という工程を設けます。
蓄積は自動化しても、「組織として再利用すべき知識か」という判断には人を残す。
このような役割分担が重要です。
Power Automateを使った自動化でも、最初からすべてを自動化するのではなく、人とシステムの役割を整理する必要があります。詳しくは、「Power Automateを作る前に業務フローを描くべき理由」も参考にしてください。
「検索できる」と「見つかる」は違う
ナレッジをSharePointなどへ蓄積すると、「検索機能があるから大丈夫」と考えたくなります。
しかし、検索できる仕組みがあることと、利用者が必要な情報を見つけられることは別です。
例えば、次のような情報を意識して設計します。
- カテゴリ
- 検索キーワード
- 質問文
- よく使われる言い換え
- 回答の更新日
- 対象となる業務や制度
特に重要なのは、利用者が実際にどのような言葉で質問するのかです。
社内の正式名称だけで情報を整理すると、その名称を知らない利用者は検索できません。
ナレッジ管理は、情報を「登録する側」ではなく、探す側の言葉から設計する必要があります。
「回答して終わる組織」と「回答するたびに賢くなる組織」
問い合わせ対応の仕組みを変えると、同じ質問を受けても組織に残るものが変わります。
Beforeでは、問い合わせが来るたびに詳しい人を探し、担当者が調査して回答します。
メールを送ったら、その業務は終了です。
そのため、次に同じ質問が来ても、また同じ調査が発生します。
Afterでは、まず過去のナレッジを検索します。
回答が見つからなければ担当者が調査し、その新しい回答を次回利用できる状態で蓄積します。
回答するたびに、組織のナレッジが増えていく。
これが目指す状態です。
FAQのKPIは「登録件数」ではない
FAQやナレッジ管理の取り組みでは、「FAQを何件作ったか」を成果として見たくなります。
しかし、本来見るべきなのは件数ではありません。
- 同じ質問が繰り返される回数が減ったか
- 利用者が自分で解決できるようになったか
- 過去回答を使って回答時間を短縮できたか
- 特定の担当者への問い合わせ集中が減ったか
- 新任担当者でも一定品質で回答できるようになったか
つまり、FAQの目的は「情報をたくさん持つこと」ではありません。
必要なときに必要な知識が使われ、問い合わせ業務そのものが改善されることです。
問い合わせデータが蓄積すると、問い合わせそのものを減らせる
問い合わせと回答をデータとして蓄積するメリットは、過去回答を再利用できることだけではありません。
問い合わせが蓄積すると、
- どのテーマの質問が多いのか
- どんな質問が繰り返されているのか
- どの部署で困っている人が多いのか
- どの業務や制度が分かりにくいのか
といった傾向も見えてきます。
すると、次の改善策が考えられます。
- FAQの見せ方を改善する
- マニュアルを書き直す
- 社内ポータルへ情報を掲載する
- 問い合わせが多いテーマを研修にする
- 業務ルールそのものを見直す
つまり、問い合わせ管理の次の段階は、「回答を早くする」から「問い合わせそのものを減らす」ことです。
AIを活用するなら、先に「使えるナレッジ」を作る
最近では、生成AIやCopilotを使って社内問い合わせへの回答を支援したい、という企業も増えています。
しかし、AIを導入すれば自動的にナレッジ管理が完成するわけではありません。
AIが参照する情報自体が古かったり、重複していたり、整理されていなかったりすれば、十分な回答支援にはつながりません。
先に、
- 質問
- 回答
- カテゴリ
- キーワード
- 更新日
- 根拠となる資料
などを整理し、組織として信頼できるナレッジ基盤を作ることが重要です。
そのうえで将来的には、
自然な言葉で質問
↓
関連する社内ナレッジを検索
↓
回答候補を提示
↓
担当者が確認して回答
といった活用にも発展させられる可能性があります。
AIから始めるのではなく、AIが使えるナレッジを先に作る。
こんな状態なら、FAQの「中身」より「仕組み」を見直す
現在、社内で次のような状態になっていないでしょうか。
- FAQはあるが、結局詳しい人へ質問が集中している
- 同じ問い合わせに何度も回答している
- 過去の回答メールを毎回検索している
- FAQへの登録が担当者の善意に依存している
- FAQが古く、どれが正しい回答か分からない
- 担当者が異動するとナレッジも失われる
- FAQの件数は多いが、利用されているか分からない
一つでも当てはまるなら、FAQをさらに増やす前に、問い合わせ対応からナレッジが生まれる業務プロセスを見直す価値があります。
FAQを作ることが、ナレッジ管理ではない
FAQを整備すること自体は重要です。
しかし、本当に目指したいのはFAQファイルを増やすことではありません。
問い合わせが発生し、担当者が回答する。
その回答が組織に残り、整理され、次の人が検索して使える。
「回答するほど、組織のナレッジが増える仕組み」を作る。
これが、FAQを「作る」から、社内ナレッジを「使われる仕組み」に変えるための重要な考え方です。
株式会社uniteでは、SharePoint ListsやPower Automateなどのツールを作るところからではなく、現在の問い合わせ業務を整理し、受付・回答・蓄積・整理・再利用までを一つの業務プロセスとして設計しています。
「FAQはあるのに問い合わせが減らない」
「詳しい人への問い合わせが集中している」
「将来的にAIで社内問い合わせを効率化したい」
といった段階からでも構いません。
まずは、現在の問い合わせ対応がどのように行われているのかを整理するところから始めましょう。
