食品ECのカート選び｜機能数ではなく、どこまで使いこなせるかで選ぶ

ECサイトを立ち上げるとき、最初の大きな選択の一つがECカートです。各社の比較表を見ると、「クーポン・ポイント対応」「レビュー機能」「Google広告連携」「SNS連携」など、多くの機能に○が並んでいます。そのため、一見すると「どのカートを選んでも、それほど大きな違いはないのでは」と感じることがあります。しかし、実際に複数のECカートを使って運営してみると、同じ「○」でも、その中身にはかなり大きな差があることが分かります。

もちろん、ECカートを選ぶ際には、デザインやテンプレート、商品管理、更新のしやすさ、決済方法、SEO、検索機能、セキュリティ、サポート体制、料金など、確認すべきことはまだまだあります。すべてを取り上げると、ECカート選定の大百科になってしまいます。そこでこの記事では、ECカートの選び方をすべて網羅するのではなく、私たちが実際に複数のカートを使ってECサイトを運営・支援してきた中で感じた、「比較表では見えにくいのに、使い始めると大きな差になるポイント」を中心に紹介します。

例えば、非常に分かりやすいのがクーポン機能です。多くのECカートの比較表には「クーポン機能あり」と書かれていますが、実際に使ってみると、その自由度にはかなり違いがあります。例えばクーポン一つでも、次のような違いがあります。

• 会員だけに使えるのか、非会員にも使えるのか
• 1人1回なのか、何度でも使えるのか
• 有効期間を細かく設定できるのか
• ○円引き、○％引きの両方に対応しているのか
• 特定の商品だけを対象にできるのか
• 最低購入金額を設定できるのか
• 複数のクーポンを併用できるのか
• クーポンコードを入力する方式だけなのか
• 顧客にクーポンを保有させられるのか
• マイページで保有クーポンを確認できるのか

比較表では、これらがすべて「クーポン○」の一文字で表現されてしまうことがあります。ポイント機能も同じです。通常の還元率だけなのか、商品ごとに倍率を変えられるのか、有効期限を設定できるのか、キャンペーンとして特別にポイントを付与できるのかによって、実際にできる販促施策は大きく変わります。レビュー機能なども含め、大切なのは機能が「あるか」ではなく、その機能をどこまで使えるのかという視点です。

私たちが選定で確認したいのは、「クーポンを発行できるか」の次です。例えば、初回購入者向けのクーポンを一部の商品だけに使い、セール商品は対象外にする。値引き後に送料無料の基準額を下回ったら、送料をどう扱うか。こうした条件を組み合わせたときに、意図した注文金額になるかを見ます。

設定自体はできても、対象商品を毎回手動で選ぶ必要があるのか、条件でまとめて管理できるのかによって、キャンペーンを続ける負担は変わります。「一度実現できる」ことと、「担当者が替わっても間違えずに続けられる」ことまで分けて見ると、比較表の○では見えない差がはっきりします。

クーポンを単純に値引きのためだけに使うのであれば、最低限の機能でも十分かもしれません。しかし、ECが成長してくると「誰にクーポンを配るのか」という考え方が重要になってきます。例えば、次のような条件で顧客を分けられるかどうかです。

• 過去に特定の商品を購入した人
• 最近一定期間購入していない人
• 購入回数が3回以上の人
• 特定地域に住んでいる人
• 新規会員
• リピーター
• 特定の会員ランクの人

こうした条件で顧客を分け、それぞれに違う特典を届けられると、クーポンは単なる値引きではなくCRMの一部になります。ステップメールなどと組み合わせれば、初回購入後のお客様へ次の商品を案内したり、しばらく購入していないお客様へ再来店を促したりすることもできます。

食品なら、前年に旬の商品を購入した人へ、今年の予約開始を案内する使い方も考えられます。ただし、贈り主と配送先を混同せずに抽出できるか、キャンセルした注文を除外できるか、案内を希望する人だけを対象にできるかも確認が必要です。抽出条件を保存できず、その都度CSVを加工しなければならないのであれば、その作業もCRMを実施するためのコストになります。

ECカートは商品を注文してもらうためだけのシステムではありません。顧客一人ひとりに合わせた接客を行うための仕組みでもあります。そのため、カートが持っている顧客管理や販促機能の深さによって、将来的にできるCRM施策の幅にも差が出てきます。

食品ECでは、さらに複雑になります。例えばギフト商品であれば、のしを付けるかどうかだけでなく、包装、ラッピング、名入れ、複数配送など、お客様ごとにさまざまな希望があります。さらに食品の場合には、次のような条件も関係してきます。

