要望フォームには何を聞く?顧客が答えやすい項目と記入例
顧客向けの要望フォームに、何を必須で入力してもらうか迷っていませんか。項目は、困った場面と望む結果を確認するために選びます。受付後に使い道が決まっている情報を聞き、社内で判断できる項目は顧客に入力させないことが基本です。
この記事では、顧客自身が記入するフォームの質問文を扱います。メールや商談など複数の受付経路をまとめる方法は、機能要望の収集を一本化する方法で紹介しています。
- 受付後の使い道からフォームの項目を選ぶ
- 困った場面と望む結果を顧客の言葉で聞く
- 送信後の案内まで含めて記入を試す
項目を増やす前に、回答を何に使うか決める
フォームに項目を足すときは、誰が回答を読み、どの判断に使うかを書き出します。社内で必要な情報が、そのまま顧客に質問すべき情報とは限りません。
英国政府のフォーム設計ガイドも、質問ごとに情報が必要な理由、使い道、回答すべき人などを確認する方法を示しています。要望フォームなら「この項目が空だと、受付後の何ができないか」と考えると、必要性を具体的に検討できます。
たとえば開発工数や事業上の優先度は、通常、社内で評価する情報です。顧客に「優先度:高・中・低」を選んでもらっても、それぞれが異なる基準で答える可能性があります。代わりに「いつ、どんな作業で必要になりますか」と聞くと、判断の背景を残せます。
入力済みの顧客情報を使える環境なら、同じ会社名や連絡先を重ねて聞く必要があるかも確認します。ただし、自動で取得される情報と、利用者が想定する情報が違わないよう、送信内容を確かめられる案内を用意します。
困った場面と望む結果を分けて尋ねる
自由記述の欄には、書いてほしい内容が分かる質問を置きます。「詳細」だけでは、機能名を書けばよいのか、操作手順を書けばよいのか判断しにくくなります。
英国政府の利用者ニーズの整理方法では、利用者が何をしたいか、その理由や状況を整理し、解決策だけに寄らないことを重視しています。以下は、その考え方を顧客向けの要望受付に応用した項目案です。必須・任意は一律の正解ではなく、受付後の確認方法に合わせて調整します。
| 項目 | 質問文の案 | 初期案での扱い |
|---|---|---|
| 困った場面 | どんな作業で困りましたか | 必須 |
| 望む結果 | どうなれば、その作業を進めやすくなりますか | 任意 |
| 現在の方法 | いまはどのように対応していますか | 任意 |
| 発生する条件 | いつ、どのようなときに起きますか | 任意 |
| 連絡先 | 内容を確認する場合の連絡先を教えてください | 追加確認が必要な運用なら必須 |

たとえば、架空の申請管理ツールなら、「月末に自分の承認待ちを探すため、申請を一件ずつ開いている」と記入できます。望む結果には「自分が確認する申請だけを把握して承認したい」と書けます。機能名が分からなくても、業務の話として伝えられる形です。
顧客が具体的な機能を提案したい場合も、同じ欄で受け取れます。その案を残したうえで、困った場面が分からなければあとで確認します。フォームの段階で提案を決められた分類へ押し込む必要はありません。
必須入力を増やさず、回答の負担を調整する
必須項目は、送信前にどうしても必要なものに絞ります。顧客が答えを持っていない質問を必須にすると、推測の数字や適当な分類が入力され、受け取る情報の意味が曖昧になります。
たとえば「作業にかかる時間」を聞きたい場合、毎回計測しているとは限りません。「分かる範囲で、かかった時間や手間を教えてください」と任意で尋ねれば、測っていない人も送信できます。分からないという状態を、影響がないという意味に読み替えないことも大切です。
質問の補足は、回答を誘導しない内容にします。「便利な自動化の案を教えてください」と書くと、自動化以外の困りごとを伝えにくくなります。短い記入例を付けるなら、特定の機能を正解として示さず、状況を説明する例にします。
添付は、画像がなければ判断できない場面に備えた補助として考えます。顧客情報などを隠す案内を添え、添付できないときの説明方法も残します。添付したファイルを誰が見られるかも、送信前に確認できると安心して使えます。
また、分類名は社内用語のまま置かないようにします。顧客が「ワークフロー基盤」と「業務ロジック」の違いを判断できなくても、困った画面名なら答えられるかもしれません。入力者にとって分かる言葉を選びます。
送信後に何が起こるかまで案内する
送信完了の画面では、受け付けたことと、その後の扱いを分けて伝えます。受付をもって実装が決まったように読める文言は避け、確認の連絡があるか、状況をどこで見られるかを、実際の運用に合わせて書きます。
たとえば「要望を受け付けました。内容の確認が必要な場合は、ご登録の連絡先へお尋ねします。対応の可否や時期は検討後にお知らせします」という案内なら、何が決まり、何が未定かを分けられます。ただし、検討結果を知らせる運用がないのに、この文面だけを置いてはいけません。
フォームは、送信した要望を次に扱う人まで決めて初めて運用できます。受付担当、追加質問の担当、結果を返す担当が同じ人でもかまいません。誰が未確認のまま残った要望を見直すかを決めておきます。
公開ボードへ投稿する形式なら、送信内容がほかの人にも見えることを入力前に伝えます。社内だけで読むフォームと同じ説明では、顧客が意図せず情報を公開する可能性があります。公開範囲を判断できない場合は、運用と説明を確かめてから案内します。
最後に、作成者以外の人に短い要望を記入してもらい、どの項目で迷ったかを聞きます。空欄が多いことだけで必須項目を増やさず、質問の意味、回答できる情報、送信後の説明が伝わっているかを順に確かめると改善点を見つけやすくなります。
よくある質問
希望する機能名を必須にしてもよいですか?
顧客が具体的な機能を思いついていない場合もあるため、困った作業を伝えられる欄を用意します。機能案を聞く場合も、その背景を補える質問と組み合わせると検討しやすくなります。
匿名の要望も受け付けるべきですか?
受付後に本人への確認が必要か、匿名のままどう扱うかで決めます。連絡できない場合の限界を社内で共有し、匿名であることだけを理由に内容の重要度を決めないようにします。
フォームを短くすると情報が不足しませんか?
初回の入力と追加確認を分けて考えます。まず困った場面を受け取り、判断に必要な点を後から尋ねる運用も選べます。追加確認する担当がいることが前提です。
まとめ
要望フォームの項目は、受付後の使い道から選びます。困った場面と望む結果を顧客の言葉で聞き、送信後の案内まで含めて記入を試すことが大切です。受け取った要望を整理し判断へつなぐ方法は、機能要望管理の基本で確認できます。