事前準備
URLを発行する前に、HTMLに含まれるFAQの質問文リストを抽出してCSチームのリーダーに確認します。「よくある質問」として掲載されているにもかかわらず実際には問い合わせがほとんど来ないトピックが含まれていたり、逆に件数が多い問い合わせが抜けていたりするケースが頻繁にあります。
フォームのinputラベルとplaceholderテキストが正確な日本語になっているか事前に確認します。英語のplaceholderが残っていたり、入力形式の説明がないフィールドがあると、CSへの「入力方法がわからない」という問い合わせが増えます。特に電話番号フィールドの「ハイフンあり/なし」の明示はCSが把握しておく必要があるため、URLとともに伝えます。
- 相手がログインなしで開ける状態か確認する
- PCとスマホで最低1回ずつ表示を確認する
- 内部情報・個人情報・不要な外部送信が残っていないか見る
- レビュー期限と修正時の差し替え方を決めておく
確認観点
CSレビューでは「このページを見てもわからなかった人が何を問い合わせてくるか」という視点で確認します。具体的には、手順説明の中で「〜してください」の主語や目的語が省略されている箇所、画像がないと手順を追えない箇所、専門用語の説明がない箇所を洗い出します。
HTMLに含まれるリンク先が正しく機能するか（404になっていないか）を全件チェックします。CSがユーザーに「こちらのページをご確認ください」と案内したリンクが404だった場合、二次問い合わせが発生してCS工数が2倍になります。`wget --spider` コマンドやリンクチェッカーツールでHTMLの全リンクを事前に確認します。
- HTML内の外部script・form action・iframeを確認する
- APIキーやトークンらしき文字列がないか検索する
- 画像・CSS・JSのパスが公開後も解決できるか見る
- noindexと認証を混同せず、必要なら両方設定する
NG例
CSレビューで最も困るのは「表示確認だけしてください」という依頼です。CSは表示の正確性より文言の適切さを判断する立場にあるため、「この文言が問い合わせ対応の現場で通じるか確認してください」と目的を明示した依頼にします。目的が明示されていないと「見た目は問題ありません」という返答で終わり、本来欲しい文言レビューが得られません。
もうひとつのNGは、エラーメッセージをHTMLの確認なしに「開発者が自由に書いた文言」のまま共有することです。「システムエラーが発生しました」「リクエストが失敗しました」のような技術的な文言は、CSがユーザーに説明するときに言葉を変換する手間が生じます。CSが案内しやすい「通信環境をお確かめのうえ、もう一度お試しください」のような具体的な文言に変更してから共有します。
修正後の再共有
CS指摘を受けた修正は「問い合わせ削減効果」という観点でビフォーアフターを説明すると、CSチームに修正の意義が伝わりやすくなります。「FAQ3の回答を書き直しました」だけでなく「問い合わせ上位10件の第2位に対応するFAQを追加しました」のように、日常業務との接続点を明示します。
再共有の際にCSチームが最も必要としているのは「このページを案内する際の標準スクリプト」です。URLと一緒に「このページはXXXのお問い合わせをいただいたお客様にご案内いただけます」という1〜2文の案内テンプレートを添えると、CS担当者が即座に活用できる状態になります。
よくある質問
リンクチェッカーツールを使わずに404リンクを確認する方法はありますか？
ブラウザでHTMLを開きDevToolsの「Network」タブを起動した状態でページを読み込み、ステータスコード404をフィルタリングします。全リンクをクリックするのは手間ですが、ページ内の主要リンクは表示直後のNetworkログで確認できます。
CSチームが「見た目は問題ない」とだけ返答してくる場合の対策は？
依頼メールに「確認項目チェックシート」を添付し、「FAQの質問文○件について実際の問い合わせ言葉と一致するか」「エラーメッセージ○か所について案内しやすい表現か」を具体的に回答してもらう設問形式にします。
エラーメッセージの文言変更はフロントエンドとバックエンドどちらを修正すればよいですか？
フロントエンドで制御できるバリデーションメッセージはHTMLまたはJSを修正します。サーバーが返すエラーコードのメッセージはバックエンド側の対応が必要なため、エラーの発生源をNetworkタブのレスポンスで確認してから担当者に依頼します。