機能の説明ばかりで顧客の課題とつながらない
サービスページや資料に機能は並んでいるのに、読み手は「それで自社の何が変わるのか」を自分で考えなければなりません。営業が商談で説明を足して、ようやく話が通じる状態です。この記事では、この課題を3つの症状に分け、自社がどれに当たるかの見分け方と、機能の説明を顧客の課題の言葉に置き換える打ち手を整理します。後半では、機能の説明は削らずに判断の土台として残し、その機能がどんな困りごとを解くのかまでつなぐ、という考え方も紹介しています。ぜひお読みください。
この課題を分解すると
この記事で扱うのは、ページや資料に書いてある説明の中身です。見込み客が自分に関係するページにたどり着けるかという入口の話は、見込み客が、自分の業種や用途に合うかをサイトで判断できないで扱います。説明の中身を見ていくと、性質の違う3つの症状が混ざっています。
① 機能の一覧に、解く困りごとが書かれていない
サービスページや資料に、機能名と仕組みの説明が並んでいます。「データを自動で集計」「権限を細かく設定」のように、何ができるかは分かります。ただ、その機能が誰のどんな困りごとを解くのかは書かれていません。読み手は、機能と自社の状況を自分で結びつけるしかありません。
商談で「それで、うちの何が楽になるんですか」と聞かれる、営業が機能の説明のたびに同じ補足をしている。こうしたことが起きていれば、この状態です。
② 課題の書き方が、どの会社にも当てはまる
「業務効率化」「属人化の解消」といった課題は書かれています。ただ、どんな場面で、誰が、何に困っているのかまでは書かれていません。同じ言い方はほかの会社のページにも出てくるため、読み手は自分の状況と重ねられず、機能とのつながりも読み取れません。
課題の段落と機能の段落が別々に並んでいて、どの課題をどの機能が解くのかが書かれていないときも、この状態です。
③ 事例や技術資料が、仕様や技術の話で終わっている
導入事例や実績紹介、技術資料はあります。ただ、採用した技術・構成・仕様の説明で終わり、相手がどんな課題を抱えていて、導入して何が変わったかが書かれていません。技術を確かめたい担当者には役立っても、課題を抱えている担当者や決裁者には、自分の話として読めません。
営業が口頭で「この案件は、実はこういう困りごとから始まった」と補っているなら、この状態です。
自社がどれに当たるかは、主なサービスページ1枚と、商談でよく使う資料・事例を並べると見分けられます。
- 機能ごとに、その機能が解く困りごとが1文でも書かれているか
- 書かれている課題の言い方が、競合のページにもそのまま当てはまってしまわないか
- 事例や実績の説明に、導入前の困りごとと導入後に変わったことが書かれているか
1つ目が書かれていなければ①、課題は書かれていても2つ目に当てはまれば②、事例や実績で3つ目が欠けていれば③です。重なっている場合は①から手をつけます。機能と課題の対応が無いままでは、②の場面も③の事例も、どの機能につなげるかが決まらないためです。
機能の説明と顧客の課題がつながらない状態には、困りごとが無い・課題が一般的・事例が技術で終わるの3つの症状が混ざっていて、どれが起きているかで書き換える場所が変わります。
- 課題①機能の一覧に、解く困りごとが書かれていないサービスページや資料に、機能名と仕組みの説明が並んでいます
- 課題②課題の書き方が、どの会社にも当てはまる「業務効率化」「属人化の解消」といった課題は書かれています
- 課題③事例や技術資料が、仕様や技術の話で終わっている導入事例や実績紹介、技術資料はあります
「機能の説明ばかりで顧客の課題とつながらない」原因
解決策① 機能ごとに解く困りごとを書き出す
機能に加えて、その機能がなぜ相手にとって大事かを書くことは、マーケティングの文章の基本としてよく勧められます。HubSpotは、機能は製品が何をするか、ベネフィットはその機能がなぜ大事で相手をどう助けるかを表すと整理しています（HubSpot「Features vs. Benefits」）。
才流のチェックリストでも、サービス・機能紹介ページの見出しを、読み手の得が伝わる形にすることが挙げられています（才流「BtoBサイトのチェックリスト② サービス・機能紹介ページ」）。
手順は3つです。まず、サービスページと資料に出てくる機能を一覧にします。次に、機能ごとに、営業とカスタマーサクセスに「この機能を見せたとき、相手が反応した困りごとは何か」を聞いて書き込みます。最後に、「困りごと→機能→導入後に変わること」の順で1行ずつまとめ、ページの見出しと本文をこの順に並べ替えます。
つまずきやすいのは、困りごとの欄を推測で埋めることです。誰からも聞いたことのない困りごとしか書けない機能は、今のところ課題とつながっていません。見出しの候補から外し、一覧の後ろに置きます。
仕様や比較表は、技術面を確かめる担当者のために、課題の説明の後ろに残します。
解決策② 課題を困っている場面の言葉に書き換える
「業務効率化」のような言い方を、誰が、いつ、何に困っているかの言葉に置き換えます。たとえば「月末の締めのたびに、担当者が3つの表を手で突き合わせている」と書くと、読み手は自社に同じ場面があるかを確かめられます。そのうえで、その場面の困りごとを解決策①で書き出したどの機能が解くのかを、同じ段落の中でつなぎます。
材料は、商談の記録、問い合わせの文面、受注した顧客への取材です。相手が自分の言葉で話した困りごとを、言い回しを変えずに抜き出します。才流は、価値の表現に迷ったら顧客対応をしている営業担当に相談するよう勧めています。商談で反応のよかったスライドをサイトに載せる方法も挙げています（才流「BtoBサイトの改善ポイント② サービス・機能紹介ページ」）。「ソリューション」のような抽象的な語を避けることも、先のチェックリストに入っています。
場面は1つに絞りすぎず、商談でよく聞く困りごとから2〜3つ書きます。専門用語が多くて伝わらない場合の言い換えや図解は、専門的すぎて説明に時間がかかるで扱います。
解決策③ 事例と実績を課題・取り組み・成果の順で書く
導入事例は、顧客の課題、取り組み、成果の順で書くのが定番の型です。HubSpotは事例を、背景・課題・解決・結果で組み立てるものと説明しています（HubSpot「Case Study Templates」）。
事例の型を解説した記事でも、課題の部分はふつう全体の3分の1以上を占めるとされています（Content Marketing Institute「Case-Study Writing Made Faster, Better, and Less Painful」）。今ある実績紹介が技術や仕様で終わっているなら、書き足すのは前と後ろです。導入前に何に困っていたか、なぜそれが問題だったか、導入して何が変わったかを担当者に聞いて書き足します。採用した技術や構成の説明は、取り組みの部分に残します。
成果の数字が出せない場合は、担当者の作業や社内の判断がどう変わったかを書きます。
技術資料も同じ考え方で、冒頭に「どんな現場の、どんな課題を解くための仕様か」を1段落置きます。営業が商談で話している説明と、よく受ける質問を洗い出すと、その段落の材料になります。事例の数そのものが足りない場合や、社名を出せない場合の書き方は、導入事例が少なく、自社に近い事例を見せられないで扱います。
アイコネクトの見解
機能より顧客にとっての価値を書くことは、一般によく勧められます。そのうえで、機能の説明は削らずに判断の土台として残し、その機能が誰のどんな困りごとを解くのかまでつなぐのがよいと考えています。機能を理解した読み手が自分の困りごととのつながりに気づいたとき、初めて自分たちに必要なサービスかもしれないと考え始めるためです。つなぐ課題も、相手が最初に口にした言い方で止めず、「なぜそれが問題なのか」を重ねた先の課題とつなぐと、どの会社にも当てはまる説明になりにくくなります。
アイコネクトで相談できること
サービスページで機能と顧客の課題をつなぎ直し、意思決定に必要なページや導入事例を設計するところは、Web改善コンサルティングで扱っています。サービス資料を「サービスへの理解」「導入後のイメージ」の観点から組み直す場合は、サービス資料制作・改善サービスの範囲です。導入事例の取材と原稿づくりは、コンテンツ制作サービスで扱っています。
見立てだけでも構いません。主なサービスページのURLかサービス資料と、商談でよく受ける「それで、うちの何が変わるのか」に近い質問をいただければ、3つのどの症状が起きているかと、どの機能から課題の言葉に書き換えるかを見立ててお返しします。
よくある質問
「何のサービスか・何が良いのかが伝わらない」「自社の主語が強すぎて読まれない」とは、どう違いますか？
「何のサービスか・何が良いのかが伝わらない」は、サービス全体として誰の何をどう変えるかが伝わっていない状態です。「自社の主語が強すぎて読まれない」は、文章が自社を主語にして書かれている状態です。こちらは、サービスの全体像は伝わっていても、一つひとつの機能が相手の困りごとと結びついていない状態を扱います。商談で「何をしている会社か」を聞かれるならそちら、「この機能でうちの何が変わるのか」を聞かれるならこちらから手をつけます。
書き換えは、マーケティングと営業のどちらが担当すればよいですか？
書くのはページや資料を管理している側、材料を出すのは営業とカスタマーサクセス、と分けると進めやすくなります。営業の時間を取りにくい場合は、商談の録画や議事録から、相手が困りごとを話した部分を抜き出すところから始められます。書き換えた文は営業に読んでもらい、商談で聞く言い方とずれていないかを確かめます。
どのページから手をつければよいですか？
見込み客が商談の前に読んでいることの多いものから始めます。アクセスの多いサービスページか、ダウンロードの多いサービス資料のどちらか1つを選び、主な機能3〜5つ分を書き換えます。そのあと商談で受ける質問が変わったかを営業に聞くと、ほかのページに広げる前に手応えを確かめられます。
この課題がよく出る業種
代表・広沢のnoteから
代表の広沢は、BtoBでは購入の前に、サービスと自分の課題がつながる瞬間が要ると書いています。機能の説明はその土台で、「資料の閲覧状況を可視化できます」だけでは、できることを理解したところで止まってしまう。「商談後に送った資料が読まれているか分からない」という課題と並んだとき、読み手はフォローの仕方を変えられるかもしれないと気づきます。あわせて、顧客の課題から考えるときも、最初に出てくる課題で止めずに「なぜ」を重ねて掘る、という整理も書いています。掘らずに止めると、どの会社も同じことを言うコンテンツになるからです。