仕組み

このページでは、バイヤーがSubmitをクリックしてから、Shopifyで購入に使用する会社が作成されるまで、1件の申請がSami B2B Onboardingでどのように処理されるかを説明します。申請が今どの段階にあるのか、またアプリが次に何を行うのかを把握するためにお読みください。

流れの概要

段階	処理内容	確認できる場所
1. 送信	バイヤーがフォームに入力して送信します。アプリは保存する前に内容を確認します。	ストアフロント
2. 最初の処理	メールが送信され、税務IDチェック、重複チェック、ルールが実行されます。	申請のタイムライン
3. 審査	チームが承認するか、追加情報をリクエストするか、拒否します。	Companies › Applications
4. 承認	アプリが、設定した条件に従って、Shopifyに顧客と会社を作成します。	Shopify管理画面とタイムライン
5. フォローアップ	バイヤーが質問に回答するか、申請が終了します。	申請のステータス

1. バイヤーが送信する

バイヤーはフォームのページを開き、ページごとに入力してSubmitをクリックします。ファイルは、選択した時点で非公開のストレージにアップロードされます。

申請が保存される前に、アプリは内容を確認します。確認に失敗した場合、バイヤーには理由が表示され、何も保存されません。

確認項目	実行されるタイミング	失敗した場合にバイヤーに表示される内容
ログイン	Account requiredがLog in first, then applyの場合	フォームの代わりにログインのプロンプト
アカウントごとに1件の申請	バイヤーがログインしている場合	フォームの代わりに、申請の現在の状況
Captcha	フォームにCaptchaがあり、バイヤーがログインしていない場合	“That captcha check failed. Please try again.”
回答	常に実行	未入力または誤りのあるボックスの下にメッセージ。ルールによって必須になったフィールドも対象です。
税務IDの形式	税務IDチェックがBlock the submit and show the errorに設定されている場合	バイヤーの国で“That tax ID doesn’t look valid for”
会社の重複	Duplicate companiesがBlock the submit and tell the buyer to contact salesに設定されている場合	“Your company already has an account with us. Contact us and we’ll add you to it.”

ルールによって非表示になったフィールドに入力された回答は破棄されるため、バイヤーに質問した内容のみが届きます。

確認に通過すると、申請は独自のリファレンス付きでPendingとして保存されます。書類の種類にマッピングされたフィールドからのアップロードは、Documentsに保存されます。バイヤーにはサンクス画面が表示されるか、指定したページにリダイレクトされます。この時点では、Shopifyには何も書き込まれません。

2. アプリによる最初の処理

送信の直後に、アプリはバックグラウンドで次のステップを順に実行します。ほとんどのステップは、申請のタイムラインにエントリを残します。

1. Default reviewer. Settings › ReviewersでDefault reviewerを選択している場合、申請はその担当者に割り当てられます。
2. Application received. バイヤーにApplication receivedメールが送信され、チームにはNew applicationが送信されます。Shopify FlowでApplication receivedトリガーが実行され、送信内容を送るよう設定されたインテグレーションに申請が送信されます。
3. Tax ID check. オンの場合、アプリは税務IDをチェックします。Reject automatically and email the buyerでは、チェックに失敗した番号があると、ここで申請が拒否され、ルールは実行されません。到達できないレジストリが判定を下すことはありません。
4. Duplicate check. Settings › Application rules › Duplicate companiesが、申請にフラグを付けるか、バイヤーの追加を提案するように設定されている場合、アプリは、そこで選択した一致条件を使って、申請を既存の会社やほかの申請と比較します。一致した場合は、タイムラインに会社名が表示され、ルールは判定を行わずに申請を担当者に任せます。
5. Rules. Liveのルールが上から順に実行され、最初に一致したルールが判定を行います。プリセットでの承認、拒否、情報のリクエスト、審査担当者への割り当て、審査対象としてのフラグ付けのいずれかです。承認に必須の回答が空の間は、ルールで承認できません。

税務IDチェック、申請ルール、申請を判定するルールを参照してください。

3. チームが審査する

判定が必要な申請は、Companies › ApplicationsのNeeds your actionビューに表示されます。管理者と審査担当者は、どちらも判定できます。各申請では、準備状況のチェックにReady to approveと表示されるか、会社名が未入力であることや、承認前にフォームが必須とする回答など、まだ対応が必要な項目が一覧表示されます。

判定は次の3種類です。

• Approve：アプリが、以下に説明するとおり、顧客と会社を作成します。申請を承認するを参照してください。
• Request info：バイヤーに追加情報をリクエストします。追加情報をリクエストするを参照してください。
• Reject：申請を却下します。申請を拒否するを参照してください。

Shopify Flowのワークフローでも、アプリのアクションを使って同じ3種類の判定を行えます。

4. 承認時にShopifyに書き込まれる内容

承認されるまで、申請の内容はShopifyに一切反映されません。承認は、担当者、ルール、Flowワークフローのいずれが承認した場合も、同じように実行されます。各ステップには数秒かかり、それぞれがタイムラインに記録されます。Shopifyが拒否した場合は、その理由も記録されます。

