Shopify Collective商品をPOSで売る前に作る受注引継ぎ台帳｜仕入先通知・出荷確認・キャンセル／返品の手動運用

POSで販売できることと、出荷依頼が完了することは分けて確認する

Shopify Collectiveの商品はPOS販売チャネルに追加でき、対面で注文を受けられます。一方で、店舗で決済した注文について、仕入先への依頼、仕入先の出荷可否確認、追跡番号の回収までを、自社の通常商品と同じ手順で処理できるとは限りません。

Shopify公式ヘルプでは、通常のCollective注文は仕入先がフルフィルメントを行い、追跡情報は小売店側へ同期されると案内されています。また、手動決済や販売チャネルによっては、小売店側で仕入先へのフルフィルメント依頼が必要になる場合があります。POS注文を扱う前には、利用中のストア、接続している仕入先、決済方法の組み合わせで、どの状態まで自動処理されるかをテスト注文で確かめてください。確認日：2026年9月29日。

この記事では、POS起点のCollective注文を、**仕入先が出荷を受け付けたと確認できるまで「出荷未確定」**として扱います。自動連携の有無を推測して販売を始めるのではなく、確認できなかった場合にも注文を止めずに処理できる台帳と担当分担を先に用意するためです。

販売開始前に決めるべき4つの取引パターン

同じPOS会計でも、購入者が商品を受け取る場所と在庫の所在で必要な処理が変わります。POSで販売するCollective商品を登録する前に、少なくとも次の4パターンを商品または仕入先単位で分類します。

1. 店舗で商品をそのまま渡す

店舗に当該商品の在庫を保有し、会計時に購入者へ渡す形です。この場合は配送手配が不要でも、Collective上の在庫・請求・仕入先との精算の扱いが自社の販売形態に適合するかを確認します。店頭在庫を自社で持つなら、Collectiveでの販売を継続する必要があるか、通常の仕入れ商品として管理すべきかも検討対象です。

2. 店舗で会計し、仕入先から購入者へ直送する

本記事で台帳管理が特に必要になる形です。POS会計時に、配送先、連絡先、配送希望に関する情報を不足なく取得します。仕入先が受諾する前に、購入者へ確定した発送日を約束しない運用が安全です。

3. 店舗で会計し、後日店舗で渡す

仕入先から店舗へ送ってもらい、到着後に購入者へ引き渡す形です。この場合、仕入先出荷だけで完了にはなりません。店舗到着、検品、購入者への到着連絡、保管期限、未受取時の扱いまで、台帳の状態を増やします。

4. 通常商品とCollective商品を同一会計に含める

通常商品を自社倉庫から、Collective商品を仕入先から送る場合、購入者には複数便になる可能性があります。レシートや接客時の説明、送料・配送日・追跡番号の案内を、商品群ごとに分けられるようにします。1注文番号だけで「発送済み」と判断すると、一部の商品だけが未出荷でも見落とします。

この分類は、POSの商品名やコレクションだけで判別しようとせず、商品SKU、仕入先名、出荷元、引渡方法を台帳に持たせて運用します。

受注引継ぎ台帳は「1注文1行」ではなく「1出荷単位1行」にする

通常商品とCollective商品、または複数のCollective仕入先が同じPOS注文に入ることがあります。そのため、台帳はPOS注文番号だけを主キーにせず、**POS注文番号＋出荷元（または仕入先）**を1行の管理単位にします。

たとえばPOS注文番号が#1001で、通常商品と仕入先Aの商品を購入した場合は2行です。仕入先Aと仕入先Bの商品を購入したなら3行になります。これにより、出荷状況や追跡番号を出荷単位で追えます。

最低限入れる列

スプレッドシート、受注管理ツール、チケットシステムのいずれでも構いません。まずは次の列を固定してください。

「現在の状態」は自由記述にせず、選択肢を固定します。たとえば、会計済み、通知済み、仕入先確認待ち、出荷予定確定、発送済み、追跡反映確認済み、取消協議中、返品対応中、完了です。

通知済みのまま止まる注文を抽出できることが、台帳を作る主な目的です。各状態には確認期限も設定します。期限の日数は仕入先との合意した回答・出荷条件に合わせ、根拠なく一律の日数を置かないでください。

台帳に残すべき証跡

電話や口頭で確認した内容も、確認者、日時、確認事項を残します。特に次の4点は、後から確認できる場所を台帳に紐付けます。

