在马来西亚寻找 Adobe Commerce B2B 专家：定制价格与报价

B2B 商务项目栽在价格与报价上的次数，远多于栽在其他任何环节上，而原因几乎总是同一个：支配这门生意的那些规则，从来没有被写下来过。它们存在于某位销售总监的脑子里、一份电子表格里，以及三十年来「我们对那个客户一向如此」的惯例里。

Adobe Commerce 拥有一套确实有实力的 B2B 功能——公司账户、阶梯与客户组价格、快速订购、申购单，以及可协商报价。平台很少是约束所在。约束在于找到一个合作伙伴，愿意去做那件不光鲜的工作：把非正式的商业惯例，转化成系统可以执行的规则；并且愿意告诉您，其中哪些规则不应该在这次转换中活下来。

本文讲的就是如何评估这项能力，包括认证能告诉您什么、又不能告诉您什么。

认证能证明什么，不能证明什么

Adobe 为这个平台设有个人认证——开发者、架构师与业务从业者三条路径——并维护一套依据企业与 Adobe 整体关系分级的合作伙伴计划。两者都是合理的筛选条件，但都不是「这支团队交付过一套复杂 B2B 定价引擎」的证据。

实务上的区别在于：

有用的做法是把它们组合起来。请询问哪些具名人员持有哪些认证，以及这些人是否被分配到您的项目上——一份挂在您永远见不到的团队身上的企业级资质，只是营销。然后索取两份 B2B 客户推荐，一份是近期的、一份至少是两年前的，并问那位较早的客户：自上线以来有什么变化。

最能可靠区分出专家的那个问题，其实与资质毫无关系。它是：「请带我走一遍：一位客户在 40 个 SKU 上有合约价，在 500 件以上有数量折扣，还有一项不得与前两者叠加的促销折扣，您会怎么建模？」 做过这件事的团队，会在回答之前先问您三个澄清性的问题。没做过的团队，会说这个平台支持。

如何在马来西亚考察一家 B2B 合作伙伴

除了上面关于认证的问题之外，有五条标准承载了大部分权重：

有实打实的 B2B 交付经验，而不是加了登录功能的 B2C 交付。 这是两种不同的产品。B2B 里有不付款的采购者、不逛商品的审批人、因账户而异的价格，以及以 200 行电子表格形式抵达的订单。请问清楚这支团队究竟构建过其中哪些。

愿意质询您的商业规则。 合作伙伴在需求梳理阶段做的最有价值的事，就是找出矛盾之处——那位有两个合约价的客户、那项在一个系统里叠加而在另一个系统里不叠加的折扣、那条没人解释得清的规则。一个不加争辩就接受您定价需求书的合作伙伴，根本没有读它。

ERP 集成的深度。 在 B2B 中，ERP 通常拥有合约价、账期与客户的财务身份，这让集成与定价引擎密不可分。请把它们当作一个问题来评估，而不是两个。

本地商业语境。 B2B 开票的 SST 处理、账期与信用惯例，以及您的客户实际上希望怎样下单——在这个市场上，那往往仍然是通过邮件或 WhatsApp，而门户被期待去容纳这一点，而不是在第一天就取代它。

上线之后的运营承载力。 B2B 规则会变：新合约、重新谈定的条款、新的客户层级。一个跟不上这个节奏的合作伙伴，会留给您一套在上线当天准确、到第二季度就开始漂移的系统。

定制价格：为什么它比看上去更难

Adobe Commerce 原生提供多种定价机制，而多数 B2B 需求是它们的组合，而不是一次定制开发：

• 客户组价格——粗粒度的分层：经销商、分销商、零售。
• 阶梯价格——某个商品上的数量折扣，可选按客户组区分。
• 目录价格规则——在进入购物车之前应用的条件式调整。
• 购物车价格规则——购物车层面的促销与条件式折扣。
• 共享目录——向不同公司开放不同的商品以及不同的价格。
• 按公司的合约价——为某个特定账户谈定的价格。

难的不是其中任何一项，而是优先级。当一位客户同时符合合约价、数量折扣、客户组折扣与一项进行中的促销时，必须有且只有一个结果是正确的，而且它必须与 ERP 会算出的那个结果一致，也与销售团队所承诺的那个一致。

那套优先级顺序是一项商业决策，而不是技术决策，而它正是进入 B2B 项目时最常被悬而未决的一件事。请在开发开始之前，把它写下来并签字确认。然后坚持要有一套把它编码进去的测试用例——一组已算好的例子，每一个包含一位客户、一个购物车和正确的最终价格，并在每次部署时运行。没有这个，日后每一次价格调整都是一场赌博。

还有两个陷阱值得点名。价格可见性在 B2B 中是一项真实需求：有些客户不能看到标价，有些在登录之前什么都不能看到，还有些是在「自己的价格保密」这个前提下谈成的。这是一项访问控制设计，而不是一个显示开关。以及舍入与计税基数——按行还是按单，以及 SST 在哪里计入——如果不在架构阶段定死，就会算出与 ERP 相差一分钱的总额，而这足以让一张凭证在财务那里被拒绝。

报价是一个流程问题，不是一个价格问题

询价看起来像一个定价功能，运转起来却像一套审批系统。真正重要的机制是：

• 谁可以发起。 公司账户内部的哪些角色有权提出报价请求。
• 接下来会怎样。 由哪位销售代表接收、他的权限有多大、他可以调整什么——行项价格、数量、运费、账期、有效期。
• 审批阈值。 超过某个额度的折扣需要第二位审批人，而这个额度本身应当可配置，而不是写死在代码里。
• 协商历史。 双方都需要看到曾经报过什么、还过什么价，而财务在日后也需要知道价格为何是这个数。
• 失效与转换。 报价在某个日期之前有效，之后转为订单——而订单必须携带报出的价格，不得重新计算。
• 买方一侧的审批。 许多 B2B 客户有自己内部的签核流程。一份不为此留出余地就直接转为订单的报价，会在客户的组织内部被驳回，而不是在您这里。

