
楽天の順位も気になる。広告費も見直したい。商品ページも直したいところがある。クーポンもそろそろ考えないと——。EC運用は、やろうと思えばやることが無限に出てくる仕事です。時間が限られている中で「今週、結局何から手をつければいいのか」が分からなくなってしまう。そんな声を、私たちはこれまで本当にたくさん聞いてきました。
この記事では、EC運用で優先順位が決められなくなる理由と、それを機械的に決めるという発想、そして実際にどう動くのかについて整理していきます。
EC担当者が見るべき指標は、売上、アクセス数、転換率、客単価、広告費、在庫、レビュー、順位——挙げていくときりがありません。しかも楽天・Yahoo!・Amazon・自社サイトと複数モールに出店していれば、その数だけ確認箇所が増えます。EC担当者が孤独になりやすい理由の背景にも、この「見るべきものが多すぎる」という構造があると感じています。
やることが多いこと自体は、悪いことではありません。問題は、その中から「今、一番効くもの」を選び出す作業が、実は一番難しいという点です。専任の担当者がいるお店でも、この優先順位づけに毎週かなりの時間を使っているというお話をよく伺います。兼任・一人体制のお店であれば、その負担はさらに重くのしかかっていると思います。
やることリストを作ること自体は難しくありません。難しいのは、リストの中の項目に優先順位をつけて、上から順に手をつけていく仕組みを維持することです。多くのお店では、リストは作ったものの、結局上から順に進まず、目についたものから手をつけてしまう——という状態になりがちだと感じています。
楽天の管理画面、Yahoo!の管理画面、Amazonセラーセントラル、自社サイトのアクセス解析——それぞれ別の画面、別の指標です。横並びで比較する作業自体に時間がかかり、比較が終わる頃には「結局何が一番重要なのか」を考える余力が残っていない、ということがよく起こります。
仮にデータを横に並べられたとしても、「どれが一番効果が大きいか」を判断する基準がなければ、結局は勘や気分で決めることになってしまいます。広告費を削るべきか、クーポンを出すべきか、商品ページを直すべきか——それぞれの見込み効果を金額換算して比較する習慣がないお店がほとんどだと思います。
「今日中に返信しないといけないお問い合わせ」と「今月の売上を左右する広告設定の見直し」は、緊急度でいえば前者が高く見えます。ただ、重要度でいえば後者が高いことも多いんです。目の前の緊急なことに追われて、重要だけれど締切のない作業が後回しになり続ける——これもよくあるパターンだと思います。
この3つの理由は、それぞれ独立しているようで、実は連鎖しています。データが分散しているから比較する基準が作りにくく、基準がないから緊急度の高いものに流されやすくなる。どこか一箇所だけを直しても、根本的な解決にはなりにくいというのが、これまで見てきた実感です。
さらに厄介なのは、この状態が続いても、すぐには数字に表れにくいということです。優先順位づけを誤っても、翌日いきなり売上が落ちるわけではありません。効果の大きい施策を後回しにし続けた結果が、数ヶ月単位でじわじわと機会損失として積み重なっていく——この「気づきにくさ」が、優先順位づけの問題を放置しやすくしている一因だと感じています。
優先順位が決められないままだと、結局「気になったところから手をつける」という運用になりがちです。これ自体が間違っているわけではありませんが、本当に効果が大きい打ち手が後回しになり続けるリスクがあります。売れているEC店舗が絶対やらないことを見ていただくと分かりますが、成果を出しているお店ほど、実は「何をやるか」より「何を今やらないか」の判断が明確だったりします。
季節性の強い施策や、期限のあるモールイベントへの対応が後手に回ると、そのタイミングでしか得られなかった機会を逃してしまうこともあります。優先順位づけは、地味に見えて売上への影響が大きい作業だと私たちは考えています。
具体的な場面で考えてみます。例えば「今週終わるクーポンが1件ある」「アクセス数と売上の連動が強いモールがある」「ライバル店の動きが気になる」という3つが同時に発生したとき、優先順位を決める基準がないと、たいてい一番目についたものから手をつけることになります。それが偶然一番重要なものであればいいのですが、多くの場合はそうなりません。
| 状況 | 基準がない場合の判断 | 影響額を基準にした場合の判断 |
|---|---|---|
| 今週終わるクーポンが1件 | 後回しにされがち(緊急度が低く見える) | 失う機会の大きさで優先度が上がる |
| アクセスと売上の連動が強いモール | 気づかれないことが多い | 過去の相関データから優先度が上がる |
| ライバル店の値下げ | 目につきやすく最優先になりがち | 自店への影響額を見てから判断 |
こうして並べてみると、「目につきやすさ」と「実際の影響の大きさ」は必ずしも一致しないことが分かります。優先順位づけの精度を上げるには、目につく順ではなく、影響額の大きい順に並べ替える視点が必要になってきます。
こうした課題を整理していくと、「人が勘で優先順位を決める」のではなく、「データから機械的に優先順位を割り出す」という発想にたどり着きました。売上への影響額を推定し、それが大きい順に並べる——考え方自体はシンプルですが、複数モールのデータを横断して毎朝これを行うのは、人力では正直かなりの負担になります。
「機械的に決める」と聞くと、人の判断を排除するような印象を持たれるかもしれませんが、実際はそうではありません。機械的に出すのはあくまで候補と、その根拠となる数字までです。最終的にやるかやらないかを決めるのは、これまで通り人です。判断の材料を集めて並べる部分だけを自動化し、判断そのものは人に残す、という役割分担を意識しています。
5年ロードマップのような長期の優先順位づけと違い、こちらは「今週何をやるか」という短いスパンの話です。長期の方向性は経営判断として残しつつ、日々の優先順位づけだけを機械的な仕組みに任せる、という役割分担が現実的だと考えています。
私たちが開発しているEC運用アシスタント「BEE」では、毎朝データを見て、今週やるべきことを3つ、影響額の大きい順に並べて提示する仕組みにしています。「なぜこれをやるべきなのか」という理由と、その根拠になった実数値をあわせて表示するので、提示された内容をそのまま鵜呑みにするのではなく、納得した上で判断していただける形にしています。
前年同月のデータがまだ揃っていない場合は、見込み金額をあえて出さないようにしています。根拠が薄い数字を提示して、誤った判断につなげてしまうことを避けるためです。データが無ければ「出せません」とそのまま伝える設計にしています。
毎日打ち手を変えていると、効果が出る前に次の施策に移ってしまい、何が効いたのか分からなくなってしまいます。かといって月単位では変化への対応が遅くなります。私たちが「今週」という単位を選んでいるのは、効果を確認できる最短のサイクルと、対応の速さのバランスを取った結果です。曜日ごとの傾向(例えば特定の曜日にアクセスが伸びやすいお店が多いこと)も踏まえて、週単位で振り返りやすい設計にしています。
既存の分析ツールの多くは「見たい数字を自分で選んで見に行く」形になっています。BEEはこの順番を逆にして、「見るべき数字と、そこから導かれる打ち手」を先に提示する形にしました。ダッシュボードを開いて自分で異常値を探す作業自体を減らすことを狙っています。
優先順位が分かっても、それを実行し続けられなければ意味がありません。BEEでは、提示された打ち手に対して「承認する」か「今回は見送る」かを選ぶだけの操作にしています。分析画面を毎回開いて、条件を設定して、実行画面に移動して——という手間を減らすことを意識した設計です。
承認した施策がどれくらい効果につながったかは、毎週自動的に記録されます。次に似た状況が来たときの見込み精度は、この記録が積み重なるほど上がっていく仕組みにしています。「値引きは10%まで」「送料無料はやらない」といったお店ごとの決めごとも記憶し、以降の提案がそれを踏まえた内容になっていきます。勝手に学習して勝手に方針を変えることはなく、決めごとの変更はお店側の判断に委ねています。
見送った施策についても記録は残ります。「今は見送ったが、状況が変わったら再検討する」という判断も、後から振り返れる形になっているので、一度見送ったものが埋もれてしまうことを防げます。
承認した施策のうち、楽天やShopifyのクーポン発行・ポイント設定については、承認した時点でそのまま実行まで進む形にしています。押した直後であれば取り消しも可能です。一方でセールの価格変更のように取り消しが効きにくい施策は、承認を記録した上で実行画面へご案内するにとどめ、最後の実行判断は必ず人の手に委ねる設計にしています。
優先順位が決められずに悩んでいると、「他のお店はもっとうまくやっているのではないか」という不安が出てくることもあると思います。ただ、実際にご相談をいただく中で感じているのは、この悩み自体は規模の大小を問わず、ほとんどのお店に共通しているということです。専任の担当者が何人もいる会社でも、優先順位づけの難しさそのものは変わりません。
大切なのは「自分だけが遅れている」と感じて焦ることではなく、優先順位づけという作業自体を、負担の少ない仕組みに置き換えられないかを考えることだと思います。売上が落ちたときに「自社だけの問題なのか、市場全体の動きなのか」を切り分ける視点も、優先順位を正しく判断する上で欠かせません。原因が市場全体にあるなら、対処すべき優先順位はまた変わってくるからです。
焦って手当たり次第に手をつけるよりも、一度立ち止まって「今、何が一番効くのか」を確認する時間を作る方が、結果的に早く状況を改善できることが多いと感じています。優先順位づけに時間を使うことは、遠回りではなく、むしろ一番の近道になり得ると私たちは考えています。
すでに自分なりの優先順位づけができている担当者の方にとっては、「決めて出す」部分の価値はそれほど大きくないかもしれません。ただ、その場合でも、複数モールのデータを横断して自動で集計する部分や、承認した施策の効果測定を自動で記録する部分は、確認作業の手間を減らす道具として使っていただけると考えています。
特に、複数モールを横断して数字を比較する作業は、経験のある担当者にとっても地味に時間がかかる作業だと思います。判断そのものは自分で行い、比較のための集計作業だけを任せる、という使い方も現実的な選択肢の一つです。判断の主体をどちらに置くかは、お店の状況によって変わって良いと考えています。
見送っていただいて構いません。「今回は見送る」を選ぶと、その判断も記録されます。決めごと(例えば「値引きは10%まで」といったルール)を伝えておくと、以降の提案がそれを踏まえた内容になっていきます。
使えます。楽天のみ、自社サイトのみといった単一モールでの運用にも対応していますし、後からモールを追加していくことも可能です。
モールとAPIで接続できる場合は、毎日決まった時間に自動で取得する形にしています。API連携が難しいモールについても、CSVやZIP、管理画面のスクリーンショットをそのまま読み込ませる方法を用意しているので、手作業でのデータ入力を最小限にとどめられます。
EC運用における優先順位づけは、本来もっと機械的に処理できる作業だと私たちは考えています。「何からやればいいか」を毎回一から考えるのではなく、機械的に出てきた候補を確認し、判断するという形に変えるだけで、担当者の負担はかなり軽くなるはずです。
優先順位づけそのものに時間を使うのではなく、優先順位が高いと分かった施策の中身を考える時間に使う——この配分を変えるだけで、同じ時間でも成果につながる作業の比率は大きく変わってくると私たちは感じています。データを見る時間を減らして、判断する時間を増やす。それが、私たちがBEEを通じて実現したいことです。
「今週何をやればいいか、いつも悩んでしまう」という方は、一度BEEのデモ画面で実際の提示のされ方を見ていただくのがおすすめです。理由と根拠が添えられた状態で提示される感覚は、実際の画面を見ていただいた方が伝わりやすいと思います。
楽天・Yahoo!・Amazon・Shopifyのデータから、今週やることを根拠つきで。
承認するだけで販促まで動く、EC運用アシスタント「BEE」です。