• 仕入先に渡したSKU、数量、配送先、注文番号
• 仕入先が出荷可能と回答した内容と出荷予定
• 追跡番号、配送会社、発送日
• 購入者へ伝えた配送予定、取消・返金、返品先の内容

個人情報を含むため、仕入先への通知先、台帳の閲覧権限、データの保管場所は必要最小限にします。仕入先へ渡す情報は出荷に必要な範囲に限り、POSレシートの共有で不要な情報まで渡さないようにします。

POS会計から発送案内までの標準手順

店舗スタッフだけに判断を委ねると、接客中に確認作業が抜けやすくなります。会計担当、受注管理担当、仕入先窓口、購入者対応担当を、少人数でも役割として分けます。同じ人が兼任しても、完了確認を別の工程として記録することが重要です。

会計時：購入者に確定前の約束をしない

直送または後日渡しの商品では、会計前に以下を確認します。

• 商品がCollective経由の手配対象であること
• 購入者が希望する受取方法
• 配送先の郵便番号、住所、電話番号、メールアドレス
• 複数便になり得ること
• 発送日が仕入先の受諾後に確定すること

店頭掲示、商品説明、スタッフ用の接客文に「仕入先確認後に発送予定をご案内します」といった表現を用意しておくと、担当者ごとの説明差を抑えられます。これは遅延を前提に不安を与えるためではなく、発送確定前の情報を断定しないための案内です。

会計後：台帳へ登録し、通知と受諾確認を分離する

1. 会計担当がPOS注文番号を台帳へ記録する。
2. 受注管理担当がSKUと仕入先ごとに行を分け、配送情報を確認する。
3. 仕入先へ注文情報を通知し、通知日時と手段を記録する。
4. 仕入先から出荷可否、出荷予定、欠品の回答を得る。
5. 回答を得るまで、状態を仕入先確認待ちに置く。
6. 出荷予定が確定したら、購入者へ案内する。

Shopify公式ヘルプにあるCollective注文管理の手順では、注文状態に応じて仕入先へのフルフィルメント依頼や取消依頼を行います。POS注文で画面上の操作が可能か、操作によって仕入先へ実際に依頼されるかは、テスト注文で確認し、結果を自社の手順書に追記してください。

発送後：追跡番号の「受領」と「反映」を確認する

仕入先から追跡番号を受け取っただけでは、購入者がShopifyの注文確認画面や通知から確認できるとは限りません。台帳では次を分けます。

• 仕入先から追跡番号を受領した
• Shopify注文に追跡情報が反映された
• 購入者へ発送案内を送った

通常のCollective注文で追跡情報が同期される仕様であっても、POS起点の対象注文で同様に表示されるかは、実際のテスト結果で判定します。反映されない場合は、誰がどのチャネルで購入者へ追跡番号を案内するかを決めます。

Shopify Flowは通知補助にとどめ、依頼完了の代わりにしない

Shopify Flowでは、注文作成をきっかけに内部メールを送るワークフローを作成できます。公式ヘルプでは、注文情報をLiquid変数でメールの件名・本文に差し込めることが案内されています。

たとえば、POS注文を識別できる条件を設定したうえで、社内の受注管理窓口へ次の情報を送る設計は有効です。

• 注文番号と注文日時
• 注文商品、SKU、数量
• 購入者の配送先情報
• 台帳の登録先リンク
• 「仕入先確認待ち」として確認するよう促す文言

ただし、Flowで社内メールを送ることと、Collectiveの仕入先へフルフィルメント依頼を作成することは別です。仕入先へ直接メールを送る場合も、宛先の管理、個人情報の取扱い、返信の受領確認が必要です。

Flowを導入する前には、利用中のShopifyプラン・アプリ構成で使えるトリガーとアクション、POS注文に対する条件判定を管理画面で確認してください。ワークフローの実行履歴を確認する担当者も決めます。実行失敗時に台帳へ登録されない設計なら、通知の自動化がかえって連絡漏れを見えにくくするためです。

キャンセル・返品は、返金と仕入先処理を別々に閉じる

Collective注文では、小売店が購入者との窓口になります。購入者への返金だけを完了しても、仕入先への取消依頼や返品先の確認が終わっていなければ、運用は完了していません。

会計後、出荷前のキャンセル

購入者からキャンセル連絡を受けたら、まず台帳で仕入先受諾・出荷の状態を確認します。未出荷でも、すでに仕入先に通知済みなら取消依頼を行い、回答を記録します。

管理する完了条件は、少なくとも以下です。