• 常温・冷蔵・冷凍といった温度帯
• 異なる温度帯の商品を同梱できるか
• 同梱した場合にどの温度帯で発送するか
• 温度帯が分かれた場合の送料計算
• 送料無料商品と送料別商品の組み合わせ
• 複数のお届け先
• 複数の出荷拠点
• メーカーからの直送
• ドロップシッピング
• 商品ごとの同梱可否

例えば、冷凍商品と常温商品を同時に注文した場合を考えてみます。冷凍便にまとめるのか、2個口に分けるのか、送料はいくらになるのか、そこに送料無料商品が含まれていたらどうするのか。食品ECの現場では、こうした判断が日常的に発生します。カート側で柔軟に設定できれば自動的に処理できますが、対応できなければ人が処理することになります。

ここでいう同梱可否は、システムの設定だけで決めるものではありません。品質を保てる温度帯や梱包条件を先に決め、そのルールをカートで表現できるかを確認します。同じ温度帯でも、出荷元が違えば同じ箱では送れません。逆に、同じ倉庫から出せても、商品の性質によっては別梱包が必要です。

送料無料条件も、「注文総額が基準を超えたら無料」だけでは足りない場合があります。配送先ごとなのか、出荷拠点ごとなのか、温度帯ごとなのか。送料無料商品に別の商品を足したとき、その商品まで無料にするのか。地域の追加送料やクール料金をどう扱うのか。送料無料にする範囲と、実際に発生する配送原価を対応させて確認することが、売れた後に利益を残すためにも必要です。

ギフトでは、のしや名入れを注文単位ではなく商品・配送先単位で指定できるか、その内容が納品書や出荷指示へ正しく引き継がれるかを見ます。購入画面では選べても、倉庫へ渡すデータに入らなければ、受注担当が転記することになります。贈答先へ金額入りの書類を入れない、といった指示も含めて、注文から梱包まで通して確認したいところです。

メーカー直送やドロップシッピングでは、注文を受けた後に出荷元へどの情報を渡し、欠品連絡や出荷実績、追跡番号をどう戻すかまでが一つの運用です。出荷元が増えたとき、全社へ同じ形式で送れるのか、拠点ごとに加工が必要なのか。お客様への発送案内が分割出荷に対応できるかも、後から効いてくる制約です。

注文後にお客様へメールを送り、送料を変更し、注文内容を修正し、出荷拠点を振り分け、倉庫へ個別の指示を出す。1件だけなら対応できても、注文数が増えるほど負担は大きくなります。売上が増えるほど手作業も増える仕組みでは、ECの成長そのものが業務負担になってしまいます。だから食品ECでは、表側の商品ページだけではなく、実際の注文条件をカート内でどこまで処理できるかまで確認しておくことが大切です。

ECカートを検討するときは、お客様が見る画面に注目しがちです。しかし運営を始めれば、スタッフは毎日のように管理画面を使います。注文確認、決済確認、メール送信、出荷処理、注文内容の変更、キャンセルなど、日々の業務をどのように行えるかも重要です。

機能が多ければ必ず使いやすいとも限りません。長年アップデートを繰り返して機能が増えた結果、設定画面が複雑になっていたり、必要な設定がどこにあるのか分かりにくくなっていたりする場合もあります。また、店舗によって受注から発送までの流れは違います。どこまで自動化できるのか、自社の業務に合わせて設定できるのかによって、日々の作業時間は大きく変わります。

ここでも見るべきなのは、単なる機能数ではありません。売上が増えたときにも、少ない負担で運営を続けられるかという視点が必要です。

デモを見る際には、通常注文だけでなく、複数温度帯の注文、複数配送先のギフト、クーポンと送料無料の併用、直送品を含む注文を用意して、受注から出荷まで操作してみます。さらに、一部商品のキャンセルや配送先変更が入った場合に、送料・値引き・出荷指示をどこまで安全に修正できるかも見ます。例外処理に必要な画面と手作業が分かれば、機能一覧よりも実際の運営体制を想像しやすくなります。

長くECサイトを運営すると、カートの中には大量のデータが蓄積されていきます。商品データ、顧客データ、注文履歴、購入商品、購入回数、ポイント、レビューなどは、単なるシステム内の情報ではありません。これらは、会社が時間をかけて積み上げてきた重要なマーケティング資産です。

例えば顧客データと注文履歴を組み合わせれば、リピーターの購入傾向を調べたり、特定の商品を買った人へ次の商品を提案したりできます。商品ごとの売上推移や顧客属性を分析し、品揃えや広告施策へ生かすこともできます。そこで意外に重要になるのが、CSVなどでどこまでデータを取り出せるかです。