1. Customer. アプリは、バイヤーのメールアドレスでShopifyの顧客を検索するか、マッピングされた回答から顧客を作成します。既存の顧客の情報を保持するか更新するかは、フォームの設定によります。プリセットの顧客タグが追加されます。
2. Approved flag. 顧客のB2B approvedフィールドがオンになり、b2b-approvedタグが追加されます。ストアアクセスルールとチェックアウトのブロックが参照するのは、タグではなくこのフィールドです。
3. Company. アプリはShopifyに会社を作成します。マッピングされた住所のロケーション、メインの担当者としてのバイヤー、マッピングされたメタフィールドが含まれます。これにはB2Bを含むプランが必要です。
4. Terms. ロケーションに、承認の条件が設定されます。カタログ、支払い条件、デポジット、配送先住所のルール、注文の送信、バイヤーの税務IDを含む税設定、バイヤーの担当者ロールです。割り当てられたスタッフがロケーションに追加されます。
5. Company in the app. 会社がCompaniesタブにActiveとして表示されます。申請に割り当てられていた担当者が、営業担当者になります。
6. Email and events. 会社が作成された場合、Shopify FlowでCompany createdトリガーが実行されます。その後、バイヤーにAccount approvedメールが送信され、Application approvedトリガーが実行されます。KlaviyoやWebhookなど、承認を送信するよう設定されたインテグレーションにも申請が送信されます。ただし、ルールが承認した場合を除きます。

B2Bを含まないプランでは、ステップ3と4は実行されません。顧客は引き続き作成されて承認され、承認の税設定が顧客に適用されますが、会社はアプリ内にのみ保持されます。

代わりに、すでにある会社にバイヤーを追加した場合は、バイヤーはその会社の担当者になり、2つ目の会社は作成されません。

承認の各ステップは、結果とともにタイムラインにエントリとして残ります。

5. リクエスト、再送信、終了

追加情報をリクエストした場合。 申請はNeeds infoに移行し、バイヤーにMore information neededメールが送信されます。メール内のリンクを開くと、回答が入力済みの状態でフォームのページが開きます。バイヤーが送信すると、申請はResubmittedになり、チームにBuyer resubmittedが送信されます。

再送信では、最初の処理と同じチェックとルールが再び実行されますが、1つ違いがあります。チームの担当者が追加情報をリクエストした場合、回答はその担当者に戻ります。税務IDチェックとルールは確認した内容を記録しますが、承認、拒否、再リクエストは行いません。ルールまたはFlowワークフローがリクエストした場合は、自動化によって再び判定されることがあります。

拒否した場合。 バイヤーが申請を変更して再送信できるようにするには、Let them update it and send it againを選択します。この場合、申請はResubmittedになります。申請を終了するには、Close the applicationを選択します。Application declinedメールは初期状態でオフになっています。拒否したバイヤーに連絡したい場合は、フォームのEmailセクションでオンにしてください。

バイヤーが回答しない場合。 Settings › Application rules › Data retentionで設定した期間が経過すると、バイヤーの回答待ちの申請はAbandonedとして終了し、リンクは無効になります。

承認後。 会社の条件は、後から変更できます。アプリは新しい条件をShopifyの会社のロケーションに適用し、メールは送信しません。

ステータス

ステータス	意味	次に起こること
Pending	新しい申請です。	チームまたはルールが判定します。
Needs info	あなた、ルール、またはFlowワークフローが、バイヤーに追加情報をリクエストしました。	バイヤーが回答するか、Abandonedとして終了します。
Resubmitted	バイヤーが申請を再送信しました。	チームが判定します。自動化がリクエストした場合は自動化が判定します。
Approved	担当者またはFlowワークフローが承認しました。	バイヤーは卸売の条件で購入できます。
ApprovedとAuto-applied	いずれかのルールが承認しました。	Approvedと同じです。
Rejected	担当者、ルール、税務IDチェック、またはFlowワークフローが却下しました。	再送信できるのは、許可した場合のみです。
Abandoned	バイヤーがリクエストに回答しませんでした。	何も起こりません。保持スケジュールに従って削除されます。

イベントと送信されるメール

上記の各ステップでイベントが発生します。Application received、Application revised、Revision requested、Application approved、Application rejected、Company createdです。各イベントには、Automation › Automationsに1つのスイッチがあります。このスイッチは、イベントが送信するメールと、同じ名前のShopify Flowトリガーを制御します。各申請メールにも、フォームビルダーのEmailセクションに専用のスイッチがあり、両方がオンの場合にのみ送信されます。各イベントが送信するメールについては、オートメーションとShopify Flowを参照してください。

次のステップ

• 申請 — 対応待ちの申請を見つけて判定します。
• 回答をShopifyにマッピングする — 承認時に顧客と会社に書き込まれる内容を選択します。
• オートメーション — プリセット、ルール、Flowに作業の一部を任せます。
• 権限とデータ — アプリが読み取り、書き込み、保存する内容を確認します。