%20(%E8%83%8C%E6%99%AF%E3%81%82%E3%82%8A).png?width=130&height=39&name=%E6%9C%80%E7%B5%82Start%20Link%20(500%20x%20150%20px)%20(%E8%83%8C%E6%99%AF%E3%81%82%E3%82%8A).png "StartLink"){kind=logo}
この記事の結論
社内FAQは、繰り返される問い合わせを、誰もが探して使える回答に変える仕組みです。質問の収集、記事の設計、導線づくり、更新運用を一続きで考えます。
社内FAQは、繰り返される問い合わせを、誰もが探して使える回答に変える仕組みです。質問の収集、記事の設計、導線づくり、更新運用を一続きで考えます。
「同じ質問に何度も答えている」「FAQを作ったのに、結局チャットで人に聞かれる」「担当者が変わると、回答の仕方も変わる」。こうした状態を改善するには、回答を集めるだけでなく、質問者が必要な記事を見つけ、手順を実行できる形に整える必要があります。
社内FAQとは、社内で繰り返される質問と回答を、検索・参照できる形で整理したナレッジです。問い合わせ記録から対象を選び、回答の根拠と確認担当を明らかにして公開します。公開後は、見つからなかった質問と、閲覧後も解決しなかった質問を分けて改善します。
この記事でわかること
社内問い合わせへの対応を、担当者個人の経験から引き継げる運用に変えたい方に向けて、FAQ化する質問の選定から公開後の見直しまでを順に説明します。
- FAQ化する質問の選び方 — 問い合わせ記録を使い、共通の回答を用意できる質問と個別判断が必要な質問を分けます。
- 見つけて使える記事の作り方 — 質問者の言葉を使ったタイトル、結論から始める回答、例外時の案内を整理します。
- FAQへの導線と更新方法 — 社内ポータルやSlackでの案内場所を決め、検索結果や追加質問を修正につなげます。
- 効果の確かめ方とAIの役割 — 問い合わせ記録で変化を確認し、AIに案内させる範囲と人へ引き継ぐ条件を考えます。
まず問い合わせの受付から解決までをたどり、共通手順にできる部分を見つけます。そのうえで記事を公開し、質問者が実際に使えるかを確かめてください。
社内FAQで共通回答と個別対応の境界を決める
FAQの目的は、記事数を増やすことではありません。質問者が自分で答えにたどり着き、手順を進められる状態を作ることです。そのために、共通の回答で案内できる範囲と、担当者の判断が必要な範囲を先に分けます。
質問と回答を蓄積して再利用する
総務、人事、情シス、経理などには、手続きや社内ルールに関する質問が寄せられます。個別のメールやチャットだけで回答すると、後から同じ説明を探し直すことになります。
- 記録 ── 問い合わせを受けた場所、質問者の表現、案内した回答を記録します。
- FAQへの記載 ── 同じ手順で答えられる質問をまとめ、FAQには手順の前提、行う操作、例外時の連絡先を記載します。
回答が担当者の判断によって変わる場合は、共通部分だけを記事にし、判断が必要な部分の相談先を示します。
部門ごとに、次のような問い合わせをFAQに記録します。
- 総務 ── 備品購入や会議室予約の手順を尋ねる例もFAQに蓄積し、共通回答を再利用できるか確認します。
- 人事 ── 休暇申請の手順、証明書の発行依頼、福利厚生に関する問い合わせ先を整理します。
- 情シス ── パスワードリセットやVPN接続、ツールの利用方法など、繰り返し寄せられる問い合わせをFAQに記録し、共通の回答を再利用できる形にします。
- 経理 ── 請求書の処理方法や支払い予定を確認する例を記録し、共通して案内できる内容をまとめます。
Excelやスプレッドシート管理の限界を見極める
問い合わせ一覧を表計算ソフトで管理する方法は、質問や担当者が少ない段階では始めやすい選択肢です。記録を集めて分類する用途には使えても、質問者が最新版の回答を探す場所として適しているかは別に確認します。
| 管理方法 | 活用しやすい状態 | 見直しを考える状態 |
|---|---|---|
| 表計算ソフト | 問い合わせ記録を集め、テーマを整理する | 更新担当や最新版が分かりにくい |
| メールやチャット | 個別の事情を確認しながら回答する | 過去の回答を探すために人へ聞き直す |
| FAQページ | 共通の手順やルールを検索して参照する | 導線や記事の更新責任が不明確 |
まず既存の記録で繰り返されるテーマを把握し、回答の確認担当を決めます。
表計算ソフト上で整理した内容をFAQページに載せた後、質問者が迷わず最新版を見つけられるかを確かめます。見つからない場合は、管理方法だけでなく、タイトルや案内場所も見直します。
自己解決だけでなく引き継ぎも設計する
FAQを読んでも、個別の承認や例外判断が必要な質問は残ります。そのとき「FAQを読んでください」だけで終わらせず、どの条件まで自分で進められるか、誰に何を伝えればよいかを記事に書きます。
受付時には、まず共通手順に当てはまるかを確認します。
- 当てはまる場合 ── FAQへ案内します。
- 当てはまらない場合 ── 必要な情報を添えて担当者に引き継ぎます。
引き継いだ質問に共通する部分が見つかったら、その部分をFAQに追加できるか検討します。
問い合わせの回答経路を先に描く
FAQにするテーマを選ぶ前に、実際の問い合わせがどこから入り、誰の確認を経て解決したかを一件ずつたどります。
同じ質問に見えても、手順の案内だけで終わる場合と、個別の判断が必要な場合があります。
この違いを見落とすと、記事を読んだ人が判断を要する作業まで進めてしまいます。
たとえば経費精算に関する質問なら、次のように用件を分けます。
- 「申請画面の場所が分からない」 ── 参照先と操作手順を確認できればFAQにできます。
- 「この支出が申請対象になるか判断してほしい」 ── 共通の確認事項を記事に示し、対象かどうかの判断は担当部署へつなぎます。
回答経路を分けたうえで、記事のタイトルと相談先を決めてください。
FAQの対象を問い合わせ記録から決める
最初からすべての質問を記事にする必要はありません。
問い合わせ記録を見て、同じ説明を繰り返しており、回答の根拠を確認できるテーマから選びます。記録が散らばっている場合は、集める場所と記載項目をそろえるところから始めます。
問い合わせを集めて分類する
質問文だけでなく、案内した回答、回答した部門、解決したかどうかも記録します。質問者が使った言葉は、記事タイトルや検索語に生かせるよう残してください。
分類では、たとえば「経費精算」の下に、次のようなトピックを設けます。
- 申請方法
- 提出期限
- 差し戻し
- 対象経費
用件が似ていても、必要な手続きや判断条件が違うなら分けます。分類に迷ったら、同じ回答を案内して質問者が手順を完了できるかを確認します。
優先順位は頻度と対応負荷で決める
まず問い合わせが繰り返されているテーマを探します。
次に、毎回同じ説明で回答できるか、回答前に個別事情の確認が必要かを見ます。繰り返しが多くても、承認や例外判断が中心なら、FAQには共通手順と相談先を載せる形が適しています。
| 優先度の目安 | 問い合わせ頻度 | 判断のポイント |
|---|---|---|
| 高 | 月10回以上 | 共通手順で回答でき、対応を繰り返している |
| 中 | 月5〜9回 | 回答の一部が共通で、条件の補足が必要 |
この表の頻度は、テーマを仮に並べるための区分であり、効果や優先度を保証する基準ではありません。自社の記録で繰り返し方、回答に要する確認、誤解した場合の影響を見比べて選びます。
頻度が低くても、期限や例外条件の誤解が業務に影響する質問は優先を上げます。個別事情の確認が中心の質問には、回答を一般化するより、窓口と事前に伝える情報を示します。
小さく公開して対象を広げる
最初に選ぶのは、共通手順が明確で、担当部署が回答の根拠を確認できるテーマです。公開前に、その手順を初めて使う人が記事を読んで次の行動を判断できるか確かめます。
| 段階 | 行うこと | 次へ進む目安 |
|---|---|---|
| 準備 | 質問と回答を記録し、分類する | 頻出テーマと確認担当が見えている |
| 初回公開 | 優先テーマの記事を作り、導線を案内する | 利用者が記事を見つけて手順を理解できる |
| 拡張 | 検索ログや追加質問から記事を増やす | 更新担当と見直し方法が決まっている |
公開後に記事が見つからないなら、追加執筆より先にタイトルや導線を直します。
記事は見つかるのに問い合わせが続くなら、回答の前提や例外の書き方を調べます。その確認で不足するテーマが分かった段階で、対象を広げます。
質問者が見つけて実行できるFAQ記事を作る
記事では、質問者が「自分の用件に合う」と判断できるタイトルを付け、答え、手順、例外時の行動を順に示します。執筆後は、回答の根拠を知る担当部署に内容を確認してもらいます。
タイトルには実際の質問を使う
「経費精算について」のような広いタイトルでは、知りたい答えが含まれるか判断しづらくなります。「経費精算の申請方法と提出期限を教えてください」のように、問い合わせで使われた言葉と具体的な用件を含めます。
- 社内用語と質問者の言葉が違う場合 ── どちらでもたどり着けるよう、本文や検索に使う語を見直します。
- 一つのタイトルに異なる手続きが混在する場合 ── 必要な行動ごとに記事を分けるか、冒頭で行き先を選べるようにします。
回答は結論、手順、補足の順に書く
冒頭で質問への直接の答えを示し、その後に操作する場所、必要な情報、進める順番を書きます。最後に、通常の手順に当てはまらない場合の確認方法を示します。
| 構成 | 記載する内容 | 確認すること |
|---|---|---|
| 結論 | 何をすればよいか | 質問への答えが冒頭で分かる |
| 手順 | 操作や提出の順番 | 次に行うことが一つずつ分かる |
| 補足 | 条件、例外、関連リンク | 該当しない場合の行動も分かる |
| 更新情報 | 確認担当や更新日 | 内容を誰が見直すか分かる |
規程、申請ページ、関連フォームなど、回答の根拠となる参照先があれば記事からたどれるようにします。根拠を確認できない内容は断定せず、主管部署への確認が必要な点と、質問時に伝える情報を記載します。
承認や個別判断が要る境界を明示する
通常の申請方法はFAQで案内できます。
例外を認めるか、誰が承認するかが個別事情で変わる場合は、記事だけで結論を出させない設計が必要です。
記事には通常の条件を示し、条件から外れる場合は相談先、伝える事情、必要な資料を案内します。
質問者が自分の状況を判断できない場合も、同じ連絡先へ進めるようにします。公開前には、共通手順と個別判断の境界が読んで分かるかを担当部署と確認します。
公開前に質問者の行動を通して確かめる
記事を読んだだけで内容が正しそうに見えても、質問者が使えるとは限りません。
実際の問い合わせで使われた言葉を入口にして記事を探し、次の点を順に確認します。
- タイトルを見た時点で用件に合うと分かるか
- 冒頭の回答から次の操作へ進めるか
途中で規程や申請画面を参照するなら、リンク先で該当箇所を見つけられるかも確かめます。条件に当てはまらない場合は、記事に書かれた情報だけで相談先と伝える内容が分かるかを確認します。
探せないならタイトルや導線を、読めても進めないなら手順を、判断に迷うなら条件と引き継ぎを直してから公開します。
FAQへの導線を問い合わせの入口に置く
記事を公開したら、質問が生じた場所から見つけられるようにします。
社内ポータル、Slackの固定メッセージ、新人研修、問い合わせメールの自動返信などから、対象者が普段使う入口を選びます。リンクを置いた後は、実際に記事へたどり着けるか確認します。
問い合わせの入口にリンクを置く
- 社内ポータル ── カテゴリとよく使う手続きへのリンクを置きます。
- チャット ── 問い合わせが寄せられる場所から関連するFAQへ進めるようにします。
- 新人研修 ── FAQの場所に加え、検索方法と回答が見つからない場合の連絡方法を案内します。
自動返信にリンクを含めるなら、質問内容に合うカテゴリや記事を案内できるか確認します。リンク先で再び探し直す必要がある場合は、案内先を絞るか、記事タイトルを見直します。
検索結果と閲覧後の問い合わせを調べる
検索結果がない場合と、記事を読んでも解決しない場合では、直す場所が違います。検索語、閲覧した記事、追加で届いた質問を突き合わせて原因を選びます。
| 観察した状態 | 考えられる課題 | 次の対応 |
|---|---|---|
| 検索結果がない | 記事がない、利用者の語句と記事の表現が違う | 記事追加か、タイトル・検索語の修正を選ぶ |
| 閲覧後も問い合わせる | 回答の不足、手順や条件が曖昧 | 問い合わせ内容を確認し、該当箇所を補う |
| 閲覧されない | 導線が見えない、テーマの需要が低い | ポータルやチャットの案内位置を見直す |
| 記事ごとに回答が異なる | 重複記事や更新漏れがある | 正式な回答を決め、関連記事を統合または修正する |
「役に立ったか」の評価を集める場合は、分かりにくかった箇所も伝えられるようにします。担当者は評価だけで修正を決めず、実際の質問と記事の記述を照らして、追加、修正、導線の変更を選びます。
更新担当と見直し条件を決める
記事ごとに、内容を確認する担当部署と、変更時に修正する担当を決めます。制度やシステムの変更を知る人と記事を直す人が異なる場合は、変更をどう伝えるかも決めておきます。
変更が起きたら関連する記事を確認する
制度変更、申請手順の変更、画面の変更があったら、該当記事だけでなく、そこへリンクする案内も確認します。
定期的なレビューでは、次の点を点検します。
- リンク切れ
- 期限
- 担当部署
- 記載した手順
内容を確認できない記事は、そのまま正しいものとして案内せず、主管部署に確認します。
確認中に質問が来たときの連絡先も示し、確認が終わってから記事の案内を再開します。
利用者の質問を更新判断に使う
同じ記事を読んだ人から似た追加質問が届くなら、記事の前提、手順、例外のどこで迷ったかを調べます。質問者ごとに事情が異なる場合は、記事の説明を増やす前に、共通回答にできる部分があるか確認します。
修正後は、質問者が使った言葉で記事を探し、変更した箇所から次の行動が分かるか確かめます。別の記事と回答が食い違う場合は、担当部署が正式な回答を決めてから関連する記述をそろえます。
問い合わせ記録でFAQの効果を確かめる
FAQの成果は、記事数だけでは判断できません。公開したテーマについて、次を一緒に確認します。
- 問い合わせの内容
- 記事への到達
- 閲覧後の追加質問
公開前後を比べるときは、質問の分類方法と集計する範囲をそろえます。
たとえば「経費精算の申請方法」の記事を公開したら、その用件の問い合わせを追います。
- 記事にたどり着けない ── 導線やタイトルを直します。
- 読んでも同じ質問が届く ── 回答の前提や手順を確認します。
問い合わせが別の窓口に移っている可能性もあるため、受付場所をまたいで記録を見ます。
必要な記録が取れていない場合は、効果を推測せず、受付時にテーマと案内した記事を残す方法から整えます。改善箇所を判断できる状態になってから、次のテーマを追加します。
AIチャットボットに渡すFAQと引き継ぎを設計する
AIチャットボットを回答窓口として使う場合も、先にFAQの根拠、公開範囲、例外時の対応を整えます。記事を探す方法が変わっても、古い手順や曖昧な条件を含む回答では、質問者は正しく進められません。
HubSpot Breezeの顧客対応Agentとナレッジ
HubSpotの顧客対応Agentを検討する際は、次の点を確認します。
- 利用するコンテンツソース
- 回答対象
HubSpotナレッジベースのコンテンツと顧客対応Agentの関係は、HubSpotナレッジベースの活用方法で紹介しています。
社内FAQには、社内だけで扱う情報が含まれる場合があります。次の範囲を先に整理してください。
- 利用者に見せてよい情報
- 回答に使う情報の範囲
使える機能や公開範囲は契約と設定で確認し、想定した利用者からだけ参照できるか、実際の質問で確かめます。
回答の根拠と人への引き継ぎを設計する
最初に試すのは、根拠が明確な共通手順や案内です。質問への回答で、次の点を調べます。
- 参照先を確認できるか
- 条件が足りないときに確認を促せるか
- 答えられないときに担当者へつながるか
個別の承認、例外の可否、機密情報を含む判断は担当者に引き継ぎます。
引き継ぐ際には、質問者が何を確認したいか、どの案内を見たか、判断に必要な情報は何かが分かる形にします。共通手順で解決できることを確認できた範囲から、対象を広げます。
できることと向かないことを分ける
AIが参照する記事に矛盾した手順や曖昧な条件があれば、まずナレッジを見直します。回答できなかった質問は、記事の不足、質問者の言葉と記事の表現のずれ、有人対応が必要な判断のどれに当たるか分類します。
| 向いている問い合わせ | 人の判断が必要な問い合わせ |
|---|---|
| 明文化された共通手順 | 個別事情に応じた例外承認 |
| 社内制度や申請先の案内 | 情報が不足していて条件を特定できない質問 |
| FAQに記載された一般的な説明 | 機密情報や個人情報を含む判断 |
| 参照先が明確な手続き | 規程の解釈や複数部門の調整 |
| キーワード検索では登録語や表現の一致を手がかりに回答を探す | 自然言語の質問では質問の意図を読み取り、関連するFAQをもとに回答する |
記事が足りなければ根拠を確認して追加し、表現がずれていればタイトルや検索語を直します。有人対応が必要なら、回答を増やす代わりに連絡先と引き継ぎ方法を明確にします。
よくある質問
社内FAQの初期構築にはどのくらいかかりますか？
必要な期間は、問い合わせ記録の整理状況、対象テーマ、記事を確認する部門によって変わります。まず記録の収集、優先テーマの決定、記事作成、確認、公開を一つのテーマで試してください。確認が止まる工程があれば、その工程の担当と必要な根拠を明らかにしてから対象を広げます。
FAQの記事数はいくつから始めるとよいですか？
記事数を先に決めるより、繰り返し質問され、回答が共通化できるテーマを選びます。公開後に記事が見つかるか、読んだ人が手順を進められるかを確かめます。見つからない質問があれば、表現や導線を見直したうえで、必要な記事を追加してください。
社内FAQと顧客向けFAQを同じツールで管理できますか？
利用するツールの権限や公開範囲によります。まず社内だけで扱う情報と顧客にも案内できる情報を分けます。HubSpotナレッジベースや顧客対応Agentを検討する場合は、社内情報が意図しない相手に表示されない構成か、利用可能な契約条件とあわせて公式情報やアカウント設定で確認します。
FAQを更新するタイミングはいつですか？
制度、システム、申請手順が変わったときに、関連する記事とリンクを確認します。定期レビューでは、内容の根拠、担当部署、利用者からの追加質問を見ます。変更内容を確認できない場合は主管部署に確認し、正しい案内が決まってから記事を更新します。
以下の画面は、Notionページを閲覧するデモ画面です。案件情報を含むページの表示例であり、実顧客の事実を示すものではありません。FAQの掲載場所を検討する際は、このようなページを質問者が見つけられるかに加え、閲覧範囲と更新担当を確認してください。
まとめ
社内FAQは、問い合わせの記録から共通化できる質問を選び、質問者が見つけて実行できる記事にするところから始まります。公開後は、追加質問を手がかりに導線と回答を直し、更新担当と人への引き継ぎを維持します。
まずは問い合わせ記録から繰り返し発生するテーマを選び、次の順に進めてください。
- 質問と回答を集め、共通手順で案内できる範囲を決める
- 担当部署に根拠を確認し、結論、手順、例外時の連絡先を記事にする
- 問い合わせの入口から記事へ案内し、検索結果と追加質問を見て修正する
記事が見つからないなら導線を、読んでも解決しないなら回答を、個別判断が必要なら引き継ぎ方法を見直します。企業様によって最適な形は異なります。自社の質問と運用体制に合わせて、次に整える箇所を選んでください。
CRMを活用した業務効率化やAIとの連携に関するご相談は、StartLinkまでお気軽にお問い合わせください。
あわせて読みたい
記事の内容を、そのまま実務に落とし込みたい方向け
HubSpotゴールドパートナーのStartLinkが、HubSpot導入・AI活用・CRM整備・業務効率化までをまとめて支援しています。記事で気になったテーマを、そのまま相談ベースで整理できます。
次に読む
株式会社StartLinkは、事業推進に関わる「販売促進」「DXによる業務効率化（ERP/CRM/SFA/MAの導入）」などのご相談を受け付けております。 サービスのプランについてのご相談/お見積もり依頼や、ノウハウのお問い合わせについては、無料のお問い合わせページより、お気軽にご連絡くださいませ。
著者情報
