マレーシアでAdobe CommerceのBtoB知見を探す：価格設定と見積

BtoBコマースのプロジェクトは、他の何よりも価格設定と見積で失敗します。そしてその理由はほぼ常に同じです。その事業を支配していたルールが、一度も書き出されていなかったからです。ルールは営業部長の頭の中と、表計算ファイルと、「あのお客様にはいつもこうしている」という30年の慣行の中に住んでいました。

Adobe Commerceは、本当に実力のあるBtoB機能群を備えています。企業アカウント、階層価格と顧客グループ別価格、クイックオーダー、購買リスト、そして交渉可能な見積。制約がプラットフォームであることはめったにありません。制約は、非公式な商習慣をシステムが実行できるルールへと変える、地味な作業をやり切るパートナーを見つけることです。そして、そのルールのどれがこの移行を生き延びるべきでないかを言ってくれるパートナーを、です。

本稿では、その能力をどう評価するかを扱います。認定が何を語り、何を語らないのかも含めて。

認定が証明するものと、しないもの

Adobeはプラットフォームについて個人向けの認定資格を運営しており——開発者、アーキテクト、ビジネス実務者の各系統——さらにAdobeとの関係全体に基づく等級を持つパートナープログラムを設けています。どちらもフィルターとしては妥当です。しかしどちらも、そのチームが複雑なBtoB価格エンジンを納めた証拠ではありません。

実務上の区別はこうなります。

有効なのは、これらを組み合わせることです。どの個人がどの認定を持っていて、その個人が自社のプロジェクトに割り当てられるのかを尋ねてください。会ったこともないチームにひもづく会社単位の資格は、宣伝です。そのうえで、BtoBの照会先を2件——直近のものと、少なくとも2年前のもの——求め、古いほうの顧客には公開以降に何が変わったかを尋ねてください。

専門家を最も確実に見分ける質問は、資格とはまったく関係がありません。それはこうです。「40SKUに契約価格があり、500個超で数量割引があり、そのどちらとも併用してはならない販促割引がある顧客を、どうモデル化しますか」。これをやったことのあるチームは、答える前に確認の質問を3つしてきます。やったことのないチームは、プラットフォームが対応していますと答えます。

マレーシアでBtoBパートナーを見極める

上の認定についての質問に加えて、5つの基準が重みの大半を担います。

ログイン付きのBtoCではなく、実証されたBtoBの納品実績。 これらは別の製品です。BtoBには、支払わない購買担当者、買い物をしない承認者、アカウントごとに違う価格、そして200行の表計算ファイルとして届く注文があります。このうちどれを実際に作ったのかを尋ねてください。

自社の商習慣に踏み込んでくる姿勢。 要件定義でパートナーがする最も価値のあることは、矛盾を見つけることです。契約価格が2つある顧客、片方のシステムでは併用でき片方ではできない割引、誰も説明できないルール。価格の要件を議論なしに受け入れるパートナーは、それを読んでいません。

ERP連携の深さ。 BtoBでは通常、契約価格、支払条件、顧客の与信上の識別情報をERPが持ちます。そのため連携は価格エンジンと切り離せません。2つではなく1つの問題として評価してください。

現地の商習慣への理解。 BtoBの請求におけるSSTの扱い、支払条件と与信の慣行、そして顧客が実際にどう発注したいのか。この市場では、いまだにメールかWhatsAppであることが多く、ポータルには初日からそれを置き換えるのではなく、受け止めることが期待されます。

公開後の運用体制。 BtoBのルールは変わります。新しい契約、再交渉された条件、新しい顧客区分。その頻度を支えられないパートナーは、公開当日は正確で、第2四半期にはずれているシステムを残していきます。

独自の価格設定：見た目より難しい理由

Adobe Commerceは複数の価格設定の仕組みを標準で備えており、BtoBの要件の多くは独自開発ではなく、それらの組み合わせです。

• 顧客グループ別価格 — 粗い区分。ディストリビューター、リセラー、小売。
• 階層価格 — 商品ごとの数量割引。必要に応じて顧客グループ別に。
• カタログ価格ルール — カートに入る前に適用される条件付きの調整。
• カート価格ルール — 買い物かご単位の販促と条件付き割引。
• 共有カタログ — 企業ごとに異なる商品「と」異なる価格を見せる。
• 企業ごとの契約価格 — 特定アカウントに対して交渉された料率。

