Shopify POS / 新機能

Cart sharing on Shopify POS
カートを「端末に縛られないもの」にする

スタッフが作りかけたカートは自動保存され、別の端末・別のスタッフが引き継いで会計まで完了できる。売場で接客したまま作ったカートを、そのままレジに渡せる。

このページの構成
  1. そもそも何が変わるのか(30秒で理解)
  2. 仕組み図解 : フロアからレジまでの流れ
  3. この機能でできる4つのこと
  4. 従来 vs Cart sharing の比較
  5. カートビューと draft order 変換
  6. 利用条件
  7. 技術者が押さえるべき5つのポイント
  8. 業務に活かせる3つのユースケース
  9. 提案で使える1行サマリ

1そもそも何が変わるのか

今までの POS のカートは、それを作った端末の中だけにあるものだった。
Cart sharing は、カートを自動保存してチーム全体で共有できるものに変える。誰が作ったカートでも、どの端末からでも、開いて・続けて・会計まで完了できる。

従来 : カートは端末の中

売場のモバイルで組んだカートは、その端末で会計するしかない。レジに移るなら口頭で伝え直すか、打ち直すことになる。

Cart sharing : カートはチームのもの

組み立て途中でも自動保存。どの端末からでも同じカートを開いて続けられ、別のスタッフがそのまま決済まで完了できる。

2仕組み図解 : フロアからレジまでの流れ

販売スタッフ A 売場で接客 モバイル端末 商品を追加 カートを組み立て 入力するそばから 自動で保存される 保存操作は不要 複数カートを切替可 受け渡し カートビュー 顧客 A のカート 顧客 B のカート 顧客 C のカート オープン中のカート一覧 既定はログイン中スタッフで絞込 別端末で開く レジで会計を完了 支払いへ進む 販売スタッフ B が引き継ぎ 打ち直しゼロ
floor-to-register selling(フロアからレジへの販売)とは : 接客する人と会計する人を分けられる売り方のこと。
売場のスタッフが顧客の横でカートを作り、そのままレジ担当に渡して決済してもらう。カートが端末をまたげることが前提条件になる。

3この機能でできる4つのこと

自動保存
組み立てながら勝手に保存される
端末をまたぐ
どの端末からでも開ける
誰でも引き継げる
どのスタッフでも継続・会計可
1スワイプで下書き注文
カート → draft order へ変換

4従来 vs Cart sharing の比較

項目従来Cart sharing
カートの保存 端末内 作った端末で完結 自動保存 組み立て中から保存される
別端末からの継続 不可(打ち直し) 可 どの端末からでも開ける
別スタッフへの引き継ぎ 口頭・メモで伝達 可 そのまま会計まで完了できる
複数顧客の同時対応 カートの切替が前提にない 切替可 顧客別カートを行き来できる
オープン中カートの可視化 記載なし 専用ビュー 既定でログイン中スタッフに絞込
下書き注文への変換 記載なし 1スワイプ

5カートビューと draft order 変換

専用のカートビューで散らからない

チームのオープン中カートが一覧で整理される。既定のフィルタはログイン中のスタッフなので、まず自分の担当分だけが目に入る。フィルタを外せばチーム全体のカートに辿り着ける。

draft

スワイプ1回で draft order 化

その場で決まらなかったカートは、1スワイプで下書き注文(draft order)に変換できる。後日の追客や、支払いリンク送付といった既存の下書き注文フローに接続できる。

カートの保持期間、1店舗あたりのカート上限、削除の扱いについては記載なし。運用ルールを決める前にヘルプセンターの記載と実機での挙動を確認すること。

6利用条件

POS Pro であること

すべての POS Pro マーチャントが対象。POS Lite での提供有無は記載なし。

11.11

POS アプリ バージョン 11.11

この機能はバージョン 11.11 で提供。店舗の全端末のアプリ更新状況を揃えておく必要がある。

有効化の手順そのものはヘルプセンター側に記載があるとされ、Changelog 本文には具体的な設定パスの記述は無い。対応国・対応プランの制限についても記載なし。

7技術者が押さえるべき5つのポイント

1. カートの所在が端末からアカウント側へ移る

