FutureShop × スマレジ連携の選択肢 — 在庫同期・受注連携・店舗在庫表示、どれが必要か
「FutureShop とスマレジを連携したい」という相談を掘り下げると、目的は三者三様です。全部をやろうとすると重くなり、必要なものだけ選べば軽く済みます。まず、何を連携したいのかをはっきりさせましょう。
3つの「連携」を分けて考える
| ① 在庫同期 | ② 受注連携 | ③ 店舗在庫表示 | |
|---|---|---|---|
| 目的 | EC と店舗の在庫を一体で管理し、欠品・二重販売を防ぐ | EC の注文を POS 側の売上・在庫に反映する | お客様が商品ページで店舗在庫を確認できるようにする |
| データの流れ | スマレジ ⇄ FutureShop(双方向または片方向で在庫数を書き換え) | FutureShop → スマレジ(注文データの取り込み) | スマレジ → 商品ページ(読み取りのみ) |
| POS 運用への影響 | 大きい(引当・按分・返品時の扱いを設計) | 中(売上計上や在庫引き落としの二重計上に注意) | なし |
| 導入の重さ | 重い | 中 | 軽い(表示ルールと店舗の選択が中心) |
| 典型的な動機 | EC と店舗で同じ在庫を売り切りたい | 売上・在庫の集計を POS に一本化したい | 来店誘導、在庫問い合わせの削減、EC 在庫切れ時の売り逃し防止 |
① 在庫同期が必要なケース
EC 専用の倉庫在庫を持たず、店舗の在庫をそのまま EC でも売りたいショップは在庫同期が必要です。ただし「どの店舗の在庫を EC に出すか」「店頭で売れた瞬間に EC の在庫をどう減らすか」「EC 注文を店舗のどこから出荷するか」など、業務ルールの設計が連携そのものより大きな仕事になります。ここを飛ばして仕組みだけ入れると、二重販売やお客様への欠品連絡が増えます。
② 受注連携が必要なケース
売上分析やポイント・顧客管理を POS 側に集約したいショップは、EC の注文をスマレジに取り込む受注連携を検討します。EC 側でも在庫を引き落としている場合、POS 側でもう一度引き落とすと二重になるため、どちらを在庫の「正」とするかを先に決めておきます。
③ 店舗在庫表示で十分なケース
EC 在庫は EC 用の倉庫で管理していて、店舗在庫と分けている。お客様からの「店舗に在庫ありますか?」が多い。来店やお取り置きが売上の柱になっている——このタイプのショップは、在庫同期をしなくても店舗在庫の表示だけで目的の大半が達成できます。スマレジの在庫を読み取って商品ページに表示するだけなので、POS の運用も EC の在庫管理も変えずに導入でき、失敗したときのダメージも小さいです。
判断のフローチャート(文章版)
- EC と店舗で同じ在庫を売っているか? → はい:在庫同期を検討(業務ルール設計から)。いいえ:次へ。
- EC の注文をPOS の売上・顧客データに集約したいか? → はい:受注連携を検討。いいえ:次へ。
- お客様が店舗の在庫を知りたがっているか(問い合わせが来る、来店が多い)? → はい:店舗在庫表示。まずここから始めるのが最も軽い。
①や②が将来必要になっても、③を先に入れておく価値はあります。表示専用の連携は他の連携と競合せず、お客様に見える効果がいちばん早く出ます。
店舗在庫表示を入れるときの実務メモ
- スマレジは API が利用できるプランでの契約が必要。契約 ID とアクセストークンを発行し、連携元の IP アドレスを許可リストに登録する。
- FutureShop 側は futureshop API のクライアント(商品情報の参照権限)とショップキーを用意する。こちらも IP 許可の設定がある。
- スマレジの商品に FutureShop の商品番号(SKU)を持たせて紐付ける(予備項目を使うのが一般的)。
- 表示する店舗と、△(残りわずか)のしきい値、お取り置きの案内文を決める。
- 商品詳細ページのテンプレートにスクリプトタグとボタンを置く。
ShopStock はこの③を、スマレジ+FutureShop 向けにサービス化したものです。他のカートへの対応も順次進めています。
関連:スマレジの店舗在庫をECサイトに表示する方法 / OMO時代の「店舗在庫の見える化」
スマレジの店舗在庫を、今日からECの商品ページに
ShopStock は表示専用の店舗在庫連携です。月額 ¥11,000(税込)、初期設定費はキャンペーン中 ¥0。オンラインで申し込み、管理画面の手順に沿って設定、商品ページにタグ1行で公開できます。
今すぐ始める →