難しいのはこれらのどれか1つではありません。優先順位です。ある顧客が契約価格、数量割引、グループ割引、実施中の販促の条件を同時に満たしたとき、正しい結果はちょうど1つでなければならず、しかもそれはERPが計算する結果であり、営業が約束した結果でもなければなりません。

その優先順位は技術的な判断ではなく商業的な判断であり、BtoB構築に入る時点で最も多く未決定のまま残されるものです。開発が始まる前に、書き出して承認を得てください。そのうえで、それを符号化したテスト一式を必ず用意します。顧客、買い物かご、そして正しい最終価格を組にした実例集を、すべてのデプロイで実行するのです。それがなければ、今後の価格変更はすべて賭けになります。

さらに2つの罠を挙げておきます。価格の可視性はBtoBにおける本物の要件です。定価を見せてはならない顧客、ログイン前に何も見せてはならない顧客、そして自社の料率が機密であることを前提に交渉している顧客がいます。これは表示の切り替えではなく、アクセス制御の設計です。そして丸めと課税基準——明細単位か伝票単位か、SSTをどこで適用するか——は、アーキテクチャ設計の段階で確定させないとERPと1セント違う合計金額を生みます。財務で伝票が却下されるには、それで十分です。

見積は価格の問題ではなく、ワークフローの問題

見積依頼は価格の機能に見えて、承認システムのように振る舞います。重要なのは次の仕組みです。

• 誰が依頼できるか。 企業アカウント内のどの役割が、そもそも見積を起こせるのか。
• 次に何が起きるか。 どの営業担当が受け取り、その権限は何で、何を調整してよいのか。明細単価、数量、送料、支払条件、有効期限。
• 承認のしきい値。 一定の限度を超える割引には第2の承認者を要する。しかもその限度は、固定値ではなく設定可能であること。
• 交渉の履歴。 双方が、何を提示し何を差し戻したかを見られる必要があり、後になって財務が、なぜその価格だったのかを知る必要があります。
• 有効期限と受注化。 見積は期日まで有効で、その後は注文になります。そして注文は、再計算するのではなく見積時の価格を運ばなければなりません。
• 買い手側の承認。 多くのBtoB顧客は自社内の決裁を持っています。それを受け止めずに受注化する見積は、自社ではなく顧客の組織の中で却下されます。

Adobe Commerceは交渉可能な見積を標準で備えており、多くの企業にとっては標準のフローと設定で十分です。独自開発が本当にコストに見合うのは、変わった承認の構造、営業チームが日常的に使っているCRMとの連携、そしてERP自身の契約レコードと整合させなければならない見積ロジックです。ここで即座に独自開発に手を伸ばすパートナーは、標準の道筋を試していません。

BtoBのその他の領域

注目を集めるのは価格と見積ですが、ポータルが実際に使われるかどうかを決めるのは次のものです。

企業アカウントと役割。 1つのアカウントの下に、異なる権限を持つ複数の利用者。発注する購買担当、承認する管理者、そして請求書は見るが商品ページは決して見ない経理担当。

購買承認のワークフロー。 顧客自身の社内ルールを、こちらのシステムで実行する。それがあってはじめて、顧客はポータルから出ずに購入できます。

クイックオーダーと購買リスト。 実務上、最もよく使われるBtoB機能であり、最も過小評価されている機能です。自分のSKUを把握している再訪の購買担当は、カタログを閲覧したいのではなく、リストを貼り付けたいのです。購買リストは、繰り返しの発注を1つの操作に変えます。どちらもAdobe Commerceの標準機能です。

掛け払いと与信限度。 BtoBの顧客は取引条件に従って支払います。つまり、与信限度、注文時の利用可能与信の確認、そして限度を超える注文が来たときにどうするかの判断——止めるのか、承認保留にするのか、印をつけて通すのか——が必要です。数字を持つのは通常ERPなので、これは連携の問題になります。

注文履歴と再注文を、利用者単位ではなく企業単位で。 同僚の注文が見えて、繰り返せるようにします。

