B2Bカタログに注文機能、顧客別価格、在庫連携は必要ですか？

顧客が表示された情報と条件に基づいて有意義な購入判断をできるなら、B2Bカタログには注文機能が必要です。購入のたびにスタッフが仕様、価格、納期を調整するなら、明確な見積もり依頼サービスのほうが適しているかもしれません。

顧客別価格、購入可能な商品、梱包数量、在庫情報は、それぞれ異なる課題に対応します。まず顧客に何をしてもらいたいかを決め、その後、既存のECプラットフォームで対応できる範囲を確認します。

リピーターの購入を追ってみる

架空の卸売業者が清掃用品を販売しているとします。ホテルグループの購買担当者は、北支店向けにいつも同じ商品を注文します。北支店には特定サイズのボトルについて合意済み価格があり、卸売業者はその商品を6本入りで販売しています。

担当者は18本を希望しています。また、現在在庫切れの商品も必要です。使いやすい注文サービスなら、通常の購入を完了でき、例外がどう扱われるかも理解できます。

まずアカウントを確認します。誰がログインしていて、どの会社、どの支店のために購入しているのでしょうか。北支店に割り当てられた商品範囲と合意済み価格が、意図した設定に従って表示される必要があります。別の支店の担当者には異なる条件が適用されるかもしれません。未ログインの訪問者には、公開カタログや公開価格が表示される場合があります。

Shopifyは、こうした違いを示す現行の例です。B2Bカタログで商品と価格を定義できますが、機能はプランによって異なります。割り当てのガイドからは、該当する会社所在地と市場条件が重要な理由も分かります。ログインだけでは、すべての訪問者に意図した価格が表示される保証にはなりません。

数量と価格の意味をそろえる

この例では、ページに価格が1本あたりか1パックあたりか、どのボトルサイズが対象か、数量欄が本数とパック数のどちらを数えるかを明記します。18本は3パックです。顧客は送信前にそれを理解できる必要があります。

最小数量、注文単位の刻み、まとめ買い割引は、それぞれ別の質問に答えるものです。Shopifyの数量ルールの資料では、これらを区別し、商品バリエーションに適用しています。あるボトルサイズのルールが、複数サイズを組み合わせた注文にも自動的に適用されるわけではありません。

情報の管理元は複数に分かれることがあります。商品情報はECシステム、交渉済み価格は営業システム、在庫は倉庫ソフトで管理しているかもしれません。各情報の正しい参照元と、不一致を解決する担当者を明確にしましょう。商品、単位、顧客の意味がシステム間で一致して初めて、連携が役立ちます。

送信ボタンが何を意味するか決める

担当者は注文の最後まで進みました。送信が業務上何を意味するかを決めてください。スタッフの確認依頼を送るのでしょうか。それとも会社の合意済み条件に基づいて注文を受諾するのでしょうか。在庫をいつ引き当て、いつ出荷準備を始めるのでしょうか。ボタンの文言、確認メッセージ、スタッフ画面にこれらの判断を反映します。

この例では、卸売業者が受諾前にスタッフ確認を行うとします。担当者が18本の依頼を送ると、依頼番号と、スタッフが注文と配送を確認するという明確なメッセージが届きます。スタッフ画面には対象の支店、商品、数量、価格がまとまって表示されます。支払い条件は顧客との合意どおりです。ウェブサイトが新しい掛取引条件を黙って承認することはありません。

在庫切れ商品には別途対応が必要です。スタッフは確認済みの後日、合意した代替品、または依頼からの削除を提案できます。どの商品が判断待ちで、どの商品が確定したのかを担当者が理解できるようにします。黙って商品を差し替えたり、依頼受付を配送の約束として扱ったりしないでください。

約束を支える在庫情報を使う

倉庫の総数は参考になりますが、他の注文に引き当て済み、または取り置き済みの商品が含まれることがあります。たとえばShopifyでは、手持ち、販売可能、確保済み、予約済みの数量を区別しています。在庫モデルではさらに商品と場所ごとの数量を追跡します。これらは特定のサービスの定義なので、実際に使用しているシステムと照らし合わせてください。

ホテルの担当者にとって重要なのは、卸売業者が供給元の拠点から18本を用意できるかどうかです。在庫情報がない場合や連携が利用できない場合に、ウェブサイトが何を表示できるかを決めましょう。在庫や納期を約束せず、見積もり依頼だけは受け付ける方法もあります。

購入を完了できる最小限のサービスを選ぶ

購入前に商品を探し、担当者と話す必要があるなら、情報提供型のカタログで十分かもしれません。見積もり依頼型なら、選んだ商品と数量をそのまま相談に引き継げるため、顧客が同じ買い物かごを説明し直す手間を省けます。

リピーターが既定の条件で注文できるなら、候補のECプラットフォームとエディションで一連の流れを実演してもらいましょう。カタログ、アカウント割り当て、価格、数量ルール、注文確認、在庫切れ商品の扱いを確認します。既存の設定だけで対応できる場合もあります。

承認済みの顧客別価格をスタッフが管理するシステムから取り込むなど、具体的なルールや情報源が欠けている場合に、拡張機能や連携を検討します。継続的な保守やプラットフォーム更新後の対応と、削減できる作業を比べてください。

独自の注文業務が重要で、利用可能な設定や拡張機能で十分に対応できないなら、カスタムプラットフォームが候補になります。ルールの保守、連携の運用、将来のサービス変更も含めて比較しましょう。一般的なカタログに連携が一つ足りない場合と、独自の注文プロセスを持つ企業では、必要な範囲が異なります。

必要な顧客の購入体験に合わせたECの支援ができます。通常のリピート購入と一つの例外を持ち寄り、購入者とスタッフが実際に完了させたいことを軸に話しましょう。

契約する前に全体の流れを見る

対応している独立したテスト環境で、架空の顧客、価格、商品を使い、実際の注文、顧客への通知、決済、出荷を停止します。ホテルの担当者が通常の依頼を送信し、誤ったパック数量を入力し、在庫切れ商品に出会う流れを確認します。次に別の支店、割り当て対象外のアカウント、未ログインの訪問者でも試し、商品と価格の表示を確かめます。

依頼がスタッフ画面に表示されるところから、購入者への確認までを追います。価格の情報源が一致しない場合や在庫連携が停止した場合の動きも尋ねましょう。実演で確認できたことと、まだ検証できていないことを記録します。

これで具体的に決められます。情報提供型カタログを維持する、見積もり依頼を追加する、注文機能を設定する、不足する情報源を連携する、または残りの独自開発を依頼する、という選択です。提供する意思のある購入体験と、スタッフが対応できる例外を支える方法を選びましょう。

B2B注文を追加する前の質問