管理画面に欲しい集計機能がなくても、必要なデータをCSVで取り出せれば、ExcelやGoogleスプレッドシート、BIツール、自社で作った補助ツールなどを使って分析できます。APIが用意されていれば、外部サービスとの連携も可能になります。ただし、API連携や外部サービスを増やせば費用や管理負担も増えるため、必ずしも「連携先が多いほど良い」ということではありません。

重要なのは、標準機能で足りなくなったときに、次の選択肢を持てるかということです。これは将来カートを乗り換える際にも関係します。自社で蓄積してきた顧客情報や注文履歴などを十分に取り出せなければ、別のカートへ移行したくても身動きが取りにくくなることがあります。自社のECで蓄積したデータを、自社の資産としてどこまで自由に活用できるのか。この視点は、長期的なカート選びでは非常に重要だと考えています。

現在のBtoC・小売向けGoogle広告では、商品情報をGoogle Merchant Centerへ連携し、その情報をもとにGoogleが商品を理解し、ユーザーに合わせて広告を最適化していく仕組みが重要になっています。特にショッピング広告やP-MAXでは、商品名、商品説明、画像、価格、在庫状況などの商品データが、Googleが商品を理解して配信先を判断するための重要な材料になります。

そのため重要なのは、「Google広告に連携できます」という機能があることだけではありません。商品の実態に合った、正確で十分な商品情報をGoogleへ渡せるかを見る必要があります。例えば、カートによってGoogleへ出力できる情報には次のような違いがあります。

• 商品ID
• 商品名
• 商品説明
• 商品画像
• 価格
• セール価格
• 在庫状況
• 商品を識別するための各種情報

カートの商品情報をそのまま自動出力するものもあれば、Googleへ送るための情報を別途設定できるものもあります。つまり、比較表ではどちらも「Google広告連携○」でも、Googleへ渡せる商品情報の質や自由度には差があります。

商品フィードの内容が十分でなければ、一度カートからデータを取り出し、自社で最適化した商品フィードを作ってMerchant Centerへ連携する方法もあります。ただし、その場合は商品の追加、価格、在庫などを継続的に同期する仕組みも必要になります。

広告との連携では、購入完了だけでなく、購入に至るまでのデータを取得できるかも重要です。例えば、次のような行動や購入情報をどこまで計測できるかです。

• 商品を閲覧した
• カートへ追加した
• 購入手続きを開始した
• どの商品を購入した
• 購入金額はいくらだった

さらに、ユーザー提供データなど、Google広告の計測精度を高めるための仕組みに対応できるかも、カートによって違います。こうしたデータを標準で取得できるのか、タグなどを追加すれば対応できるのか、それともシステム上難しいのか。ここにも差があります。

ECを始めたばかりであれば「簡単にGoogle広告と連携できる」ことは大きなメリットです。しかし広告予算を増やして本格的に運用していくのであれば、簡単につながることと、十分なデータを使って運用できることは別だと考えておいた方がよいでしょう。

ECカートを比較するとき、どうしても月額料金に目が行きます。無料や低価格から始められるサービスもあれば、最初から数万円以上の基本料金がかかるサービスもあります。スタート時だけを見れば、安い方が魅力的に感じるのは当然です。しかし実際の料金体系には、次のようなものがあります。

• 基本料金
• 売上に応じた従量課金
• 決済手数料
• オプション機能
• 外部アプリ
• 外部サービス
• カスタマイズ費用

最初は低価格でも、売上規模が大きくなるにつれて従量課金が増え、結果として費用が大きくなることもあります。一方で基本料金が高くても、必要な機能が最初から含まれていたり、売上が増えた後の追加費用が比較的小さかったりする場合もあります。

さらに、忘れてはいけないのが人件費です。例えば、ある機能を使うことで、これまで毎月30時間かかっていた作業が3時間で終わるようになるのであれば、月額料金が多少高くても十分に価値があるかもしれません。反対に、月額料金が安くても、システムでできない処理を毎日スタッフが手作業で行わなければならないのであれば、人件費を含めた運営コストは高くなります。

カート料金ではなく、ECを運営するための総コストで比較する。特に売上が増えた後ほど、この考え方が重要になります。

クーポンやレビューなどの販促機能は分かりやすく、カートを比較するときにも目立ちます。一方で、長く運営すると重要になってくるのが、もっと地味な基本性能です。

• ページの表示速度
• メール環境
• セキュリティ対策
• 担当者ごとの権限管理
• サポート体制
• 継続的なシステムアップデート
• 安定して運営できること

