2019年05月30日カテゴリ:Webサイト運用

フォーマルなフォーム〜問い合わせフォームの改善7つのポイント〜

コーポレートサイトには、何らかのかたちで訪問者からの質問や問い合わせを受け付ける仕組みがあると思います。一昔前は質問を受け付けないために、わざと連絡先を書かないといったサイトも散見されました。しかし企業のサイトの場合、デジタルプレゼンス(インターネット上の存在感)が無いと企業そのものの実在性すら危ぶまれる現代において、そんな状態を放置することは通用しません。

連絡先として一般的にはメールアドレス、電話番号、問い合わせフォームなどを用意するかと思います。せっかくのWebサイトなのですから、24時間365日受付可能、Webで完結できるフォームが最適でしょう。しかしながら、最適なフォームを用意しようとすると、思いの外、色々と整備する必要があるものです。

ここでは何をどう整備するとフォームを使ったコミュニケーションのデザインができるのかをまとめてみました。サイトを改善する際の参考にして頂ければ幸いです。

ポイント1:ユーザーの手間は最小限に

サイト全体でフォームが一つ、すべてのページから同じフォームへリンクだけ貼られてる…そんな状態になってませんか?確かにフォームを作るのは面倒ですから、作り分けたくないと思う気持ちは理解できなくもありません。ただし、作る側の手間を惜しむことで、逆にユーザーの手間を増やすのはあまり良いことではありません。

訪問したユーザーが何か疑問をもち、問い合わせしたいと思った時に、ワンクリックでフォームへ遷移できることは大変重要です。これが「お問い合わせ先一覧」などに誘導されて、文章を読まないとフォームにたどり着けないとすると、案内の文章(訪問者にとってはどうでもいい、サイトの都合で手間を惜しむために設けられた)を読んでるうちに、何を問い合わせしたかったのか?忘れてしまいます。その案内文に杜撰な誤字脱字でもあろうものなら、離脱確定でしょう。

一方、ワンクリックでフォームへ飛べたとしても、お問い合わせの対象、例えば商品名などを選択させるのはあまりよろしくありません。仮に選択できるのだとしても、初期値として遷移元のページに関連する商品などが選択済みになっているべきです。訪問者が問い合わせをするということは商品のことを詳しく、正しく知っているとは考えにくいですし、そもそも遷移元のページも遷移先のフォームも同じサイト内なのであるなら、遷移元の情報をフォームの選択項目やチェック項目に引き渡すことができます。そのほうが訪問者にとっては便利でしょう。フォームの作成時にはひと手間かかりますが、ここは歯を食いしばって連携できるように仕込んでおくべきです。

ポイント2:取得情報を欲張らない

例えば、問い合わせフォームに住所は本当に必要でしょうか?確かに「郵送申し込み」フォームであるならば、郵送先の情報を入力する必要はありますが、単なる問い合わせに住所まで教えなければいけない理由があるでしょうか?
穿った見方をすれば、「訴訟を起こす際に必要になるから」ぐらいじゃないでしょうか。ユーザーにしてみれば「えっ、そんな喧嘩腰なの!?」と思ってしまうわけです。そりゃ嘘の住所入れますよね。

あるいは「サイトに関するご意見」フォームで、メールアドレスは本当に必要でしょうか?ユーザーが返信を欲しい場合、連絡先としてメールアドレスが必要かもしれません。しかしながら「ご意見」なので、返信が必要とは限りません。近所のスーパー同様「こういう意見いただきました。こう考えます。こうします!」というコンテンツを展開することも不可能ではないでしょう。であるなら、メールアドレスは必須ではなく、オプショナル(任意)であるべきです。性別や年齢も同様に本当に必要なのかどうか、熟考が必要でしょう。すくなくとも、連絡先のメールアドレスにきちんとメールが届くことを確認して、必要であれば改めてご本人に問い合わせるというワークフローで十分じゃないでしょうか?

一般的に企業のマーケティングやCRMの担当者の視点では、ついつい欲が出て、必要でもない情報を根こそぎ入力させたくなるものです。しかし、使いもしない&”使え”もしない個人情報を死蔵することは、漏洩リスクを増やす一方であり、何のメリットもありません。
さらに問題なのは、入力されたデータが本当であるかどうかわからないという点です。個人情報を積み上げてホクホクしてるつもりが、ごみの山を増やして、データベースやCRMシステムの費用負担を増やしているだけかもしれません。集めるのなら正しいことが確認できた情報に絞るべきでしょう。ゴミを取り込んでも百害あって一利なしです。

欲張らずに取得する情報を最小限とし、さらに必須入力を制限することで、フォームを入力する手間は激減し、フォーム入力に躊躇するユーザーを減らす効果があります。

ポイント3:再入力はさせない

ページごとに微妙に違う項目があるフォームを用意した場合、どのフォームでも使いそうな共通の入力項目名は統一するようにして、cookieなどのメカニズムにより初期値として入力されるようにしておきましょう。
フォームにたどり着いた直後に面倒になって離脱するユーザーは多いものですが、一度最後までフォームを入力したユーザーは、別の用件でフォームを入力する確率は比較的高いものです。この時、どのフォームでも入力するような情報が初期値で入力されていると、差分情報だけ入れれば良いことになり、ユーザーにとっては大変便利です。

そこまではちょっと、という場合であっても、少なくともフォームで取得するデータの「名前」は共通にしておくと、ブラウザが気を利かせて入力してくれるかもしれません。
データベースを使って会員管理システムなどを作りこまなくても、このぐらいのことはブラウザの機能を活用して実現可能です。

ポイント4:追跡できるように

