承認ワークフロー

読了時間： 7 分。 対象： 提案がバイヤーへ届く前に社内の決裁が必要なマーチャント、またはバイヤーの購買チームが承認の前に決裁を必要とするマーチャント。

⚠️ 承認ワークフローには Professional プラン以上が必要です。LiteとStarterのマーチャントにはポリシーの編集画面が見えますが、ポリシーを作成することはできません。Professionalには一本道の多段階の連なりが含まれます。並列・条件付きの段階、期限切れのエスカレーション、代理承認はEnterpriseの機能です。 プラン、トライアル、料金をご覧ください。

QuotWayは承認の二つの側に対応します。

• マーチャント側 - 営業担当者が提案し、営業マネージャーが承認してから提案がバイヤーへ送られます。
• バイヤー側 - バイヤーが提出し、購買の管理者が承認し、次に経理が承認し、それから見積が正式に承認されます（BtoBに対応したストア）。

どちらの側も同じポリシーの構造を共有します。段階、段階ごとの担当者、任意の並列のまとまり、任意の条件のルールです。

---

ポリシーの構造

ポリシーは次のものを持ちます。

• 領域 - MERCHANT または BUYER。
• 発動の条件 - このポリシーはいつ適用されるか。例：
  • 見積の合計が$50,000超
  • 見積にコレクションXの商品が含まれる
  • バイヤーの顧客タグに enterprise が含まれる
  • （条件なし）- その領域のすべての見積に適用されます。
• 段階 - 順序のある承認の段階の連なりです。各段階は次のものを持ちます。
  • 担当者 - 誰が承認できるか（一人以上のスタッフ、または一つ以上の役割）。
  • 方式 - ALL（すべての担当者の承認が必要）または ANY（一人の承認で段階が完了）。
  • 任意の条件のルール - Xの場合はこの段階を飛ばす。

ポリシーは、少なくとも一つの段階を持ち、有効の切り替えが入っているときに動作します。

実例A - 一段階のマーチャント承認

想定：$10,000を超えるすべての見積で、提案が出ていく前に営業マネージャーの承認が必要。

ポリシー：

• 領域：MERCHANT
• 発動：quote.totalEstimate > 10000
• 段階：
  1. 営業マネージャーの確認 - 担当者：staff:sales-manager-1 - 方式：ANY。

これだけです。営業担当者が$12,000の見積で提案を送信を選ぶと、提案の状態が AWAITING_MERCHANT_APPROVAL に変わります。営業マネージャーにメールとアプリ内の通知が届きます。確認して承認すると、提案が送られます。

却下した場合、担当者には却下の理由とともに通知が届き、編集して再提出できます。

実例B - バイヤー側、多段階、並列

想定：大企業のバイヤーの購買チームが三つの決裁を必要とする。

1. 購買の管理者
2. 経理または法務（並列。先に決裁したほう）
3. CFO

ポリシー：

• 領域：BUYER
• 発動：quote.total > 100000
• 段階：
  1. 購買の管理者の確認 - 担当者：見積ごとに割り当て（既定はバイヤーの会社の購買の役割）- 方式：ANY。
  2. 経理または法務の確認 - parallelGroup: 1 - 担当者：経理と法務 - 方式：ANY（先に承認したほうで完了）。
  3. CFOの最終確認 - 担当者：見積ごとに割り当て - 方式：ANY。

バイヤーが提案で承認を選ぶと、見積の状態が AWAITING_BUYER_APPROVAL に変わります。QuotWayはバイヤーポータルにその連なりを示します。「3段階中の1段階目 - 購買の管理者の確認」といった形です。

実例C - 条件による省略

想定：通常の見積は一つの承認を通るが、特定の優先度の高い顧客の見積は承認をまったく飛ばす。

ポリシー：

• 領域：MERCHANT
• 発動：（条件なし - すべてに適用）
• 段階：
  1. 営業マネージャーの確認 - 担当者：営業マネージャー - 方式：ANY - 条件付き：customer.tags contains "auto-approve" の場合は飛ばす。