特にページ表示速度は、すべての集客施策の入り口に関わります。広告からアクセスしても、検索結果から訪問しても、メルマガから来ても、ページの表示が遅ければ購入前に離脱する可能性があります。画像形式への対応、スマートフォン向け画像の最適化、CDN、サーバー、ページ内で読み込むプログラムなど、速度に影響する要素はさまざまです。細かな技術までEC担当者が把握する必要はありませんが、快適にページが表示されることもECカートの重要な基本性能と考えた方がよいでしょう。

同じように、困ったときに相談できるサポート体制があるか、複数のスタッフが安全に管理画面を利用できるか、新しい技術や外部サービスの変化に合わせて継続的にカート自体がアップデートされているかも、長く使ううえでは重要です。

ECを立ち上げたばかりの段階では、CRM、高度なクーポン、複数拠点配送、API連携などは必要ないかもしれません。そのため、機能が豊富なカートを見ると「ここまで必要ない」「オーバースペックだ」と感じることもあります。もちろん、小規模なECであれば、シンプルで低価格なカートの方が適しているケースもあります。高いカートだから良い、安いカートだから悪いという話ではありません。

ただ、ECが成長すると状況が変わります。リピーターを増やしたい。広告を本格的に使いたい。受注業務を自動化したい。出荷拠点を増やしたい。顧客データを分析したい。そうしたときに、必要な機能がカート側に用意されていなければ、外部サービスを追加したり、人が作業したり、場合によってはカートそのものを乗り換えたりする必要が出てきます。

ECカートは、一度使い始めると簡単に交換できるものではありません。商品、顧客、注文履歴、決済、デザイン、SEO、広告計測など、さまざまなものがカートを中心に積み上がっていくためです。そのため選定するときには、現在の規模だけでなく、2〜3年後にどんなECを運営したいかまで考えておくことをおすすめします。

ECカートを選ぶとき、最初にサービスの比較表を見る人は多いと思います。しかし、本来はその前に「自分たちが何をしたいのか」を整理しておくことが重要です。例えば、次のような条件をあらかじめ整理しておきます。

• どのような商品を販売するのか
• ギフト需要はあるのか
• 常温・冷蔵・冷凍を扱うのか
• 複数の出荷拠点があるのか
• リピーターをどのように育てたいのか
• Google広告などを本格的に利用するのか
• 誰が受注処理をするのか
• どの程度まで業務を自動化したいのか
• 数年後にどのくらいの事業規模を目指すのか

そのうえで、「このカートにはどんな機能がありますか？」ではなく、「私たちがやりたいことを、このカートでどこまで実現できますか？」と考えると、カートの見方が変わってきます。

相談時には、「標準機能」「有料オプションや外部連携」「個別開発」「手作業が残る部分」を、やりたい運用ごとに書き分けてもらうと判断しやすくなります。できない処理が一つあるだけで即不採用にする必要はありません。発生頻度と処理時間、ミスが起きたときの影響を見て、自社で引き受けられる負担かを判断します。

ただ、これから初めてECを始める会社にとっては、「将来どんな機能が必要になるのか」「何をカート会社へ確認すればよいのか」自体が分からないことも多いと思います。カート会社は当然ながら、自社サービスの専門家です。一方で、複数のカートを実際に使った運営側の経験がある第三者を交えて選定すると、それぞれの特徴や、将来発生しそうな課題を別の視点から確認できます。発注する側にとっても、カート会社にとっても、導入後に「思っていたものと違った」という状況を減らすことにつながります。

ECカートの比較表を見ると、多くの機能に○が付き、どのサービスもよく似ているように見えます。しかし実際には、同じクーポン機能でもできることは違います。食品ECなら温度帯や送料、複数配送などへの対応力にも差があり、受注後の業務、データの取り出しやすさ、Google広告との連携、料金体系、表示速度など、運営を始めてから見えてくる違いもあります。

だからこそ、ECカートを選ぶときには「機能がいくつ付いているか」だけで判断するのではなく、その機能をどこまで使いこなせるのか、自社の運営にどこまで合わせられるのかを見ることが大切です。今は必要のない機能でも、ECが成長すれば必要になることがあります。反対に、高機能なカートでも自社で使いこなせなければ、その価値を十分に生かすことはできません。

ECカートの本当の性能は、導入したときよりも、ECが成長したときに見えてきます。ヨーシーでは、特定のECカートを販売する立場ではなく、食品ECを実際に運営してきた経験と、複数のECカートを使った支援経験をもとに、事業規模や商品、運営体制、今後の成長まで考えたECサイト・カート選定を支援しています。