BtoBとBtoCを共通の基盤で。 マレーシアの多くのブランドは両方で販売しています。Adobe Commerceは共有カタログの上のウェブサイトとストアビューでこれを扱いますが、税の表示、価格の可視性、購入手続きのルールは対象ごとに異なり、それは発見するのではなく設計すべきものです。

BridziaのAdobe Commerceの取り組みは、企業アカウント、階層価格、クイックオーダーと購買リスト、そして標準機能では届かない独自の価格・見積ロジックのモジュール開発を含め、BtoBコマースをカバーしています。

実装の進め方

うまくいく順序は次のとおりです。

1. 何よりも先にルールの掘り起こし。 価格と承認のルールを、それを抱えている人たちから引き出し、実例として書き出し、承認を得ます。矛盾は出るものと思ってください。それを解決することが成果物です。
2. 優先順位を決め、テストとして符号化する。 その後のすべての変更は、これに照らして測られます。
3. ERP連携を細い1本で検証する。 契約価格を持つ顧客1件、注文1件を、正しい伝票まで通します。
4. 人が実際に使う2つの機能を軸にポータルを作る。 デモ映えする機能より先に、クイックオーダーと再注文を。
5. 実際のアカウントで試験導入する。 協力的な顧客3〜4社に実際の発注で使ってもらうほうが、どんなUATの台本より多くを見つけます。
6. 新規契約と料率変更の運用サイクルを、公開前に決める。 最初の1件が来てからではありません。

期間もこれを反映します。標準的なBtoCの再構築は、連携の複雑さにより3〜5か月です。独自の見積機能と価格ロジックを伴うBtoB構築はさらに長くなり、その追加分はフロントエンドではなく、ルールの掘り起こしと連携にあります。

よくある質問

Adobe CommerceはBtoBに向いているか。

向いています。企業アカウント、共有カタログ、階層価格と顧客グループ別価格、クイックオーダー、購買リスト、交渉可能な見積が標準で備わっており、共通の基盤の上でBtoBとBtoCを異なるルールのもとに扱えます。価格ロジックとERP連携が難所であるときにこそ、その複雑さに見合う価値を発揮します。

BtoB構築には認定を持つAdobe Commerceパートナーが必要か。

認定は妥当なフィルターですが、それだけでは不十分です。認定を持つどの個人が自社のプロジェクトに入るのかを尋ね、それを納品済みのBtoB案件——顧客ログイン付きのBtoCではなく、企業アカウント、見積、契約価格そのもの——の照会と組み合わせてください。

Adobe Commerceは顧客ごとの契約価格を扱えるか。

扱えます。顧客グループ、共有カタログ、階層価格、企業ごとの契約価格の組み合わせで、通常はそれらを持つERPから同期します。設計上の仕事は、どの仕組みがどのルールを担うのか、そして複数が同時に当てはまったときに何が優先されるのかを決めることです。

Adobe CommerceのBtoB実装にはどれくらいかかるのか。

同等のBtoC構築より長くかかります。追加時間の大半は開発ではなく、ルールの掘り起こしとERP連携です。価格ルールが書き出される前に出された見積は、店舗側だけの見積です。

見積は独自開発すべきか、標準機能を使うべきか。

まず標準の交渉可能な見積と設定から始めてください。独自開発を正当化するのは、変わった承認の構造、CRM連携、あるいはERPの契約レコードと整合させなければならない見積ロジックであって、作り込みへの好みではありません。

どこから始めるか

誰かに相談する前に、自社の価格ルールを実例として書き出してください。顧客、買い物かご、正しい価格の組で。この作業が矛盾を見つけ、その矛盾こそがこのプロジェクトの実際のスコープです。その文書に真剣に向き合うパートナーは、どんな資格よりも重要な能力を示しています。

Bridziaは14年にわたり、クアラルンプールからアジア各地の小売・FMCGブランド向けにAdobe Commerce（Magento）プラットフォームを構築してきました。BtoBコマースと、独自の価格・見積ロジックも含みます。BtoB構築を検討中で、ルールをきちんと掘り下げてほしい方は、プロジェクトについてお聞かせください。