従来「端末ローカルの一時状態」だったカートが、端末をまたいで参照できる共有リソースになる。オフライン時の挙動や競合(同じカートを2端末で同時に開いた場合)については記載なし = 実機検証が必要な領域。

API ?

2. API / Webhook 仕様の言及は無い

Changelog は POS アプリの機能説明にとどまり、Admin API や POS UI Extensions からカートを操作できるかは記載なし。外部システム連携を設計する前に開発者ドキュメント側の確認が要る。

3. 「誰の売上か」の設計が要る

作った人と会計した人が分かれる以上、スタッフ別実績の集計方針を先に決める必要がある。カートに紐づくスタッフ帰属がどう記録されるかは記載なし = インセンティブ制度がある店舗ほど事前確認が必須。

4. 既定フィルタは「自分のカート」

カートビューは初期状態でログイン中スタッフに絞り込まれる。他人のカートを引き継ぐ運用にするなら、フィルタを外す操作をオペレーションに明記しないと「渡したのに見つからない」が起きる。

draft

5. draft order 変換は既存の自動化に流し込める接続点

カートを 1 スワイプで下書き注文に変えられるということは、下書き注文をトリガにした既存の Flow / アプリ / Webhook の仕組みに、店頭の未成約カートを乗せられるということ。追客メール、在庫取り置き、後日決済リンクなどを既存資産のまま接続できる。ただし変換後の下書き注文にどのメタ情報が載るかは記載なし。

8業務に活かせる3つのユースケース

A → B
USE CASE 1

接客と会計を分ける「フロア接客型」オペレーションへの転換

課題
売場で提案した内容を、レジで別スタッフが打ち直している。読み合わせと再入力で 1 件あたりの会計時間が伸び、繁忙時間帯にレジが詰まる。
打ち手
売場スタッフはモバイル端末でカートを組み立てるところまで担当し、レジ担当がカートビューから引き継いで決済のみ実行する分業に切り替える。
効果
レジでの再入力が無くなり、打ち間違いによる訂正も減る。接客スタッフは顧客の横を離れずに提案を続けられる。
技術メモ
カートビューは既定でログイン中スタッフに絞られるため、引き継ぎ時にフィルタを解除する手順を店舗マニュアルに明記する。全端末を 11.11 以上に揃えることが前提。
顧客A 顧客B 顧客C 顧客D 同時進行のカート
USE CASE 2

1人のスタッフが複数の顧客を並行して抱える売場の「取り違え防止」

課題
試着待ちや在庫確認の待ち時間に別の顧客を接客するため、担当がバラバラの商品を頭とメモで管理している。会計時に商品の取り違えや漏れが起きる。
打ち手
顧客ごとにカートを分けて作り、カート間を切り替えながら接客する。組み立て途中のカートは自動保存されるので、中断してもそのまま残る。
効果
顧客ごとの検討内容が端末上に残り、取り違え・入れ忘れが減る。待ち時間に別顧客を挟んでも取りこぼさない。
技術メモ
カートの保持期間・上限は記載なし。閉店時に未成約カートをどう処理するか(下書き注文化するか破棄するか)を運用ルールとして先に決めておく。
swipe draft 後日 追客・決済リンク
USE CASE 3

その場で決まらなかった検討カートを、下書き注文として追客資産に変える

課題
高単価商材や在庫切れサイズの検討で「持ち帰って考える」となった案件が、口頭のまま消えていく。何をいくらで提案したのかが店舗に残らない。
打ち手
成約しなかったカートを 1 スワイプで下書き注文に変換し、後日の連絡・見積提示・決済リンク送付につなぐ。
効果
店頭の検討内容が管理画面側のデータとして残り、追客の起点になる。提案の再現に時間を使わずに済む。
技術メモ
下書き注文をトリガにした既存の自動化(Flow・外部アプリ・Webhook)にそのまま乗せられる可能性がある。ただし変換後にどのメタ情報(担当スタッフ・店舗・元カート)が引き継がれるかは記載なしのため、自動化を組む前に 1 件変換して実データを確認すること。

9提案で使える1行サマリ

「POS のカートを端末から解放し、チームで共有できるようにする機能。
自動保存・端末間の引き継ぎ・専用カートビュー・1スワイプで下書き注文化。
売場で作って、レジで閉じる。POS Pro+バージョン 11.11 で今すぐ使える。」