承認ワークフロー

読了時間： 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 - バイヤー側。バイヤーの連なりが進行中です。

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

エスカレーション

Enterpriseでは、段階の詳細設定で制限時間を設けられます。段階がその時間を過ぎても決裁されないと、1時間ごとに動く approval-escalation-check の定期処理が、選んでおいた対応を行います。催促を送る、段階を別の人へ付け替える、または自動で承認か却下する、のいずれかです。自動の承認や却下は、システムによる決裁として、期限切れである旨の理由とともに記録されます。

開始から7日たっても完了していない連なりは、分析のために MerchantEvent('approval_chain_stuck_7d') として記録されます。

段階を手動で動かすには、その承認者が見積から段階を代理に委ねます。承認の代理をご覧ください。

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

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

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

承認の代理

段階で許可されている場合（段階の詳細設定にある Allow the approver to delegate this step - Enterprise）、対応できない承認者は、見積からその段階を別の有効なスタッフへ委ねられます。メモを添えることもできます。バイヤー側の承認者は、メールアドレスで別の担当者へ委ねます。代理は期間ではなく段階ごとです。代理人がその段階の決裁を引き継ぎ、元の承認者はその段階を決裁できなくなります。引き継ぎは段階の決裁とともに記録され、自動で元の承認者へ戻ることはありません。

---

よくある落とし穴

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

---

関連記事

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