取引先に会員登録をしてもらったものの、営業担当が案内した価格と画面の価格が違う。見積を頼んだだけなのに、届いたメールには「注文完了」と書かれている。既存の法人取引をECへ移すときは、商品をカートに入れる機能だけでは、こうした行き違いを防げません。
大阪でECサイト制作を検討する卸売会社の責任者に向けて、会員の状態、適用する価格、見積と注文の進み方を整理します。地域によって変わる取引慣行を想定した記事ではありません。以下の状態表と場面は架空の設計例であり、自社で承認した販売条件に合わせて書き換えるための材料です。
「会員になった」を、何ができる状態かまで説明する
登録フォームの送信、メールアドレスの確認、取引先としての承認は、同じ出来事ではありません。入力が終わっただけで既存取引先と同じ価格を見せてよいか、掛取引の注文まで受け付けてよいかを、Web担当者が推測して決めないようにします。営業・経理など、社内で条件を決める担当者と確認します。
最初に、現在の取引先をEC上のどの会社に結び付けるかを決めます。同じ会社でも支店や事業部で条件が異なるなら、価格を会社全体に付けるのか、拠点ごとに付けるのかが設計に影響します。登録者が選んだ会社名だけで条件を引き継がせず、既存の取引先情報との照合を誰が行うかまで整理します。
承認待ちの画面には、今できることと次に起きることを書きます。「登録が完了しました」だけでは、注文できない理由が伝わりません。たとえば「申請を受け付けました。取引条件の確認後に利用開始をご案内します」とすれば、入力完了と利用開始を区別できます。回答時期は実際に守れる案内にします。
既存の取引先にも、この段階は必要です。電話で取引があることと、登録した担当者がその会社の注文を行えることは別だからです。申請者の確認方法は自社で定め、サイトには必要な手順だけを示します。会員承認を、与信の承認や支払方法の承認まで終わった印として扱わないことが要点です。
買い手の社内承認が必要な場合は、売り手による会員承認とは別の流れとして扱います。担当者が明細を作り、上司が発注を認める仕組みまで必要なのか、承認済みの発注だけをECへ入力するのかを確認します。両方を画面で「承認待ち」と呼ぶと、誰の操作を待っているか分からなくなります。「当社で利用申請を確認中」「お客様社内の発注承認待ち」など、承認する側が伝わる名前にします。
会員状態と価格・見積・注文を一枚の表にする
「ログインしているか」だけを条件にすると、承認待ち、価格設定前、取引停止中の利用者を同じ扱いにしてしまいます。画面を描く前に、状態ごとに価格欄と操作ボタンの組合せを決めます。以下は、承認制の卸売ECを想定した例です。すべてのサイトにこの状態数が必要という意味ではありません。
| 会員の状態 | 価格欄の表示例 | 見積の受付 | 注文の扱い |
|---|---|---|---|
| 未ログイン | 法人価格は利用開始後に案内 | 公開窓口から取引相談 | 会員取引の注文は不可 |
| 申請済み・承認待ち | 条件確認中と表示 | 相談受付の範囲を明示 | 利用開始の案内を待つ |
| 承認済み・価格未設定 | 価格確認が必要と表示 | 対象商品を指定して依頼 | 金額未確定のまま送信させない |
| 取引中・価格設定済み | 対象会社・拠点の適用価格 | 個別条件の商品は見積へ | 注文可能な明細だけ手続きへ |
| 利用停止・条件見直し中 | 自社方針に沿う制限表示 | 既存の相談窓口へ案内 | 新規注文を止める範囲を設定 |
価格を表示しない欄は、空白やゼロ円で代用せず、理由を読める形にします。特に価格未設定の商品をゼロ円として合計すると、利用者は無料で注文できると思うかもしれません。「価格確認が必要」と示し、見積依頼へ進む商品なのか、設定完了を待つ商品なのかを案内します。
表の右端は、会員の状態だけで最終判断しません。取引中でも、個別仕様の商品や価格が決まっていない明細は見積対象になるためです。「この会員は注文できる」と「この商品をこの条件で注文できる」を重ねて判定します。見積対象と通常注文の商品が同じカートに入ったときの扱いも必要です。
混在するカートでは、全体を見積依頼として送るか、通常注文の明細だけ先に進めるかを決めます。後者なら、送信前に今回注文する商品と見積を依頼する商品を並べ、送料や納品の扱いも説明します。どちらの方法でも、総額だけを表示して全商品が注文済みに見える結果画面を作らないことが大切です。
停止の設計では、新しい注文を止めることと、過去の取引を確認することを区別します。必要な記録まで突然見られなくならないよう、閲覧と操作の範囲を社内で決めます。理由の詳しい説明を誰でも見える画面へ出すのではなく、利用者向けの案内と担当者が管理する情報を整理します。
会員価格は「誰の、何単位の価格か」をそろえる
会員価格という名前でも、一律の割引、取引先グループごとの単価、会社ごとの個別価格など、実際の持ち方は異なります。まず代表的な商品で、どの取引先にどの価格を適用しているかを社内で整理します。画面に表示する数字の出所を決めずに、見た目だけを作り始めないことが大切です。
次に、単価の対象をそろえます。一個の価格なのか、一箱の価格なのか、数量によって変わるのかを、数量入力と同じ場所で読めるようにします。税や送料の扱いも含め、商品ページ、カート、確認画面で同じ条件を示します。途中の画面だけ別の会員区分の価格が出る状態は、公開前に解消します。
担当者が複数拠点を扱う場合は、いまどの拠点の条件で操作しているかも表示します。拠点を切り替えた後、カートに残る商品の価格や支払方法をどう扱うかは確認が必要です。切替前の条件が使えないなら、変わった項目を知らせて再確認へ進めます。所属会社名をヘッダーに出すだけで、明細も正しく切り替わったと判断しないようにします。
複数の価格ルールが当てはまる場合は、優先する条件を明確にします。個別価格に加えて会員割引やクーポンが重なるのか、特定商品は対象外なのかを確認します。値引きの運用を新たに勧めるためではなく、現在合意している条件がECの計算で変わらないようにするための確認です。
未設定や更新失敗のときに何を表示するかも、通常価格とセットで決めます。別の会員向け価格や過去の価格へ無条件に戻すと、利用者には正しい金額に見えてしまいます。購入手続きを止めて担当者に確認するなど、自社が採る方法を決め、金額が出ない理由と連絡先を画面で伝えます。
見積依頼から注文へ移る場所を明確にする
見積機能には、表示中の金額から書類を出すものと、担当者が条件を確認して回答するものがあります。前者を導入しただけで、個別条件の相談や営業側の承認まで扱えるとは限りません。自社でいう「見積注文」が何を意味するか、依頼、回答、買い手の確認、注文受付という段階に直して考えます。
担当者が回答する架空例なら、送信直後の画面は「見積依頼を受け付けました」とし、依頼番号と回答方法を示します。その時点で注文や出荷が決まったような文言は使いません。社内で見る一覧にも「回答待ち」を表示し、売上の確定した注文と取り違えずに扱えるようにします。
回答には、対象の商品と数量、単価、送料等の扱い、有効期限、次に必要な操作をまとめます。買い手が条件を受け入れて注文へ進むなら、どの見積に基づく手続きかを確認画面で示します。実際に契約が成立する時点の説明は、自社の契約条件に合わせて確認し、ボタン名だけで決めないようにします。
回答を修正するときは、以前の回答と新しい回答を識別できるようにします。同じ番号を使うなら改訂の表示を設け、注文時にはどの回答を参照したかを記録します。メールに添付した見積と会員画面の内容が異なる場合も、どちらで手続きを進めるかを明示します。古いメールから開いた場合に、更新後の条件を読み直せる案内が役立ちます。
見積後に数量や納品条件を変更した場合、そのまま同じ条件で進めるのか、再回答が必要なのかを定めます。期限切れの見積も同様です。「期限が過ぎています。条件の再確認を依頼してください」といった案内を用意し、古い回答を現在も使える価格のように残さないことが必要です。
価格の維持と在庫の確保も別々に扱います。見積金額を保存していても、その数量を取り置いているとは限りません。取り置きの有無、納期をいつ回答するかを自社の運用に合わせて示します。画面の「見積済み」という短い表示だけで、価格・在庫・納期のすべてが確定したと受け取られないようにします。
機能名ではなく、状態表を使ってEC基盤を確かめる
候補サービスを比べるときは、「BtoB対応」「会員機能あり」という見出しだけで決めず、表の各行を実現できるかを確かめます。会社や拠点への価格の割当、承認待ちの表示、注文前の確認などが、標準機能、追加契約、個別対応のどこに当たるかを整理します。
makeshopの公式資料では、承認制の会員ショップと、取引先グループ別価格や見積書発行の機能が区分されています。また、見積書から購入する機能と、個別の承認の流れを作る対応も同じものとしては案内されていません。必要な動作を伝えたうえで、対象プランやオプションを確認する材料になります。
Shopifyの公式資料には、会社の拠点に応じた価格等の設定や、注文を下書きとして受けて確認する仕組みが示されています。下書きの作り方によって価格が固定される初期状態も異なります。これをすべてのECへ一般化せず、採用する構成で、価格更新後の見積がどう動くかを実際に試すことが必要です。
支払方法については、画面で選べることと、決済サービスを利用できることを混同しないようにします。既存の掛取引を使うのか、外部の法人向け決済を使うのかで確認先が変わります。契約や利用条件は担当者が確認し、制作側には画面へ反映する承認済みの条件を渡します。
公開前は、注文できない状態も最後まで試す
受入テストでは、未ログイン、承認待ち、価格未設定、条件の違う二つの取引先を用意します。同じ商品を開き、表で決めた価格欄とボタンになるかを順に確認します。利用者向けの画面だけでなく、社内に届く記録や通知にも、会員・価格・受付状態が正しく引き継がれるかを照合します。
見積依頼は、送信、回答、注文への移行、期限切れ、回答後の数量変更を試します。画面とメールの両方で、見積依頼を注文完了と呼んでいないかを読みます。回答前の依頼が誤って注文処理へ回らないこと、同じ見積から重ねて手続きした場合の扱いも確認対象です。
条件を変える前から開いていた画面も残して試してください。承認状態や価格を更新した後に、古い画面から操作したときの結果を確認できます。ボタンを隠しただけで制限が完成したと判断せず、許可しない操作を受け付けない仕組みまで、制作担当と検証します。
最初の相談には、会員状態の表と、通常注文・個別見積の代表例を持ち寄ると具体的です。全商品の詳細がそろう前でも、価格を決める人、見積に答える人、設定を更新する人が分かれば、必要な画面と社内作業を結び付けられます。EC全体の費用や体制を整理する際は、ECサイト制作の要件整理ガイドも参考になります。
参考・出典
- makeshop「makeshop BtoBについて」：会員制、グループ別価格、見積書発行、個別対応の区分を参照。
- Shopify「B2Bの機能」：会社・拠点、カタログ、注文確認などの機能と利用範囲を参照。
- Shopify「下書き注文を使用したB2Bの注文の作成」：確認用の下書きと価格固定の説明を参照。
公式資料の確認日：2026年9月21日。会員画面へのログインや実注文の検証は行っていません。本文の表・図は設計例で、各サービスの完成画面や特定企業の取引条件ではありません。導入時は最新の契約・機能を確認してください。
