Shopify Flowで受注処理を自動化するなら、最初は「条件に合う注文へタグを付け、担当者へ知らせる」など、結果を確認しやすい処理から始めます。注文の作成、入金、発送は別の出来事です。自動化する前に、どの時点のデータで、何を判断し、失敗したら誰が対応するかを決めます。
注文作成と入金済みを区別する
| トリガーの例 | 用途の例 | 注意点 |
|---|---|---|
| Order created | 受付時の商品・メモを分類する | 注文作成だけで入金済みと判断しない |
| Order paid | 支払い完了後の社内確認へ回す | 条件に使う通貨・金額の定義をそろえる |
| 別の在庫・配送イベント | 在庫や配送の状態に応じて処理する | 受注イベントと同じデータが使えるとは限らない |
Flowのトリガー説明を参照し、名前が似たイベントも同一視しないようにします。Order paidは支払い状態が支払い済みに変わる際に始まります。
実装する前の業務設計表
| 決めること | 記入例 |
|---|---|
| 目的 | 包装希望の見落としを減らす |
| 発火時点 | 注文作成時 |
| 条件 | 注文メモに店舗で定めた受付語がある |
| 処理 | 注文へ確認用タグを追加し、担当へ通知 |
| 人の判断 | 包装可否と費用を確認して出荷へ進める |
| 例外 | メモなし、表記違い、変更依頼、取消 |
これは設計例で、すべてのメモ表現を自動判別できるという意味ではありません。注文後のメモ変更まで扱うなら、その変更を拾う別の運用が必要です。文字列一致だけで有料作業の確定や出荷指示まで進めないようにします。
タグと社内通知のワークフローを作る
- Flowで新しいワークフローを作り、目的に合うトリガーを選びます。
- 利用できる注文データから条件を選びます。商品判定は表示名だけでなく安定した識別子を検討します。
- 条件を満たした注文へ、店舗で命名をそろえたタグを追加します。
- 担当者が使う通知先を設定し、注文番号・管理画面で確認する情報・対応内容を入れます。
- 該当しない場合と、情報が欠ける場合の流れを確認します。
- 後述のテストで条件と出力を確認し、対象を限定して有効化します。
Add order tagsの公式説明で、タグが注文に追加されることを確認します。顧客タグとは付与先が違います。注文の分類タグを付けただけで、その顧客を販促メールの購読者として扱わないでください。
条件の境界と二重処理をテストする
| ケース | 確かめること |
|---|---|
| 条件に一致 | 正しい注文へ予定のタグと通知内容が出る |
| 条件に不一致 | 通知や処理を行う経路へ進まない |
| 金額が境界と同額 | 「以上」と「より大きい」の設定が意図と合う |
| メモや顧客情報が空 | 欠損を前提とした条件と表示になる |
| 処理済み・再実行 | 同じ通知や外部処理を重ねる条件にならない |
| 取消・返金 | 古い分類をどう見直すか担当が分かる |
公式のワークフローテストは有効化前に条件と変数を確認できます。テストでは実更新を伴うアクションは実行されず、変更する最初のアクションで止まるなどの制約があります。分岐の確認と、外部サービスを含む一連の実動作確認を区別してください。既存データを使う模擬イベントでも、個人情報の表示・共有先には注意します。
運用開始後の監視と停止方法
開始直後は最近の実行結果と、実際の注文・タグ・担当者の受信結果を照合します。エラーが出たら、トリガー、条件、実行アクション、外部連携のどこで止まったかを記録します。むやみに再実行せず、決済・発送・通知など、既に行われた操作の有無を先に確認します。
ワークフローには目的、担当者、確認日、停止後の手作業を残します。公式の管理ガイドに沿って複製やエクスポートで版を保全し、変更理由を記録すると、想定外の処理を止めて見直しやすくなります。
顧客に届く通知は注文・発送メールの確認と合わせて点検してください。受注業務の整理と自動化はお問い合わせからご相談いただけます。
コメント