FAQはFrequently Asked Questions、よくある質問と回答のことです。NN/gのFAQ解説は、実際の顧客の疑問と言葉を使い、情報を見つけて利用できる回答を整えることを重視しています。
本記事では、問い合わせを集める、同じ疑問をまとめる、条件付きの回答を作る、入口を置く、公開後に直すという順序で進める方法を提案します。架空のネット通販（EC）店舗の配送先変更を例に、回答文と空欄ひな型を示します。実在店舗やCX研究所の配送規約ではありません。
FAQにする質問を選ぶ
会社が説明したいことより、顧客が何を知りたくて困ったかを先に整理します。
メール、電話、チャット、店舗で聞かれた質問を、個人情報を除いて集めます。件数だけでなく、「購入前」「手続き中」「利用後」のどの場面で聞かれたかも残してください。同じ配送先変更でも、発送前と発送後では答えが異なります。
「住所を間違えた」「送り先を変えたい」「注文後に届け先を修正できますか」は、同じ目的の候補です。ただし「引っ越したので登録住所を変えたい」は、未発送の注文を変更することとは別かもしれません。顧客が達成したい行動を確かめてからまとめます。
ZendeskのFAQ構造の説明では、入口、内容の整理、顧客の行動に合う分類、データに基づく改善を扱っています。分類名も「受注情報管理」より「注文内容を変更したい」のように、読者が探す言葉で試します。
質問と回答の記入例
結論を先に書き、条件・操作・できない場合の経路を続けます。
説明用の架空例として、次の店舗は、発送準備前の注文に限り、注文画面から住所変更を申請できると仮定します。変更完了は確認通知で知らせ、発送準備開始後は変更可否を担当者が確認します。この機能や運用がない店舗には、そのまま掲載できません。
質問：注文後に配送先を変更できますか？
発送準備前であれば、注文画面から変更を申請できます。「注文履歴」で対象の注文を開き、変更申請の画面から新しい配送先を送信してください。受付表示だけでは変更は完了していません。確認通知と注文画面の新住所が一致していることを確かめてください。
発送準備が始まっている場合、画面から申請できない場合、確認通知が届かない場合は、店舗の問い合わせ窓口へご連絡ください。変更できるかと、必要な対応を確認して案内します。公開コメント欄には、住所や注文番号を記載しないでください。
実際の掲載前には、操作名、対象商品、締切、受付と完了の区別、問い合わせ先を自社の運用に置き換えます。「変更できます」だけで済ませると、発送後にも同じ操作ができると読まれる可能性があります。
コピーして使う回答ひな型
一つの質問で、適用条件と次の行動が分かるようにします。
| 欄 | 記入する内容 | 上の例で対応する内容 |
|---|---|---|
| 質問 | ［顧客の言葉で一つの目的］ | 注文後の配送先変更 |
| 最初の答え | ［可能か・条件は何か］ | 発送準備前なら申請できる |
| 対象と例外 | ［対象商品・時点・除外条件］ | 発送準備後は個別確認 |
| 行動の手順 | ［実在する画面名・操作順］ | 注文履歴から変更申請 |
| 完了の確認 | ［何を見れば終わったと分かるか］ | 確認通知と新住所 |
| 困った場合 | ［実在する連絡先・必要情報］ | 店舗の問い合わせ窓口 |
| 管理情報 | ［責任者・確認日・更新条件］ | 発送運用担当、運用変更時に更新 |
一つの回答に返品、支払い、配送の全条件を詰め込みません。必要な別の回答へリンクし、そのリンク先で何を確認できるかを示します。社内の管理情報は、公開する回答文とは分けて保存してください。
読者が回答へたどり着ける入口を作る
FAQのページだけでなく、疑問が起きる画面にも回答への入口を置きます。
NN/gの顧客サポート情報の研究では、FAQ・問い合わせ・個別の情報ページの役割や相互の経路を扱います。問い合わせたい人が、FAQだけに連れていかれる状態は目的とずれます。
配送先変更のFAQなら、注文完了画面、注文履歴、配送案内からもたどれるかを確認します。FAQ一覧の分類、サイト内検索、スマートフォンでの操作も試します。「住所」「届け先」「配送先」などの言葉で同じ回答へ到達できるかを見てください。
返金判断や本人確認が必要な相談は、担当者への経路を残します。すべてをFAQで解決できると約束せず、「どの条件では連絡が必要か」を明記します。顧客接点の整理は、回答を置く場所を決める補助になります。
公開前に確認する5つのこと
回答の正しさ、発見しやすさ、完了までの行動を一緒に確かめます。
- 実際に質問された内容と、回答が扱う目的は一致しているか。
- 条件・期限・操作名は担当者が確認した最新のものか。
- スマートフォンでも必要な回答と操作の入口が見つかるか。
- 申請した状態と処理完了した状態を区別できるか。
- 例外時に実在する問い合わせ経路へ進めるか。
理解を確かめる試験の例として、担当者が答えを教える前に、利用者に「注文の配送先を変えたい場合、できるか確認してください」と依頼します。回答が見つかったか、条件を理解できたか、次の行動を選べたかを別々に記録します。少数の試験で、すべての顧客が理解できると断定しません。
公開後の更新と効果の見方
閲覧されたかだけでなく、同じ疑問と手続きの失敗が減ったかを見ます。
公開前後で対象の問い合わせ内容を同じ分類で数えます。注文数が増えた月は、問い合わせの件数だけでなく注文当たりの割合も確認します。FAQ閲覧後に問い合わせがなかったことだけでは、解決したのか諦めたのか分かりません。検索語、回答への到達、手続きの結果、再問い合わせも合わせて見ます。
更新の責任者と確認日を決め、画面や規約が変わったときに回答も確認します。質問から商品や手続き自体の問題が見つかったら、FAQを増やすだけでなく、原因の修正を検討します。顧客の声（VoC）の分析は、繰り返す疑問を改善へ渡す方法の一つです。
まとめ
FAQは、読者が回答を見つけ、条件を理解し、次の行動を選べる形で作ります。
- ✓実際の疑問を顧客の言葉で整理します。
- ✓結論・条件・手順・完了確認・例外の経路を用意します。
- ✓疑問が起きる画面から回答へ進めるかを試します。
- ✓問い合わせと行動の記録を見て、回答と手続きの両方を更新します。
繰り返し届く質問を一つ選び、上のひな型を埋めてください。運用担当の確認後に、答えを知らない人がその回答で判断できるかを試すところから始められます。
