1 ポイント 投稿者 GN⁺ 2025-12-09 | 1件のコメント | WhatsAppで共有
  • 大規模な SaaS 企業が顧客からの問い合わせを避けるために作成した「fuck off contact page」 をサービス企業が模倣すると問題が生じる
  • このページは実際の人との接触を最小化するよう設計され、ユーザーが問い合わせを断念する構造を持つ
  • 一方、サービス型企業は顧客との信頼構築とリード獲得が重要であるため、このアプローチはビジネス目標と正面から衝突する
  • 「オフライン訪問」「営業チームへの連絡」といった選択肢だけを大量に並べた構成は、実質的に ユーザーを離脱させる装置であり、人と直接つながる要素はページ最下部に埋もれてしまう
  • あるクライアントが有名なサイトを似せるよう依頼した結果、実際の目標であるリード獲得・ユーザーサポートに合わないデザインを固執し、離脱を誘発するパターンがそのままページに反映された
  • プロジェクトは完了したが、専門家としての基準とクライアント期待の不一致、プロセスの教育不足、値引き単価が生んだ関係の非対称性が問題の根本原因だった

「fuck off contact page」の概念

  • 「fuck off contact page」は、企業が顧客との直接接触を避けるために作るコンタクトページ
    • 主に数百万〜数十億ドル規模の SaaS 企業で見られる
    • 顧客サポートコストを下げるため、実際のサポート窓口をログインの後ろに隠すか、限定的なチケットシステムで代替する
  • このようなページはエンタープライズ顧客のみ専任担当者や電話サポートを提供し、一般顧客はナレッジベースを通じて自分で問題を解決するよう誘導する
  • 結果として、企業側では問い合わせの減少が成功となる一方、利用者は**「連絡しないで」というメッセージを受け取る**体験になる

事例:サービス企業の誤った模倣

  • 執筆者が担当した サービス型デザインエージェンシーのウェブサイトリデザイン案件 でこの問題が発生
    • 元々の連絡ページはシンプルなフォーム形式だったが、クライアントは 大手 SaaS サイトのデザイン要素を模倣しようとした
    • 結果として**「営業チームにお問い合わせ」ボタンがページ下部にしかない**ため、実際の人との接触が極端に困難になった
  • これは顧客フレンドリーであるべきサービス企業の目的と衝突する
    • SaaS 企業は問い合わせを減らしたいが、サービス企業は支援を提供し、リードを獲得する必要がある
    • ユーザーは「営業チームにお問い合わせ」ボタンを見ると即座に離脱するか、自力で解決しようとすることになる

プロジェクトの進行と限界

  • デザインチームは クライアントを説得できなかった
    • プロジェクト範囲内で他の変更要求を抑えるため、優先順位が後回しになった
    • その結果、問題点を認識しながらもそのまま進め、納期とコストは合わせたものの、社内では品質への不満が残った
  • 完成後、クライアントは満足したが、デザイナーは 「smoke and mirrors(煙と鏡)」のような業界の幻想に加担したという自責感を覚えた
    • 結果物が 自分の名前を付けられるレベルではなかったという失望感

「fuck off contact page」を避ける方法

  • 問題の起点は プロジェクト着手前の関係設定にあった
    • 知人の依頼による値引き価格を提示したことで、クライアントはデザイナーを 専門家ではなく単なる実行者 と認識するようになった
  • デザインプロセスの教育不足も原因
    • 多くのクライアントと一部のデザイナーは、ディスカバリーとワイヤーフレームの段階を単なる手続きだと誤解している
    • しかし、何をなぜ作るのかを理解するプロセスが核心であり、ブランドよりも情報構造とフロー設計が優先される
  • 値引き価格は信頼より搾取の可能性を示すサインとして機能し、協業全体に不信が生まれる
    • 建設的な異議が尊重される関係構築は依然として課題として残る