訪問者によってはページのトラブルや誤記などを報告してくれる場合があります。しかしながら、具体的にどのURLでどの部分がどう間違ってる、というところまでビシッと教えてくれるような神指摘は大変稀で、通常は「ここ間違ってますよ」ぐらいしか書かれてなかったりします。

この状況で遷移元のページが分かるなら、少なくとも訪問者が指摘する「ここ」が遷移元周辺であると推定できます。このように、具体的にいつ、どのサーバで、どのページから飛んできてフォームに入力したか、というあたりの実行時に関する情報は記録(ログ)しておくべきです。この情報自体はお問い合わせ内容とは関連ありませんが、フォーム自体の問題や「月曜の4時ごろフォームで連絡したと思うんだけど」といった電話の問い合わせと突合するための手がかりとしてとても役に立ちます。

プライバシーポリシー、クッキーポリシーをどう構成するかにもよりますが、あくまでもトラブルシュートを目的として追跡情報を保存する場合、一定の期間を過ぎたら消してしまうように運用する方が良いでしょう。

ポイント5:WAFは大切

フォームは外部からの入力データを受け取って処理を行います。処理はなんらかの前提条件をもとに組み立てられている場合が多く、前提条件を満たさないデータを受け取った時、しばしば想定外の動作をしがちです。その想定外の動き(いわゆる脆弱性)を利用して攻撃をしてくる悪意のある相手もいるので、その予防策として、WAF(Web Application Firewall)をかけておきましょう(WAFについては、「クラウド型WAFとセキュリティ対策ついて、ざっくりと整理してみました。」をご参照ください)。

もちろんWAFも完全ではありませんから、WAFがあればすべての攻撃に対処できるといったものでもありません。しかしながら、フォームの処理でうっかり抜けてた部分を防御する役に立ちます。

ポイント6:全社全部署巻き込む

意外と忘れがちなのが、フォームで受けた問い合わせを処理するためのワークフローです。「まあ、Web担当者が振り分けをして担当部署に転送するのがいいんじゃないかな?」とか、安直に決めてませんか?

その問い合わせは急ぎのものかもしれませんし、部外者にはチンプンカンプンで、なんの話かわからない内容かもしれません。Webマスターが全知全能のパーフェクトなヒューマンビーイングであるならば無問題ですが、普通はそんなことはありません(たまに神的に広範囲を把握しているすごい方もいらっしゃいますが)。
自分が関わっていないビジネスに関する知識は、実は問い合わせた訪問者と同程度であることが一般的です。その場合、安直なワークフローだと「わざわざ反応を遅くするためにWeb担当者を介する」という誰も幸せではない構造になってしまいます。

ビジネスの詳細はその担当者が一番知ってるわけですから、フォームで受けた問い合わせは担当部署の担当者に直接飛ぶべきです(Web担当者には同報で通知があれば十分です)。そうすると前述の連携が生きてくるわけです。
フォームによる問い合わせの受付けは、訪問者が入力する問い合わせの時点で、担当するビジネスや業務の担当者に振り分けておくことが可能なのです。
つまり、関連する全部署、全組織を巻き込んであらかじめ合理的なワークフローを構築しておかないと、まともに運用できないのです。このあたりの根回しは十分注意しましょう。

ここで特に注意が必要なのは通知の宛先です。具体的に個人のメールアドレスなどにしてしまうと、その方が異動したり辞めたりした時に過去の情報を掘り起こせなくなってしまいます。理想的にはなんらかのリポジトリ(データベースやCRMのシステムなど)に蓄積して、担当者が入れ替わっても「歴史」を確認できるようにすべきでしょう。最低でもメーリングリストなど、共有を前提とした宛先にしておくべきです。

ポイント7:英語フォームは項目名の翻訳ではだめ

頑張って日本語コンテンツのフォームは整備したとして、同様に英語版のフォームも用意するとします。しかしながら、英語という言語ひとつとっても、言語に紐付いてさまざまな文化・習慣があり、これらとの整合性が取れていないと、なんだかよくわからない、使い勝手の悪いものが出来上がってしまいます。

例えば名前。よく見るのが姓と名で2フィールドにわけてあるものですが、果たしてすべての文化において姓名は定義可能でしょうか?あるいはよみがな。日本以外の文化圏では、よみがなってなんのことだかわからないかもしれません。

こうして入力フィールドの時点で数が異なるわけですから、単なる翻訳でうまくいくわけがないのです。。

同じ英語でも社会の制度に違いがあります。例えば、英国の郵便番号はアルファベットと数字が混ざってますが、米国の郵便番号は数字のみだったりするのは有名です。となると英語すなわちグローバルというわけでもないので、このあたりは丁寧に対応する必要があるでしょう。

以上、7つのポイントでお問い合わせフォームにまつわる留意事項をまとめてみました。落ち着いて考えればどれも難しいことではありません。現実的で合理的な運用をイメージできれば、よりよいコミュニケーションの起点としてフォームを上手に活用できるようになると思います。フォームの最適化について、何かご質問はございましたら、以下のフォームからお気軽にお問い合わせをお願いします。

Getting Betterとは

企業の忙しいWeb担当者(Web担当者)の方のために、コーポレートサイトやオウンドメディアの運営に欠かせない情報やトレンド・ノウハウを解説するブログです。

日々のサイト運営のご参考になれば幸いです。

IMAGICA Lab.のWebサイト構築サービスについてはこちら
https://www.imagica-imageworks.co.jp/web/

「株式会社IMAGICAイメージワークス」は、2018年10月1日に「株式会社IMAGICA Lab.」となりました。

トップへ