• 購入者への返金または返金予定の案内
• 仕入先への取消依頼
• 仕入先からの取消可否の回答
• Shopify上の注文・フルフィルメント状態の確認
• 台帳の取消理由と完了日時

Shopify公式ヘルプでも、Collective注文の取消・返金は注文の状態に応じて手順が分かれます。POS会計直後の取消、仕入先受諾後の取消、出荷後の取消を1つの手順にまとめず、状態別の判断表を手順書に持たせてください。

出荷後の返品

Collectiveの返品では、仕入先が返送ラベルを用意する、小売店がラベルを用意して仕入先または自店舗へ返送する、手動で処理するといった選択肢があります。どの商品をどこへ返送するかは、購入者から問い合わせを受けてから調べるのではなく、仕入先ごとの返品ポリシーとして事前に登録します。

台帳には返品先住所だけでなく、次も残します。

• 返品受付日と受付担当
• 返送ラベルを用意する主体
• 返品先（仕入先・自店舗・その他）
• 返送追跡番号
• 仕入先の受領確認
• 購入者への返金実行日

返品の返金時点は、仕入先の返品条件、自社の購入者向けポリシー、商品の状態によって異なり得ます。仕入先との取り決めと購入者向け表示が矛盾していないかを、販売前に確認します。

公開前に行う4件のテスト注文

運用設計は、設定画面を読むだけでは完了しません。実際に少額でテスト注文を作成できる条件を整え、台帳の全列が埋まるかを確認します。テスト後は注文を削除するのではなく、テスト用であることを明記して記録を残します。

テスト1：Collective商品の単独POS販売

確認するのは、POS注文の作成、仕入先側での注文認識、必要なフルフィルメント依頼、追跡情報の反映、購入者通知です。自動化されない箇所を洗い出し、台帳の必須作業にします。

テスト2：通常商品との混載

通常商品とCollective商品を同一会計に入れます。出荷元ごとに台帳行を分けられるか、購入者への案内で複数便を説明できるか、通常商品の発送完了でCollective商品まで完了扱いにならないかを確認します。

テスト3：複数仕入先のCollective商品

仕入先ごとに通知先、受諾期限、追跡情報、返品条件が異なることを前提に確認します。1つのPOS注文に対して、通知・受諾・発送の完了時刻を別々に記録できなければ、台帳を修正します。

テスト4：会計後のキャンセルと返品

出荷前キャンセルと、出荷後返品を可能な範囲で検証します。返金操作、仕入先への取消・返品連絡、返送ラベルの担当、台帳の完了条件を確認します。実商品の返品テストが難しい場合でも、仕入先と手順を文書で合意し、誰がどの画面・連絡先で処理するかを確認します。

テスト結果は「できた／できない」だけでなく、操作担当、確認画面、必要な権限、仕入先からの回答時間、購入者へ案内した内容を残します。ShopifyやCollectiveの仕様、仕入先の運用、利用アプリを変更したときは、同じ4件を再テストする判断基準にできます。

販売を始める判断基準

POSでCollective商品を販売する前に、少なくとも次の状態になっているかを確認してください。

• 商品ごとに出荷元・仕入先・引渡方法を判別できる
• POS注文から出荷単位ごとに台帳を作れる
• 仕入先通知、受諾、発送、追跡反映、購入者案内の担当が決まっている
• 通知済み・確認待ち注文を日次で確認する担当と時刻が決まっている
• キャンセル、返品、返金の完了条件を仕入先別に確認済みである
• 単独販売、混載、複数仕入先、キャンセル／返品のテスト結果がある

ここまでを満たせば、POSで売れるという機能確認を、購入者への説明と仕入先への引継ぎまで含む受注運用へつなげられます。自動処理できる部分が確認できた後も、例外注文を追える台帳を残しておくと、連携仕様や仕入先条件が変わった際の確認場所になります。

参考情報

• Shopify Collective利用の要件と考慮事項（Shopify Help Center）
• Shopify Collectiveアプリでの注文管理（Shopify Help Center）
• Shopify Collectiveアプリの返品ポリシー（Shopify Help Center）
• Shopify FlowでLiquid変数を使う（Shopify Help Center）
• Feature Request: Shopify Collective + POS Order Routing（Shopify Community） ※POS起点の引継ぎ漏れを想定した運用設計の補助的な問題提起として参照。仕様根拠には使用していません。
• Shopify Collective shipping delays（Reddit r/shopify） ※仕入先出荷の状況確認と購入者連絡を分けて管理する必要性を検討する補助的な問題提起として参照。仕様根拠には使用していません。