1件のコメント

 
GN⁺ 2025-12-09
Hacker Newsの意見
  • 以前、小さなエージェンシーで働いていたとき、顧客が30項目以上ある問い合わせフォームを求めていたのを思い出す
    その大半が必須入力で、ユーザーの目的が想定と少しでも違うと本当に苦痛だった
    実際に必要なのは名前、メールアドレス、そしてテキスト入力欄だけだったのに、多くの顧客が複雑なフォームにこだわっていた
    こうしたフォームは結局ただメールに変換されて会社代表に送られるだけで、データベースすらなかった
    今でもGitHubの過剰なIssueテンプレートを見るたびにあの頃を思い出す — ただドキュメントの壊れたリンクを知らせたいだけなのに、OSのバージョンやビルド情報、果てはCLA署名まで求められて、もうやめようと思ってしまう

    • こういう現象は、GitHubのコントリビューショングラフと「Issues」という命名から生まれた文化のせいだと思う
      今では、ただ助けようとしている近所の人ではなく、何かを要求してくる人として扱われる空気がある
      参考: The Pez Dispenser, Here Comes Everybody
    • ただ、場合によっては複雑なフォームが合理的なこともある
      たとえばスポーツチームのグッズショップを専門にするデザインエージェンシーなら、「あなたのチームはどの競技ですか?」のような質問で不適合な顧客を自分でふるい落としてもらうことができる
      もちろん一部の見込み客は失うかもしれないが、その分より質の高いリードを得られる
  • 「エンタープライズ風」の問い合わせページは、リード数を減らす直接的な原因になる
    現在リードが不足している状況では、こうしたアプローチは売上減少につながる
    こうした事実をデータとともに予算担当者へ率直に伝えるほうがよいと思う

    • ここに実際のデータやケーススタディがあれば、さらに説得力が増しそうだ
      自分はカスタマーサポートが良い会社にはより長く留まる傾向がある。製品が多少物足りなくても、フィードバックを本気で反映してくれる会社には信頼が生まれる
    • ただし、顧客を叱るような言い方をすると関係がこじれる可能性がある
    • クライアントごとに違うアプローチが必要だ。率直な分析をありがたがる顧客もいれば、見下されたと感じる顧客もいる
    • デフォルトフォントのほうがずっと読みやすかった。lenowo.org のようなサイトは可読性が低くて不満だった
    • フォント変更オプションがどこにあるのか気になる。サイトを読むためにゲームのように探し回るのは嫌だ
  • このサイトのデザインは本当に印象的だった
    「オールドウェブ」を復活させるなら、これくらいの独創性は見せるべきだ

    • SafariのReaderモードのおかげで実際に文章を読めた
    • ただ、モバイルでは読みにくかった。画面の半分がアイコンで隠れ、スクロールバーもないので文章の長さも分からなかった
    • 自分もこのスタイルを真似したいと思ったが、こういうデザインを実装できる技術が自分にはないと気づいた
    • デザイナーの別作品もおすすめ → https://www.nicchan.me/art/
    • スクロールが壊れていていらいらした。ページ全体と偽のウィンドウのどちらをスクロールすべきか混乱した
  • 連絡手段を隠す会社は本当に信頼できない
    スパムを避けたい理由は理解できるが、カスタマーサービスそのものを隠すのは卑怯に感じる
    顧客は単なる不満ではなく、実際に金銭的被害を受けることもあり得る

    • ただ、規模が大きくなるとサポートコストは高くなりすぎる。すべての顧客に個別対応を提供するのは不可能だ
      サポートは高コストであり、事業規模に合わせて調整せざるを得ない
    • 私のドメイン登録業者 GKG はメールアドレスと電話番号をヘッダーにすぐ表示している。こういう透明性は新鮮に感じる
    • Facebookのように中核機能を提供していながら問題解決手段がないのは最悪だ。アカウントが停止されたら終わりだ
  • 大企業の内部でも、こうしたチケット受付の複雑化が進んでいる
    ちょっとした依頼を1つ出すだけでも苦痛な旅になり、電話でさえ音声チャットボットが立ちはだかる
    ビジネス効率のためだと言うが、本当に異常なやり方だ

  • この分野で働く立場から見ると、一部の製品ではログイン後でも特定の資格を持つ開発者だけがサポートチケットを作成できる

    • ウェブホスティング会社の中には、ログインするためにクレジットカード登録が必須なところがある
      Hetznerもそうだったが、こういう方針はあまりに不便だった
      Upcloudはカード情報なしでもサポートしてくれて、その点が本当に印象的だった
      今では価格よりも直接会話できるサポートチャネルを重視するようになった
      Hetznerにはこうした点を改善してほしい。サービス自体は気に入っている
  • もう1つの問題は、ログインした顧客しか連絡できないページ
    HetznerやContaboがそうで、OVHはその点まだDiscordサーバーを運営していて基本的な問い合わせができた
    自分は匿名性を重視しているので、カード情報を求める仕組みには違和感があった
    一部の会社は悪意ではなく、単なる無知からこうしたシステムを作っているのだと思う
    こうした問題を指摘する文章が認識改善の助けになればよい

    • Scaleway は公開Slackコミュニティを運営していて、エンジニアと直接話せる
      ただ、その副作用として偽のアカウント復旧依頼が増える
      結局こうした制限は悪意というより自己防衛的な措置であることが多い
  • 自分はこうした問い合わせフォームの不安定さがむしろおかしいと思う
    静的サイトで唯一インタラクティブな部分なのに、しばしば500エラーで落ちたり、メールが消えたりする
    設定した人がすでに会社を去っていることも多い

  • このウェブサイトはブラウザのリーダーモードすら壊してしまう例だ

  • 文章全体がややナイーブに感じられた
    顧客が単なるデザイン会議1回でカスタマーサポートに大規模投資するとは思えない
    ウェブ開発者がこうしたビジネス上の意思決定をあまりに重く受け止めているのも理解しづらい

    • ただ、専門家の意見を無視するのはおかしい。他の業種では、顧客が専門家の助言をここまで簡単に拒否することはあまりない
    • 顧客は大規模なサポート投資を望まないだろうが、だからといってサポートを敵対的にしたいわけでもないはずだ
      おそらくスパムのせいで複雑なフォームに移行した可能性が高い
    • 筆者は「sales team」という言葉にこだわりすぎているように思う
      機能を減らそうという提案は行き過ぎだ。「get in touch」のような中立的な表現に変える程度が適切だろう
    • ウェブ開発者は顧客が失敗すると報酬を得られないので、顧客の成功に利害関係がある
    • 結局これはカスタマーサポートではなくリード獲得の問題だ。SaaS文脈ではない点を誤解しているようだ