「ECサイト、そろそろ改善したいよね」

この言葉が会議に登場してから、半年。場合によっては1年。
改善案は出ている。予算の話もした。ベンダーにも相談した。

それでも、なぜか進まない。

こうしたご相談を受けることがあります。

話を聞いてみると、誰かがサボっているわけではありません。むしろ逆です。皆さん、それぞれの立場でかなり真剣に考えています。

真剣だからこそ、

「まずは集客を改善すべきだ」
「いや、購入単価を上げるほうが先だ」
「その前に問い合わせを減らしたい」
「そもそも今のシステムでは対応が難しい」

と、正しい意見が次々に出てくる。

意見が出ない会議も困りますが、正しい意見しか出ない会議も、意外と前に進みません。

EC改善が止まっている案件を見ていると、技術や予算の話に入る前に、部門ごとの目的が揃っていないことがあります。

私は現場に入ると、まずこのズレを確認します。

同じECサイトを見ていても、見ているものは違う

ECサイトはひとつです。

でも、マーケティング、営業、カスタマーサポート、システム。それぞれの部門が見ているECサイトは、ほとんど別物です。

ヒアリングをしていると、その違いがよく分かります。

マーケティング担当者は、流入数やコンバージョン率、回遊率、リピート率の話をします。

「集客はできているのに、購入まで進んでもらえない」
「もっと関連商品を見てもらいたい」

そう考えれば、レコメンド機能や会員施策を強化したくなるのは自然です。

営業部門は、売上だけでなく、商談や受注にかかる時間を見ています。

「購入単価を上げたい」
「法人のお客様から来る見積もり依頼に、もっと早く返したい」
「営業担当者を介さなくても、継続注文できる状態にしたい」

カスタマーサポートは、数字の裏側でお客様がどこにつまずいているのかを知っています。

例えば、

「決済方法が分からないという問い合わせが多い」
「配送日の変更について、毎日同じ説明をしている」

といった声です。

管理画面だけでは見えにくい、小さな不便や不安を一番近くで見ているのは、サポート部門だったりします。

そしてシステム担当者は、その裏側で現実を見ています。

「機能としては分かるけれど、今の仕組みでは簡単には追加できない」
「ここを変えると、在庫連携にも影響が出る」

やりたいことと、できること。その間にある距離を見ています。

全員が同じECサイトの話をしているのに、会話の単位が違うんです。

マーケティングは数字で話す。
営業は売上と業務で話す。
サポートはお客様の声で話す。
システムは構造と影響範囲で話す。

どの意見も、間違っていません。

だから難しいんです。

会議が進まないのは、意見が多いからではない

EC改善の会議では、いろいろな要望が出ます。

レコメンドを入れたい。
検索機能を改善したい。
問い合わせを減らしたい。
基幹システムと連携したい。
会員データを活用したい。

一つひとつを見れば、どれも必要そうに見えます。

ただ、ここでよく起きるのが、「何をするか」から話し始めてしまうことです。

レコメンド機能を導入するか。
どのツールが良いか。
いくらかかるか。
いつ実装できるか。

でも、その前に決めておかなければならないことがあります。

この改善で、誰のどんな困りごとを減らしたいのか。

ここが揃っていないまま具体策の話に入ると、会議の中で同じ言葉を使いながら、全員が別の完成形を想像することになります。

例えば、「レコメンドを強化したい」という話。

マーケティング担当者は、回遊率を上げたい。
営業担当者は、セット購入で単価を上げたい。
システム担当者は、運用が複雑にならない形にしたい。

全員がレコメンドの話をしています。
でも、目指しているものは少しずつ違います。

そのまま進めると、途中で「思っていたものと違う」が出てきます。

仕様が増える。
調整が増える。
いったん持ち帰る。

気づけば、次の会議でも同じスライドが映っています。

改善案が多い会社ほど、改善が進むとは限りません。

全部やろうとすると、だいたい何も始まらないからです。

お客様の不便は、部門をまたいで起きている

部門ごとに役割が分かれているのは、会社としては自然なことです。

ただ、お客様は部門ごとにECサイトを使っているわけではありません。

商品を探して、在庫を確認して、決済して、配送を待つ。問題があれば問い合わせる。

お客様にとっては、すべてがひと続きの体験です。

例えば、在庫表示が分かりにくいという問題があったとします。

表面上は、サイト上の表示改善に見えるかもしれません。

でも実際には、店舗在庫との連携、倉庫側の更新頻度、受注後の引き当て、問い合わせ対応まで関係していることがあります。

画面だけを直しても、裏側の運用が変わっていなければ、別の場所にひずみが残ることがあります。

EC改善が難しいのは、システムが複雑だからだけではありません。

お客様の体験は横につながっているのに、会社の組織は縦に分かれている。

この構造がある以上、ひとつの部門だけで改善を完結させるのは、なかなか難しいんです。

