定期購入の例外変更をCSの記憶に任せない｜配送日・住所・商品・スキップを契約単位で処理する判断台帳（Shopify・ecforce）
ON THIS PAGE▼
定期購入の変更依頼は「契約」だけを見て処理しない
定期購入の配送日変更、住所変更、商品・数量変更、スキップは、依頼内容だけを見ると単純です。しかし実務では、同じ契約に対しても、次回分の注文がどこまで進んでいるかで処理が変わります。
たとえば「次回を1週間遅らせたい」という依頼は、契約上の配送サイクルを変える話なのか、次回1回だけを調整したい話なのかを最初に分ける必要があります。さらに、次回受注が生成済みか、WMSや倉庫へ連携済みか、決済が実行済みかによって、画面上で変更できても実際には止められない工程があります。
そこでCSと受注担当は、依頼を受けた順に次の3層を照合します。
- 契約：対象顧客、契約ID、契約状態、商品、数量、配送頻度、登録住所
- 次回受注：次回注文の有無、注文番号、明細、配送先、決済状態、注文ステータス
- 出荷・連携：出荷締切、倉庫・WMS連携状態、送り状発行・出荷済みの有無
この順序にすると、「契約の住所だけ変え、すでに作成済みの次回受注は旧住所のまま」「スキップ処理をしたが、倉庫連携済みの注文を止めていない」といった分断を発見しやすくなります。契約を更新する担当と出荷を止める担当が異なる場合にも、引き継ぐ情報を固定できます。
変更操作の前に、契約IDと次回注文番号を1件の記録に並べてください。顧客名やメールアドレスだけで処理対象を特定すると、複数契約・過去注文がある顧客で照合が曖昧になります。
最初に決めるべき判断軸：変更対象と締切
変更依頼を受けたときに必要なのは、すぐに「可能です」と返すことではなく、どのデータを、いつまでに、誰が更新するかを決めることです。受付時の確認項目を依頼種別ごとに固定します。
| 依頼種別 | 最初に確認すること | 契約以外で確認すること | 顧客へ確定前に伝えること |
|---|---|---|---|
| 配送日・配送頻度 | 今回のみか、以後も変えるか | 次回受注の生成、出荷締切、決済予定 | 希望日に確定できるかは出荷状況確認後に案内する |
| 配送先変更 | 変更対象が次回以降か、登録情報全体か | 次回受注の配送先、送り状・倉庫連携 | 出荷準備後は変更不可または別対応となる可能性 |
| 商品・数量変更 | 代替商品、価格、頻度への影響 | 次回受注の明細、在庫、決済額、同梱条件 | 差額・在庫・反映回を確認してから案内する |
| スキップ | 対象回、次々回以降への影響 | 次回受注の有無、出荷連携、決済 | スキップ後の次回予定と、連携済み注文の扱い |
| 停止・解約 | 一時停止か解約か | 未処理注文、返金・取消の要否 | 解約後の復元可否、新規契約が必要になる条件 |
ここでいう「締切」は、画面上の編集期限ではなく、自社が変更を保証できる最終時点です。少なくとも、以下の時点を業務ルールとして定義します。
- 顧客がセルフサービスで変更できる締切
- CSが契約・注文を通常手順で変更できる締切
- 倉庫連携を止められる締切
- 送り状発行後・出荷後に適用する例外手順の分岐点
締切を一律の「発送○日前」にする必要はありません。配送方法、倉庫の連携回数、決済方法で差があるなら、配送グループや出荷拠点ごとに管理します。重要なのは、CSが画面を見て都度推測するのではなく、案内の基準とエスカレーション先を持つことです。
依頼から完了までを残す「定期変更台帳」
定期変更台帳は、別の基幹システムを新たに導入するものではありません。少なくとも、契約・注文・出荷の照合結果と顧客案内を同じ行に残せる仕組みです。チケットシステム、スプレッドシート、CRMのカスタム項目のいずれでも構いません。
最低限の台帳項目
以下を1依頼につき1行、または1チケットにつき固定項目として持ちます。
| 区分 | 記録項目 |
|---|---|
| 受付 | 受付日時、受付経路、依頼者確認、依頼内容、希望適用回 |
| 特定 | 顧客ID、契約ID、次回注文番号、対象商品・数量 |
| 状態確認 | 契約状態、次回受注の状態、決済状態、倉庫・WMS連携状態、出荷締切 |
| 判断 | 標準処理／例外処理／不可、判断者、判断理由、承認者 |
| 実行 | 変更した対象（契約・注文・両方）、実行日時、実行者、操作画面または処理番号 |
| 案内 | 顧客への返信日時、確定した配送日・住所・商品・金額、案内担当 |
| 完了確認 | 変更後の契約・注文の再確認、倉庫への連絡有無、完了者 |
「変更後の値」を残すことも重要です。「住所変更済み」「配送日変更済み」では、後から何をどこまで変えたかが分かりません。旧値をすべて複製する必要はありませんが、少なくとも確定した新しい配送先、次回予定、商品・数量、対象注文番号は記録します。
ステータスは処理進行ではなく確認状態で分ける
台帳のステータスを「対応中」「完了」だけにすると、どこで止まっているかが分かりません。次のように確認工程に沿って分けます。
- 受付：本人・対象契約・依頼内容が未確定
- 可否確認中：出荷・決済・在庫などを照合中
- 実行待ち：承認、倉庫回答、顧客回答待ち
- 変更実行済み：画面操作は完了、注文・連携の再確認前
- 案内済み：顧客へ確定内容を送信済み
- 完了：契約、次回受注、出荷連携の必要な確認を終えた状態
- 例外完了：通常画面外の対応、取消、返金、再注文などで完了
この設計なら、作業量だけでなく「締切が近いのに可否確認中」「実行済みだが案内未送信」の案件を抽出できます。
Shopify Subscriptionsで確認できる変更範囲と注意点
Shopify Subscriptionsの公式ヘルプでは、管理者が定期契約に含まれる商品、数量、配送頻度、連絡先・配送先を管理し、次回注文のスキップ、契約の停止・再開・解約を扱えることが案内されています。顧客もアカウント画面から、配送先、支払い方法、次回注文のスキップ、停止・再開・解約などを管理できます。仕様確認日はいずれも2026年10月2日です。
ただし、CSの運用では「顧客が変更できる」ことと「確認なしで変更を任せられる」ことを同一視しません。次のように振り分けます。
セルフサービスへ案内しやすい依頼
- 出荷締切前であり、顧客が対象契約を特定できる
- 配送先やスキップなど、顧客アカウントで公式に管理対象とされている変更
- 商品の代替提案、差額確認、個別承認を必要としない依頼
案内後は、顧客が変更できたはずとみなして台帳を閉じません。出荷締切が近い依頼や、変更が注文・倉庫連携に影響する依頼では、変更後の契約・次回注文を確認する担当と時点を決めます。
CSが契約と次回受注を照合して扱う依頼
- 今回だけの配送日調整か、配送頻度そのものの変更かが不明なもの
- 商品・数量を変えることで在庫、価格、決済額の確認が必要なもの
- すでに次回注文が存在するもの
- 出荷締切が近い、または出荷連携後のもの
- 停止・解約を希望するが、未出荷注文の扱いも決める必要があるもの
Shopify Subscriptionsでは、解約後に同じ契約を元に戻すことはできず、顧客が新しい契約を作成する必要があります。解約は「あとで戻せる停止」として扱わず、停止との違い、未処理注文への影響、顧客の意図を確認してから実行します。
なお、提供された公式資料で確認できるのは配送頻度の管理やスキップ等です。個別の希望日に次回配送日を直接指定できるか、生成済み注文への反映条件、アプリや外部連携を含む挙動は、利用中の設定・アプリ構成で別途テストしてください。仕様を確認しないまま、配送頻度の変更で単発の配送日要望を代替処理するのは避けます。
Shopify Flowを利用できる環境では、定期契約データを取得し、ステータス条件などで対象を後続処理へ渡せます。これは全件を自動変更する用途よりも、「締切接近」「確認待ち」といった案件を内部通知や例外キューに出す用途から検討すると、安全です。変更操作そのものの自動化は、注文生成や出荷連携との前後関係を検証してから範囲を限定します。
ecforceでは「親受注」と「子受注」を分けて確認する
ecforceの公式FAQでは、定期受注管理の配送情報から、次回配送予定日（発送日）とお届け時間を変更する方法が案内されています。また、受注管理の一括更新では、子受注に紐づく親受注の次回発送予定日・次回配送予定日を変更できます。参照したFAQのページ更新日は2026年3月10日、仕様確認日は2026年10月2日です。
この仕様から実務上注意したいのは、依頼の対象を「目の前の子受注」だけで判断しないことです。定期変更台帳には、親受注番号と、今回影響する子受注番号を分けて記録します。
個別変更と一括更新を同じ手順にしない
個別の配送日・時間変更を処理する場合は、対象契約と対象回を照合し、変更後に次回配送予定日を確認します。一方、一括更新は対象抽出の条件が不十分だと、意図しない親受注まで変更するリスクがあります。そのため、一括更新を使う前には少なくとも次を確認します。
- 対象件数が依頼件数・承認件数と一致するか
- 抽出結果に対象外の配送周期、商品、顧客が含まれていないか
- 更新対象が親受注の次回発送予定日・次回配送予定日であることを理解しているか
- テスト環境または影響を限定した少数件で、子受注・出荷連携への反映を確認したか
- 更新後に対象一覧を再抽出し、変更値と件数を照合する担当がいるか
公式FAQで確認できるのは配送日時変更と一括更新の操作範囲です。住所、商品、数量、スキップ、決済、外部倉庫への反映条件までを同じ手順で処理できるとは限りません。これらは契約・受注・連携の設定に依存するため、利用中のecforce環境で操作権限、出荷ステータス、連携タイミングを確認し、台帳の確認欄で管理します。
顧客案内は「変更しました」ではなく確定内容を返す
定期購入の変更では、操作完了と顧客への説明完了を別工程にします。変更できなかった場合だけでなく、変更できた場合にも、顧客が次に何を受け取るのかを明確にします。
変更完了時の案内テンプレート
ご依頼の定期購入について、次回分を以下の内容で変更しました。
対象：［商品名／契約識別情報］
次回のお届け予定：［日付・時間帯］
お届け先：［必要に応じて都道府県・市区町村など確認に必要な範囲］
商品・数量：［変更がある場合のみ記載］
今後の配送：［今回のみ変更／以後の頻度を変更］
※出荷状況などにより、別途ご案内が必要な場合はお知らせします。
配送先は、メールの誤送信時に個人情報を過度に露出しないよう、表示範囲を自社ルールで定めます。また、変更不可の場合は、単に「締切を過ぎたため不可」と伝えるより、今回の注文の状態、可能な代替策、次回以降に反映できる内容を分けて案内します。出荷済みなら追跡・配送会社への案内、未出荷であれば取消・再注文の可否など、実際に選べる手段だけを提示します。
運用開始前に行うテストと週次レビュー
台帳を作っても、契約変更が次回受注や倉庫連携にどう反映されるかを確認していなければ、判断基準にはなりません。稼働前に、少なくとも以下のケースをテストまたは検証済みの記録で確認します。
- 次回受注の生成前・生成後で、配送先変更がどこに反映されるか
- 出荷連携前・連携後で、スキップまたは配送日変更をした場合の扱い
- 商品・数量変更時の価格、決済額、在庫、明細の変化
- 停止、再開、解約後の次回注文と顧客画面の表示
- ecforceの個別変更と一括更新で、親受注・子受注に生じる差分
- 変更後に顧客へ送る通知、社内への連絡、台帳の完了条件
週次では、台帳から「締切超過後の受付」「実行済み・案内未送信」「例外完了」「同じ理由による再問い合わせ」を確認します。ここで目的にするのは、担当者の対応速度だけではありません。どの依頼が標準機能で閉じ、どこで契約・受注・出荷の照合が必要になったかを把握し、締切、画面手順、顧客案内を更新することです。
定期購入の例外対応は、すべてを自動化するほど安全になるとは限りません。取消不能な解約、出荷連携後の注文、価格や在庫に影響する商品変更は、人が確認する設計を残す必要があります。一方で、契約ID、次回注文、出荷状態、確定案内を台帳に揃えれば、担当者の記憶や個別チャットに依存せず、どこまで処理したかを引き継げます。
参考情報
この課題、もっと詳しく相談したい方へ
記事では答えきれない個別の状況にもお応えします。