いいえ、私はあなたの問い合わせフォームを埋めたくありません
(adamjones.me)- 問い合わせフォームは、メールアドレスを公開する方法に比べて、故障・アクセシビリティ・記録の欠如・不要な個人情報要求といった問題が多く、利用者と運営者の双方により大きな負担を生みやすい
- B&Q、AWS abuse contact form、Axa、Vodafone、Virgin Mobileの事例のように、フォームが送信できなかったり、有効なメールアドレスを拒否したり、支援技術の利用者に不利に動作したりすることがある
- UK Charity Commissionの苦情フォームはページごとに約6〜7秒かかり、11ページを経由しなければならず、National Gridのフォームは些細なフィードバックにも住所や電話番号のような個人情報を要求する
- メールなら下書き作成、予約送信、記録保存、ワークフロー統合が可能だが、問い合わせフォームは送信確認や内容の控えすら提供せず、利用者がスクリーンショットで証拠を残さなければならないことが多い
- 構造化データの収集、チームへの割り当て、スパム対策、セキュリティ、アクセシビリティは、たいていメール・自動応答・共有メールボックス・カスタマーサポートツールで解決できるため、一般的な問い合わせにはメールアドレスの公開の方がシンプル
問い合わせフォームが利用者に不利な理由
- 問い合わせフォームは、Webサイトにメールアドレスを載せる方法よりも、利用者に悪い体験を与えることが多い
- WordPressのアップグレードやCRM変更のような理由でフォームが静かに壊れることがあり、利用者は送信ボタンを押した後になって初めて失敗を知る
- B&Qの問い合わせフォームは送信不能な状態で、ネットワークリクエストを見る限り、フロントエンドには存在しない
title属性の欠落が原因でエラーになっていたようだ- エラーメッセージは、再試行しても解決しない状況で利用者に逃げ道を与えない
- AWSのabuse contact formは数か月間壊れていたというHacker Newsでの事例があり、Elastoplastの問い合わせフォームも問題例として言及されている
一部の利用者にだけ壊れるフォーム
- Axaの問い合わせフォームは、一部の有効なメールアドレスを誤って拒否する
test+test@example.com、tést@example.com、test@éxample.comはRFC 6532に照らして有効だが、そのフォームでは拒否された- フォームには関連するAxa製品がすべて表示されていない
- Vodafoneの紛失・盗難端末の報告フォームは、夜間メンテナンスのためサイトが頻繁に利用不能になる
- 携帯電話を盗まれた利用者が報告しようとすると、メンテナンス画面に出くわす可能性がある
- 多くの問い合わせフォームは基本的なWebアクセシビリティ基準を満たしておらず、支援技術の利用者には入力が難しい
- Virgin Mobileの苦情ページは選択状態の表示を隠しており、キーボード操作がほぼ不可能になっている
作成時間と個人情報の要求
- UK Charity Commissionの苦情フォームは各ページの読み込みに約6〜7秒かかり、完了には11ページを経由する必要がある
- ページ読み込み待ちだけで約75秒を要する
- 進行状況の表示がない
- 入力フィールドに
autocomplete属性がなく、利用者は各項目を自分で毎回確認しなければならない - ドロップダウンの選択肢がグループ化されておらず、並び順にも一貫性がない
- National Gridのcontact・feedbackフォームは、簡単なフィードバックに対しても自宅住所や電話番号のような個人情報を要求する
- 電話番号形式のような単一のミスがあるだけで、入力内容が消え、最初から書き直しになる
- 一部の苦情フォームは、生年月日や身分証のコピーのような、より機微なデータを要求する
- その組織が本来その情報を保有していない場合でも要求されることがあり、セキュリティ確認のために既存記録と照合する目的ですらない
- 一般的な問い合わせフォームで、肩書き、職務、会社規模、固定電話番号のような項目は、実際には必要ない可能性が高い
- 不要な個人情報の収集は、データ漏えいやなりすまし詐欺のリスクを高め、信頼しにくい組織ではスパムの懸念も強めるため、利用者が送信を断念したり虚偽情報を入力したりする原因になる
メールがもたらす実用的な利点
- メールは、利用者が下書きを作成し、予約送信し、やり取りの記録を簡単に残せるようにする
- 後でフォローアップするためにメッセージをスヌーズするなど、既存のワークフローにも統合しやすい
- 問い合わせフォームはこうした機能をたいてい提供せず、正常に動作していても、利用者が後から参照できる確認メッセージを受け取れないことが多い
- 送信した詳細をすべて含む控えは、さらにまれである
- ある企業ではフォーム送信が失われ、利用者が保存していたスクリーンショットを提示して初めて再発見されたという経験がある
- 問い合わせフォームは、正しく作って維持するのに時間と労力がかかるが、裏側ではほとんど常にメールか、メールを受け取るシステムにルーティングされる
- 中間段階をなくしてメールアドレスを公開する方がシンプルである
- フォーム経由の問い合わせに返信するとき、利用者が元々何を送ったのか思い出せない状況も起こる
- 最初からメールであれば、原文を一緒に確認できる
煩わしいインターフェースの例
- Sainsbury’sの問い合わせフォームは、長いオプションツリーをたどらせた後、モーダル内で再び同じトピックを選ばせる
- その後に表示されるフォームのウィンドウは非常に小さく、ほとんど入力不可能なレベルである
- 問い合わせフォームは上記以外にも、さまざまな形で利用者に不要な摩擦を生むことがある
構造化データが必要なとき
- 問い合わせフォームで構造化データを受け取り、リクエスト処理時間を短縮したいことはある
- 顧客識別子を正確に受け取ったり、問い合わせを自動的に適切なチームへ割り当てたりする目的があるかもしれない
- この方法は、一部の状況では妥当な場合もある
- Amazonは最近の購入商品を表示し、返品依頼のような一般的なカスタマーサポートの流れをセルフサービスで処理させつつ、人間につながる経路も比較的簡単に提供している
- 優れたカスタマーサービス用ポータルがないなら、一般的な問い合わせにはメールの方が良い
- 必要な詳細情報は、合理的な自動応答で受け取れる
- GP at handの自動応答は、全体として明確で長すぎない例として扱われている
- 利用者が最初から必要な情報を入れられるよう、mailto linksに件名と本文のパラメータを含めることもできる
- 例では、関連サポートページ、名前、アカウント番号、問い合わせ内容を事前入力する方式が示されている
問い合わせの分類とチーム運用
- 問い合わせを自動でチームに割り当てる前に、そもそもその自動化が必要かどうかを確認すべきである
- 1日に受け取るメールが2通しかない、あるいは結局すべて同じ人に届く小さなチームなら、問い合わせフォームで分類する必要性は低い
- 本当に自動割り当てが必要なら、Zendesk AIのようなプラットフォームを検討できる
- チーム単位のメッセージ管理はメールでも可能である
- shared mailbox
- collaborative inbox
- Zendesk、Zoho Desk、Freshdesk、Request Tracker、Zammad、osTicket、FreeScoutのようなカスタマーサポートツールをメールに接続できる
連絡の障壁、スパム、セキュリティ、アクセシビリティ
- 問い合わせフォームが連絡の障壁を下げるという考えは、経験的にはあまり当てはまらなかった
- 3つの組織でメール公開に切り替えた後も、実際の問い合わせ数はフォーム使用時とほぼ同じだった
- 厳密なデータ分析と公開があれば、他者を説得する助けになるかもしれない
- ごく低い労力で送れるフィードバックフォームは例外になりうる
- 親しみやすく、カジュアルなメールでも歓迎すると明記すれば緩和できる可能性がある
- 匿名性が好まれる状況では、フォームが障壁を下げる可能性がある
- 性的指向を公表していない人が、関連コメントを自分のメールと簡単に結びつけられたくないことはありうる
- GOV.UKには、匿名フィードバック収集にうまく機能するシンプルな例がある
- メールアドレスを公開するとスパムが増えるという心配は、実体験とは異なることがある
- WordPressフォームより、メール公開後の方がスパムが少なかったケースがあった
- 匿名フォームは無意味な入力をしやすい一方で、今日ではスパムフィルタを通過する評判の良いメールを送る方が難しい可能性がある
- 心配なら、スパムボットに見つかりにくいようメールアドレスを難読化することもできるが、こうしたスパムはまれであり、スパムフィルタも向上しているため、たいていは時間の無駄かもしれない
- 難読化の過程で実装を誤って何かを壊すリスクもある
- メールは過去には暗号化されておらず非常に安全性が低かったが、2024年には一般的な設定であれば、他のメールトラフィックの約**99%**と同様に安全に暗号化される可能性が高い
- 顧客が暗号化をサポートしないメールプロバイダを使っている理論上の可能性はある
- UK National Cyber Security Centreも独自の連絡用メールアドレスを公開している
- 問い合わせフォームを使っていても、その後メールで返信するのであれば、メールセキュリティだけを理由にアドレスを公開しないという理屈は弱い
- アクセシビリティ標準への準拠のために問い合わせフォームが必要だという主張は事実ではない
- メールアドレスを公開する方法の方が、問い合わせフォームよりも解析しやすく理解しやすい可能性が高い
- Equality and Human Rights Commission、Scope、AbilityNetも連絡用メールアドレスを公開している
意図的に難しく作られたフォーム
- 一部の組織は、規制上要求される連絡経路を、実際には使いにくくしたいと考えている可能性がある
- Metaはデータ保護に関する連絡を非常に難しくしており、複数の慈善団体がMetaのフォームは見つけにくく、記入しにくいと指摘している
- 筆者の経験では、Metaの関連手続きは複雑で時間がかかり、複数の壊れたフォームへ案内された
- 規制当局は、法律や規則の文言だけでなく趣旨まで守る主体が報われるよう、基準をより適切に設定すべきである
結論
- 問い合わせフォームは適切に作るのが難しく、関わるすべての人にとってより悪い体験になりやすい
- 一般的な問い合わせには、問い合わせフォームをなくし、Webサイトにメールアドレスを公開する方がよい
1件のコメント
Hacker News のコメント
年を取り、気難しくなるほど、可能なら関わらないことが最善だと気づいた。
レストランが汚かったりスタッフが失礼だったりすれば行かないし、Webサイトにダークパターンがあったり問い合わせフォームが機能しなかったりすれば、そのサイトは使わない。
理由は2つあって、たいていの事業者は自分たちが壊れていることを知っていても気にしないし、悪い体験を避けることは自分のストレスにも良いから。
もちろん医療のような必須サービスには適用しにくい。
求人サイト、エージェント、雇用主のサイトがどれもひどい。
いちばん強烈だったのは、自ら Easy Apply と呼んでいた雇用主のサイトで、履歴書をアップロードするとひどくパースして、大量のテキストボックスにでたらめに流し込んだ。
PDFが問題なのかと思ってWord文書でやり直したが結果は同じで、おそらくWordをPDFにエクスポートしてから同じひどいパーサーを使っているようだった。
そのテキストを正しい欄に戻すだけでも腹立たしいのに、普通の入力欄ですらなく、入力の反応が非常に遅い粗悪なJavaScriptの塊だった。
それでいて雇用主たちは、良い人材を見つけるのは難しいと愚痴を言う。
これに気づいてからは、そういうシグナルが見えたらすぐタブを閉じて振り返らないので、時間と労力をかなり節約できた。
低品質コンテンツの作り手が見分けやすくしてくれて、ありがたいくらいだ。
メッセージ、メール、コメント、議論をする前に、目的は何で、そこで得られる最善の結果は何かを考えろという意味だ。
この助言のおかげで、ただ受け流すことがずっと楽になった。
Webサイトがひどく、もっと良く作れるというのも正しいし、相手が明らかに間違っているというのも正しいが、関わったところで少しのカタルシス以外に得るものはなく、全員の時間を無駄にするだけだ。
だから、そのまま手放すほうがいい。
本来はそのくらい簡単であるべきだったのに、実際にはユーザー名、メールアドレス、電話番号、特定の条件を満たすパスワードまで要求する完全なアカウント作成をさせられた。
有効なパスワードを3回作れなかったので、彼らは私が飲みすぎたと思って助けようとしてくれたが、彼らも何度試しても、私のお金を受け取るためのアカウントを作れなかった。
彼らのWebサイトと不要なアカウント作成ポリシーがコンバージョンを積極的に妨げているわけで、しばらく笑ってしまった。
もちろん笑われた人たちはこの問題の中心人物ではなかったので、得意げになるのは抑えて、同僚に伝えてみてはと提案した。
技術的には勝てたとしても、ストレスや精神状態を考えると、ただ流すほうがずっといい。
すべてに当てはまるわけではないだろうが、人生の大半の小さな苛立ちには当てはまりそうだ。
「問い合わせフォームに記入したくない」というのはその通りだが、企業や政府もあなたから連絡を受けたがっているわけではない。
彼らにとってはコストだからだ。
平均的な「営業見積もり問い合わせ」フォームは、平均的な「苦情受付／質問」フォームよりも明確で、摩擦も少ない。
人々がメールではなくフォームを使う理由の1つは、あるWebサイトに客として入り、そこのフォームに記入するという状況と文脈にあるのかもしれない。
自分のメールボックスにいるときと、他人のサイトにいるときでは、行動の仕方が変わりうる。
GitHubのIssueテンプレートにある、時に過剰な質問がその例で、必要な情報を強制すると同時に、自分が客であり、相手のコミュニケーション規範に従うべきだという点を示唆している。
誰かのフォームに数分かけて記入することすら頑なに拒むなら、その後のあらゆるやり取りでも要求が多く、協力的でない可能性が高い。
もちろん、そういう人たちは自分をそうは見ていない。
ひどい問い合わせフォームを置くのは、レストランのウェイターが客の顔に唾を吐きかけながら挨拶するのと同じくらい意味がわからない。
今の世の中の動きを見ると、数年、あるいは数か月以内にそれが標準になるかもしれないが。
問い合わせフォームを作るなら、少なくとも**「メッセージを受け取りました」という自動メール**くらいは送ってほしい。
そうすれば、バックエンドが実際に受け取り、有用などこかへ届いたはずだという最低限の確信が持てる。
自動返信がないと、きちんと動作したのかいつも疑ってしまう。
悪意のある人が、こうしたフォームのあちこちに他人のメールアドレスを入れてスパムを送るのを、何が防げるのだろうか。
ランダムに生成したメールアドレスを大量に入れてサイトをDDoSするのは、また何が防げるのだろうか。
そして、こうしたフォームのスパムがメールクライアント上でスパムに見えるようになれば、本当に重要かもしれないメッセージまでスパム扱いされ、自動削除される可能性がある。
「共有メールボックス、共同作業型の受信箱、Zendesk、Zoho Desk、Freshdesk、Zammad、osTicket、FreeScout のような既製のカスタマーサポート・ソリューションをメールに接続せよ」というリストには、古典であり今なお優れた Request Tracker が抜けている
https://bestpractical.com/request-tracker
https://github.com/bestpractical/rt
関係者ではなく、リクエスト提出者の立場でしか使ったことはないが、いつも直感的で安定していた
同じシステムが20年ほど動き続けてきたという点にも価値があるし、ある小さな機関で大型プリンターのジョブ提出用に Request Tracker をつないで使っているのを見たこともあるほど柔軟だ
RT が恋しい。見た目はひどかったが、良かった
Zendesk はいまだにユーザーを削除できない。それはその機能が、私たちが使っていない「Support」の一部だからで、ユーザーを作成することは今でも「Chat」の一部なので可能だ
Perl は何十年も人気言語ではないし、2024年に Perl 開発者を採用しようとすると簡単ではないだろう
AI が助けてくれるケースかもしれないが、AI も RT の「スクリプトレット」を知っているかは確かではない
問い合わせフォームは死んだ。最近は箱に文章を入力すると、LLM が自分の問題とはまったく関係のない答えをいくつか返してくる
サポートチームに連絡したければ、解約すると脅さなければならない
それすら気にしてくれるなら、の話だが
以前はケーブル会社に電話して解約すると言うと、顧客維持担当者に回され、数年前の価格水準まで下げる取引を提案されたものだった
最後にその手を使ってみたときは、少し保留にされたあと、「承知しました、お客様。本日付でサービスは解約されました。ほかにお手伝いできることはありますか？」と返ってきた
会社のアカウントをタグ付けして不満を投稿し、必要ならそれを増幅してくれる大手メディアや有名なネットクリエイターのタグもいくつか付ける
たとえば近年、YouTube クリエイターがハッキングされたアカウントを取り戻したほぼすべての事例は、Twitter などで Team YouTube をタグ付けして解決したものだった
今ではソーシャルメディア上の PR 悪夢になる可能性だけが企業を動かすようだ
100%ではないにせよかなり良く、「この FAQ 項目で問題は解決しますか？」を繰り返す昔のサポートチャットボットよりは良かった
そういう FAQ は絶対に問題を解決しなかったからだ
[0] https://news.ycombinator.com/item?id=40246171
フォーム経由で入ってくるスパムの比率はおおむね時間がたっても一定だが、公開されたメールアドレスに届くスパムは、サイトがスパムボットに繰り返しスキャンされ、そのアドレスがどんどん多くのスパマーのリストに追加されるにつれて増えていく
スパム検出は良くなったが完璧ではなく、スパム全体の量が増えるほどフィルターをすり抜けてくる量も増える
ある時点からは、スパムフォルダーの中から誤分類された本物のメールを探すことも不可能になり、結局は圧倒されてメールアドレスを変えなければならなくなる
公開メールアドレスを載せるなら、スパム量が多くなりすぎたら交換する消耗品として見るべきだ
筆者がこれを経験していないのだとしたら、公開ウェブサイトに生きているメールアドレスを何年も置いたことがないからかもしれない
もちろん、私が十分に有名ではないのでその問題を経験していないだけかもしれない
かつてはスパムフォルダーに1日約500件入っていたが、今は同じアドレスで平均1日2件程度だ
かなり前から、スパムが通過することよりも、スパムフィルターが正当なメールをスパム扱いしたり、そもそも配信しなかったりする問題のほうがはるかに大きい
準経験的には、メールアドレスと問い合わせフォームを5年以上掲載したサイトを運営してきたが、こうした効果には気づかなかった
ただし定量的に十分調べたわけではないので断言は難しく、データがあるなら分析を見てみたい
残念ながら該当する受信箱は時間がたつとスパムを自動削除するため、記録が残っていない
このデータを持っているなら誰か公開してくれるとうれしいし、分析へのリンクを喜んで記事に追加したい
理論的には、問い合わせフォームのリンクも時間とともにどんどん多くのリストに追加され、同じ問題が起きるのではないかと思う
フォームでもこうしたパターンを見たわけではないので、実際にそうだと主張しているのではなく、論理上思い浮かんだ思考実験に近い
ついさっき会社用の新規顧客問い合わせフォームを作った
メールの代わりにフォームを使った理由は、第一にフォームのほうがより非人格的に感じられ、取引したくない見込み客に返信しなくても罪悪感が少ないこと、第二に JavaScript なしでも動作し、JS による難読化なしでメールを表示するとスパムが増えそうだったことだ
EU なのかドイツなのかは確かではないが、オンラインで営業するすべての会社が顧客連絡用に実際に確認しているメールアドレスを持たなければならないという規定は気に入っている
会社から、信頼できて継続性のある媒体で書面の回答を得られるほぼ唯一の方法であることが多い
企業のサポートチャットはたいていひどいし、電話は紛争になったときに証拠が残らない
https://www.gesetze-im-internet.de/tmg/__5.html
noreply@ からメールを送らないでほしい
私のメールを望んでいないなら、私もそちらのメールは望んでいない
ただし、一つだけ留意点はある。大企業ならリソースがあるのだから、入力しやすい問い合わせフォームを用意すべきだと思うが、個人でプロジェクトを作っている開発者の立場では、問い合わせフォーム経由で無駄な依頼を本当にたくさん受ける
スパムでもなく、かなり多くのユーザーは問い合わせフォームをチャットボットのように考え、個人的だったり手抜きだったりする質問を投げてくる
時には質問ですらなく、「製品を使いたいです」のような一回きりの文だけを送ってくる
それならそのまま使えばいいのではないか
あまりに奇妙なので、フォームをさらに隠し、フィールドを追加して少し摩擦を入れるようになった