自動承認の印により、タグの付いた顧客では段階1が完全に迂回されます。二つの並行するポリシーを保守せずに、小さなVIPの名簿を扱うのに便利です。

ポリシーを編集する

1. 管理画面 → 承認 → 新しいポリシー（または既存のものを開く）。新しいポリシーには、よくある場合のためのひな形が用意されています。そこから始めて調整しても、一から組み立てても構いません。
2. 編集画面は上から下への流れです。いつ（誰が確認するか、発動の条件）→ どの見積（適用範囲と条件）→ 段階 → その後（連なりが承認されたときに何が起きるか）。
3. 流れの上の ＋ ボタンで段階を追加します。各段階について、
   • 承認者を選びます（特定のスタッフ、役割、またはバイヤー側のポリシーではバイヤーの担当者）。
   • 一つ上の段階と並列で実行するには、**「前の段階と同時に実行する」**にチェックを入れます。
   • 条件による省略は**「この段階に条件を追加」の下にあります。制限時間、エスカレーションの宛先、代理承認、理由の記録は、段階の詳細設定**の下にあります。
4. 保存します。
5. 準備ができたらポリシーを有効にします。

ポリシーは複数持てます。優先度の順に評価され、最初に合致したポリシーが適用されます。

受信箱での承認の状態

見積の受信箱には、保留中の各承認の現在の状態が表示されます。

• AWAITING_MERCHANT_APPROVAL - マーチャント側。営業マネージャーの決裁待ちです。
• AWAITING_BUYER_APPROVAL - バイヤー側。バイヤーの連なりが進行中です。

見積の詳細 → 承認のタブを開くと、連なりの全体が見られます。各段階の状態、次の対応が誰にあるか、そして現在の段階での経過時間です。

エスカレーション

承認の段階が7日を超えて ACTIVE のままだと、approval-escalation-check の定期処理が動きます。

• マーチャントにアプリ内の帯が表示されます。「承認が止まっています。確認するか担当を変更してください」。
• 分析のために MerchantEvent('approval_chain_stuck_7d') が記録されます。

担当の手動での変更は、設定 → サポート → 承認の担当者を変更のサポートの道具から行えます。

バイヤーには承認がどう見えるか

BtoBに対応したストアのバイヤーには、顧客アカウントのUI拡張またはホスト型ポータルで承認の連なりが見えます。どちらになるかはストアが使う経路によります。各段階には次のものが表示されます。

• 状態の表示（PENDING / ACTIVE / APPROVED / REJECTED）。
• 担当者の役割の名称（バイヤー自身が連なりの一員でない限り、名前などの個人情報はバイヤーの表示から伏せられます）。
• 現在の閲覧者が作動中の担当者である場合は、操作のボタン。

承認の代理

担当者が休暇に入る場合、設定 → 承認 → 代理から保留中の承認を別のスタッフへ委ねられます。代理は日付の範囲で指定されます。その範囲が終わると、承認は元の担当者へ戻ります。

---

よくある落とし穴

• ポリシーの編集画面が「アップグレードが必要です」で使えない。 LiteまたはStarterをご利用です。承認ワークフローにはProfessional以上が必要です。
• 段階は作動するのに、担当者にメールが届かない。 その担当者のスタッフの記録にメールアドレスがあるか確認してください。ShopifyがスタッフのメールアドレスをAPIから隠すことがあります。トラブルシューティングをご覧ください。
• 条件による省略が一度も作動しない。 条件はターゲティングと同じルールの形式を使います（対象の指定ルールをご覧ください）。条件が見積の実際のデータと一致しているか確認してください。
• 並列のまとまりで両方の担当者が mode: ALL になっている。 それは機能しますが、「まとまりの全員が、順不同で承認しなければならない」という意味になります。多くの場合、求めているのは mode: ANY です。

---

関連記事

• 一部承認と分割変換 - 承認された提案が受け入れられた後に起きることです。
• バイヤーポータルと顧客アカウント - バイヤー側の承認がどこに現れるかです。