STEP 01
最初の自動化は、仕事を一つだけ任せる
受注管理システムを選ぶことと、自動処理のルールを作ることは別です。すでに使うカートや受注ツールで、毎回同じ条件を見て同じ操作をしている箇所から探します。判断が担当者ごとに違う仕事は、先に手順をそろえます。
たとえば『ギフト指定のある注文へ、担当者確認の目印を付ける』に限定します。目印を付けたから包装確認済み、発送可能、出荷完了と扱うわけではありません。タグや目印が別の自動処理を起動することもあるので、既存ルールとのつながりを先に調べます。
返金、注文取消し、在庫調整、出荷指示など影響が大きい処理は、同じ試行へ混ぜません。以下ではShopify Flowを具体例に、テスト・記録・再実行の仕様を確認します。他サービスの停止や再送も同じとは限りません。
STEP 02
きっかけ・条件・処理と、任せない注文を書く
きっかけは注文作成など、そのルールを調べ始める出来事です。条件はギフト指定の有無など対象を選ぶ基準、処理は目印の追加など実行する操作です。この三つを分け、いつの注文状態を使うかも決めます。
取消済み、出荷作業中、情報不足、すでに同じ確認待ちの目印がある注文など、対象にしない条件を置きます。『ギフトである、または未処理』では広すぎるのか、『ギフトであり、かつ未処理』なのかを例で確かめます。空欄を自動で「いいえ」と決めず、情報不足として人へ回す条件も用意します。
注文番号だけでなく、どの処理をどの単位で済ませたかが分かる記録を持ちます。同じ注文への再通知や手動実行があっても、顧客通知や出荷指示を二重に送らない設計か確認します。単に処理済みタグを付けるだけで、同時実行や途中失敗まで防げるとは考えません。
STEP 03
テスト画面の合格と、実際の反映を分ける
条件に合う注文だけでなく、合わない注文、空欄、取消済み、同じ注文をもう一度渡す場合を試します。何を実行するはずかに加え、何も変更してはいけない場合を確かめます。既存の実注文を勝手に複製したり、顧客へ試験メールを送ったりしないようにします。
Shopify Flowのテストは、変数と条件の確認に使えますが、実店舗データを書き換える最初のアクションで止まります。外部サービスへの処理も実行されないため、テスト画面が通ったことを、タグ更新や通知の到達まで確認済みとしません。実データを使うテストでも、テスト実行と本番操作は別です。
イベントを記録するため自分で実注文を作る方法では、その注文作成自体は本番操作です。可能なら模擬イベントを使い、実行確認が必要な段階は権限のある担当者と対象・副作用を決めます。少量の実行後には、処理先で目印が付き、対象外には付いていないかを照合します。
STEP 04
200回動いたことを、200注文完了と数えない
仮の運用記録として、受信・手動再実行などを合わせて200回の受付があり、注文番号で数えると190注文だったとします。追加10回は同じ注文の重複分です。これはShopifyで必ず重複が起きるという主張ではなく、件数を分けるための架空例です。
190注文を重複なく分け、対象150注文、条件外40注文とします。対象150のうち、目印の反映を確認できたのが145、待機3、失敗2なら、未完了は5注文です。受付200回でも、自動処理の反映完了は145注文で、ギフト内容の確認完了や発送完了ではありません。
条件外40も、注文全体の仕事が不要とは限りません。この自動化を使わないだけで、通常の受注手順へ回します。残る5は同じ締切で放置せず、待機理由と失敗箇所、担当者、次に確認する時刻を残します。
STEP 05
エラーを直したら、再実行の前に反映済みを調べる
失敗表示が出ても、途中まで処理できている場合があります。どの注文のどの処理が終わったかを接続先でも照合し、『失敗だから全部未実行』として送信を繰り返さないようにします。待機中と失敗も分け、並行して二つの復旧処理を走らせないようにします。
Shopify Flowの手動再試行には、実行中・待機中ではないこと、ワークフローが有効であること、起動条件が元の実行と一致することなどの条件があります。元のきっかけのデータを使っても、取得データや条件・処理では最新の状態が使われるため、過去と同じ結果になるとは限りません。
修正後は対象を絞って再試行し、元の実行と新しい実行の両方を追います。送り直す前に注文が取消しや出荷済みへ変わっていないかも見直し、必要なら自動化を使わず担当者が個別対応します。
STEP 06
止め方と、その後に残る仕事まで決める
対象外への処理、二重通知、内容の取り違えを見つけたら、広げずに停止と影響確認へ進みます。どの担当が停止できるか、止めている間の受注をどこで確認するか、再開条件は何かを決めておきます。停止ボタンを押しただけで、すでに送った通知や更新が元に戻るわけではありません。
Shopify Flowでは、個別の実行取消しは関連するワークフロー全体を無効にはしません。反対にワークフローをオフにすると、新規起動を止め、進行中の実行も取り消します。取消しには時間がかかる場合があるため、状態と反映先を確認してから手動対応を重ねます。
同サービスの実行履歴は完了後14日間の保存です。必要な注文番号、実行ID、条件、反映結果、訂正理由を社内の適切な保存先へ残し、必要以上の顧客情報を複製しないようにします。短縮した時間だけでなく、確認待ちの残件と誤処理も見て、安定した一つの処理から対象を広げます。