Adobe Commerce 原生支持可协商报价，对相当一部分企业而言，原生流程加上配置就已经够用。定制开发真正值回成本的地方，在于不寻常的审批拓扑、与销售团队日常已经在用的 CRM 的集成，以及必须与 ERP 自身合约记录对得上的报价逻辑。一个在这里立刻伸手去做定制开发的合作伙伴，根本没有试过原生路径。

B2B 的其余部分

价格与报价拿走了注意力；而下面这些决定着这个门户会不会真的被用起来：

公司账户与角色。 同一账户下的多个用户，各自权限不同——一位下单的采购员、一位审批的经理、一位只看得到发票、永远不会看到商品页的财务联系人。

采购审批流程。 把客户自己内部的规则，在您的系统中执行出来，因为正是这一点让他们不必离开门户就能完成采购。

快速订购与申购单。 实务中使用率最高的 B2B 功能，也是最被低估的。一位知道自己 SKU 的回头买家，想要粘贴一份清单，而不是逛商品目录。申购单把一笔周期性订单变成一次操作。两者都是 Adobe Commerce 原生具备的。

挂账支付与信用额度。 B2B 客户是按账期付款的。这意味着信用额度、下单时的可用额度校验，以及一个决定：当一笔订单会超出额度时该怎么办——拦截、转入审批，还是允许但打上标记。那个数字通常由 ERP 拥有，这就让它成了一个集成问题。

公司层面的订单历史与再次下单，而不只是按用户区分，这样同事下过的订单是可见、可复用的。

B2B 与 B2C 共享基础设施。 许多马来西亚品牌两种生意都做。Adobe Commerce 通过共享目录之上的站点与门店视图来处理这一点，但税额显示、价格可见性与结账规则会因受众而异，而这需要被设计出来，而不是被撞见。

Bridzia 的 Adobe Commerce 业务涵盖 B2B 商务，包括公司账户、阶梯价格、快速订购与申购单，以及在原生功能够不着时，为专属的价格与报价逻辑所做的定制模块开发。

实施应该怎样推进

行之有效的顺序是：

1. 在其他一切之前，先做规则梳理。 从掌握这些规则的人那里把定价与审批规则挖出来，写成已算好的例子，并取得签字确认。要预期会有矛盾；把它们解决掉，本身就是交付物。
2. 确定优先级，然后把它编码成测试。 此后每一次改动都以此为尺度衡量。
3. 用一条窄切片验证 ERP 集成——一位按合约价的客户、一笔订单，一路走到正确的凭证为止。
4. 围绕人们真正会用的那两个功能来构建门户，也就是快速订购与再次下单，把它们排在演示效果好的功能之前。
5. 用真实账户试点。 三四位愿意配合的客户拿它下真实订单，能发现的问题比任何用户验收测试脚本都多。
6. 在上线之前就规划好运营节奏，用于应对新合约与价格变动，而不是等第一份到来之后才想。

时间表应当反映这一点。一次标准的 B2C 重建视集成复杂度需要三到五个月；带定制报价与价格逻辑的 B2B 项目更长，而多出来的时间落在规则梳理与集成上，而不是前端工作上。

常见问题

Adobe Commerce 适合做 B2B 吗？

适合——公司账户、共享目录、阶梯与客户组价格、快速订购、申购单与可协商报价都是原生的，而且这个平台能在共享基础设施上、按不同规则同时承载 B2B 与 B2C。恰恰是在定价逻辑与 ERP 集成才是难点的地方，它的复杂度配得上它的代价。

做一个 B2B 项目，我们需要一家有认证的 Adobe Commerce 合作伙伴吗？

认证是一个合理的筛选条件，但仅凭它并不充分。请询问哪些具名的持证人员会在您的项目上，并把它与已交付 B2B 项目的客户推荐结合起来看——具体是公司账户、报价与合约价，而不是加了客户登录的 B2C 项目。

Adobe Commerce 能按客户处理合约价吗？

能，通过客户组、共享目录、阶梯价格与按公司的合约价组合实现，这些通常从拥有它们的 ERP 同步过来。设计工作在于决定哪一种机制承载哪一条规则，以及当多条同时适用时以哪一条为先。

一次 Adobe Commerce B2B 实施需要多久？

比同等规模的 B2C 项目更久。多出来的时间大多在规则梳理与 ERP 集成上，而不是在开发上。任何在您的定价规则被写下来之前做出的估算，估的都只是前台店铺。

报价应该定制开发还是用原生功能？

先从原生的可协商报价加配置开始。定制开发的正当理由是不寻常的审批拓扑、CRM 集成，或者必须与 ERP 合约记录对得上的报价逻辑——而不是对「专属定制」的偏好。

从哪里开始

在向任何人做需求说明之前，先把您的定价规则写成已算好的例子——客户、购物车、正确价格。这个练习会找出矛盾，而那些矛盾正是这个项目真正的范围。一个愿意认真对待这份文档的合作伙伴，正在展示的是比任何资质都更重要的那项能力。

Bridzia 从吉隆坡出发，用 14 年为亚洲各地的零售与快消品牌构建 Adobe Commerce（Magento）平台，其中包括 B2B 商务与定制的价格与报价逻辑。如果您正在界定一个 B2B 项目的范围，并且希望规则被认真质询一遍，请把项目情况告诉我们。