だから私は、画面の話だけを聞いていても、改善の全体像は見えないと思っています。

その画面の裏で、誰が何をしているのか。
その変更によって、どの部門の業務が増えるのか。
逆に、どの負担が減るのか。

そこまで見て、初めて改善の話になります。

最初に揃えるべきなのは、機能ではなく困りごと

では、最初に何をすればいいのか。

私なら、機能一覧を作る前に、各部門の「困っていること」を並べます。

ここで大事なのは、「やりたいこと」ではなく「困っていること」を出すことです。

似ているようですが、かなり違います。

「検索機能を改善したい」は要望です。

「商品名を正確に入力しないと商品が見つからず、お客様が商品にたどり着けていない」は困りごとです。

アクセス解析まで確認できているなら、

「商品名を正確に入力しないと商品が見つからず、検索結果ページの離脱率が高くなっている」

と、さらに具体的にできます。

「チャットボットを入れたい」は要望です。

「配送や返品に関する同じ問い合わせが多く、スタッフが個別対応に追われている」は困りごとです。

要望から始めると、すぐに機能比較や製品選定の話になります。

困りごとから始めると、本当にその機能が必要なのかを考えられます。

もしかすると、システム開発をしなくても、商品情報の見せ方や業務フローを変えるだけで解決できるかもしれません。

逆に、現場の工夫だけでは限界があり、システム側から変えなければならないこともあります。

ここでのポイントは、最初から答えを決めないことです。

新しい機能を入れることが改善なのではありません。
困りごとが減ることが改善です。

この順番を逆にしないことが大切です。

全員の希望をかなえることが、合意形成ではない

部門横断で話すとき、「全員が納得する案をつくらなければ」と考えてしまうことがあります。

ただ、すべての要望を一度に盛り込むと、プロジェクトは大きくなります。

費用も期間も膨らみます。
仕様も複雑になります。
そして、また進まなくなります。

合意形成は、全員の希望を平等にかなえることではありません。

今回の改善では、何を優先するのか。
今回は何をやらないのか。

そこまで決めることだと思います。

例えば、

「今回は新規集客よりも、購入途中の離脱改善を優先する」
「問い合わせ削減よりも、まず法人注文の業務負荷を減らす」
「会員施策は次の段階に回し、先に在庫連携を安定させる」

こうして順番が決まれば、それぞれの部門が完全に満足していなくても、プロジェクトとしては動き出せます。

「全員が納得するまで決めない」は、丁寧に見えて、実質的には決めない選択になりがちです。

優先順位をつけるというのは、何かを捨てることではありません。

実行できる単位に分けることです。

EC改善では、部門ごとの正解をひとつにする必要はありません。

違う正解を持ったまま、今回はどれを優先するのかを決めればいいんです。

技術の話は、目的が揃ってからでいい

EC改善の話になると、どうしても新しいサービスや機能に目が向きます。

AI接客やパーソナライズ、データ連携など、新しい選択肢の相談を受けることも増えました。

もちろん、技術は大切です。

ただ、目的が揃っていない状態で新しい技術を入れても、社内のズレまで自動で解消してくれるわけではありません。

便利な道具を持ったまま、別々の方向へ走る人が増えるだけになることもあります。

私が技術選定の前に確認したいのは、

誰の課題を解決するのか。
何を改善できれば成功なのか。
どこまでを今回の範囲とするのか。

この3つです。

ここが揃っていれば、技術選定も判断しやすくなります。

高機能だから選ぶのではなく、今回の課題に必要だから選ぶ。

逆に言えば、どれだけ高機能でも、今回の課題に必要なければ選ばない。

この判断ができる状態をつくることが、改善の最初の仕事だと思っています。

正解の違いは、改善の邪魔ではない

ECサイトの改善が進まないとき、つい「もっと良い提案が必要なのではないか」「新しいツールを入れたほうがいいのではないか」と考えてしまいます。

でも実際には、その前で止まっていることが少なくありません。

マーケティングには、マーケティングの正解があります。
営業には、営業の正解があります。
カスタマーサポートにも、システムにも、それぞれの正解があります。

問題は、正解が違うことではありません。

どの課題から、どの順番で解決するのかが決まっていないことです。

改善を始める前に、まず各部門が見ている困りごとを並べてみる。

そして、今回のプロジェクトで目指すゴールをひとつに絞る。

派手な施策ではありません。
会議映えもしないかもしれません。

でも、こうした認識合わせができているプロジェクトほど、その後の設計や開発で判断がぶれにくくなります。

正解が違うことは、プロジェクトの弱点ではありません。

それぞれの部門が見つけた課題を持ち寄れることは、むしろ改善の材料です。

EC改善は、機能を増やすところから始まるのではありません。

社内で見えている景色を、一度同じテーブルに載せる。

そこから、ようやく前に進み始めます。

※関連リンク：「GMOクラウドEC」公式サイト