做批发独立站，常见误区是把问题缩成“给批发客户打折”。真实采购里，一个品牌客户可能有总部、区域仓和门店；总部谈年度价格，门店按自己的地址补货，采购员下单，财务按账期付款，仓库再根据 ERP 的库存和履约状态发货。若这些规则只留在销售邮件里，网站价格、下单地点和 ERP 订单就容易对不上。
本文以一家虚构的户外用品品牌为规划例子：它既卖给个人，也向经销商和连锁门店供货。以下品牌、业务流程和配置都是说明用的假设，不代表真实客户案例。Shopify B2B 已覆盖 Basic、Grow、Advanced 和 Plus，但各计划的目录数量、分配方式和部分扩展能力有区别；因此，建设顺序应从交易规则和数据边界开始，再决定店铺、主题及集成方案。官方的Shopify B2B 按计划功能说明和使用前要求列出了当前计划能力与限制，实施前应按实际店铺重新核对。
01 | 先确认计划能力，再画采购流程
Shopify B2B 不是 Plus 专属功能。Basic、Grow、Advanced、Plus 都可使用 B2B 功能，常见的公司资料、目录、批发价格和账期等能力可以作为方案起点；但特定功能随计划变化。例如 Basic、Grow、Advanced 的上限是所有 B2B Markets 合计最多 3 个启用中的目录，并非每个市场各 3 个；Plus 支持更多目录配置，并可把目录直接分配到公司地点。不要把计划描述成“能不能做 B2B”的二选一，应先把所需规则列出来，再核对对应计划是否支持。
规划表按“规则—负责人—Shopify对象—系统边界”填写：谁批准开户、哪个地址交易、谁能看批发价、订单是否复核、谁维护账期、订单与库存由哪套系统负责。逐项标出规则来源与更新责任，避免把所有流程误塞进 Shopify。
同时做一轮能力排除。B2B 客户必须通过新客户账户登录，旧版客户账户不适用；加速结账方式、订阅、部分配送选项及某些第三方应用也可能不兼容。若业务依赖这些能力，先做小范围验证，再承诺设计和开发。官方要求与限制说明适合作为检查清单，但最终仍应以当前店铺配置、应用版本和实际结账测试为准。
02 | 用公司、公司地点和联系人表达真实客户
建议把客户模型按三层建立：Company 表示签约组织；Company location 表示发生交易的具体业务地点；Customer 表示代表企业采购的个人。一个户外经销集团可以是一家公司，旗下总部仓、东部经销店和西部经销店则是多个公司地点。每个地点可以有自己的税务资料、账单与收货地址、价格、付款条件、结账设置和联系人。Shopify 官方公司与客户模型将公司地点定义为 B2B 交易对象，这一层决定了许多订单规则的落点。
开户时不要只导入邮箱和公司名。先整理企业外部编号、法定名称、税号、地点代码、账单地址、收货地址、币种或市场、价格组、付款条件、状态及联系人授权。企业编号和地点代码应稳定且唯一，命名规则要由运营、财务和 ERP 团队一起确认。联系人按地点授权；同一企业内，一个人可访问多个地点，需选择本次代表的地点。邮箱不能直接等同门店，参见企业联系人与地点权限说明。
用虚构经销商做一条验收样本：采购员甲能代表总部仓和两家门店采购；采购员乙只属于其中一家门店。分别验证登录后可选的交易地点、默认收货信息、可见价格、订单历史及权限边界。再测试联系人离职、地点停用、公司新增门店和同邮箱跨地点授权。将这些变更写成日常维护流程，避免联系人离职后仍能代表企业下单，或新门店被错误继承旧地点条件。
03 | 混合店还是独立 B2B 店，按运营边界选择
混合店让零售与批发共享同一店铺和产品基础，适合商品相同、品牌体验相同、团队能够维护统一目录与客服流程的情况。登录身份和 B2B 公司地点成为显示批发上下文的关键。零售访客应看到公开零售价与零售内容，获批企业登录后再看到对应目录、条款和采购入口。混合店的风险在于上下文串线：页面缓存、第三方搜索、邮件链接或自定义主题代码如果没按客户和地点正确呈现，可能会泄露价格或给错购买指引。
独立 B2B 店适合批发商品、内容、销售流程或团队管理边界明显不同的业务。例如经销商要浏览箱规、备件、报价单和门店补货工具，而零售站以消费者内容和单件购物为主。分店会带来第二套主题、导航、产品发布、搜索优化和应用配置，也要定义商品、客户和订单如何在店之间同步。因此，不要仅因“批发看起来更专业”就拆店；先比较两种方案的内容维护责任、运营权限、数据同步和客户登录体验。
画一页边界图，标出商品、定价、客户准入、库存、订单汇总和客服责任。大部分共用时评估混合店；批发若有独立商品、流程或运营治理，再评估专属店。可参考 Shopify 的混合店与独立店说明，再由团队定边界。
04 | 目录与价格要同时测试重叠规则
目录不仅是折扣表，它还控制批发客户能买哪些商品、按什么价格买，以及部分数量规则和阶梯价。可将通用经销价、特定区域商品范围、重点客户固定价分别作为规则来源，再决定由 B2B Market 还是公司地点承接。Basic、Grow、Advanced 最多 3 个启用目录是跨所有 B2B Markets 的总数；当不同客户层级迅速增加时，先检查当前计划的目录模型是否能表达所需规则，再考虑计划变化或外部方案。Plus 提供更多配置空间，也不是免于设计规则或没有系统限制。
要特别防止同一地点匹配多份目录。多个目录可能共享商品、不同价格、数量阶梯和 Markets 归属。Shopify 对多个直接分配到同一地点的目录有明确规则，但当公司地点分配目录又同时匹配市场目录时，适用结果取决于具体分配路径和当前规则。不要把某一个情形中的“最低价”概括为所有目录重叠场景的通用优先级。应逐个构造地点、市场、目录、商品和变体组合，在商品页、购物车、结账和订单记录中核对最终结果。官方目录价格与分配说明详细列出目录分配与重叠时的考虑点。
数量规则也要与包装业务吻合。假设品牌希望户外水壶按 6 件递增采购、某配件每次至少采购 24 件，这两个数字仅是规则说明，不是推荐值或真实客户政策。分别检查产品变体、订单行数量、快速订购表格、购物车数量修改和移动端步进器。数量规则、数量阶梯定价、固定价和整体折扣可能同时影响买家对单价的理解，验收时需展示单位、最低量、递增量和阶梯触发条件，并与报价单及 ERP 单位换算一致。
05 | Figma 采购界面要覆盖状态与单位
Figma 不能只交付一个“批发首页”。应至少画出访客、已登录但无授权地点、已获批联系人、可选多个地点、地点被停用、目录缺货、最小量未满足、超出库存提示、草稿待复核等状态。设计稿要标记状态由哪个数据决定：身份、Company location、目录、库存、订单状态，还是人工审批。对于多地点联系人，提供明确的地点切换器，并在页面、购物车和结账持续显示当前采购地点，避免用户以为切换的是收货地址、实际却切换了合同价格。
商品卡片和快速订购组件要把“包装单位”和“下单单位”说清楚。若一箱含 6 件，用户输入的是箱数还是单件数？页面显示价格按件还是按箱？阶梯价按单个 SKU 数量计算还是按整个订单数量？这些文本应在商品页、列表快速加购、购物车和订单确认中保持一致。数量步进器不应允许用户从合法增量跳到非法数量；若用户粘贴输入或编辑旧订单，界面要解释需调整到的有效数量，而不是只显示泛化错误。
移动端要验证批量输入、长 SKU、变体、价格列和数量控件。切换地点后是否重算价格、清理不兼容商品或要求确认，应写进原型。交付附关键字段、空/加载/权限状态及可访问性备注，减少开发猜测。
06 | Liquid 与 Headless 都必须传递正确上下文
在 Shopify 主题中使用 Liquid 时，企业名称、公司地点和 B2B 状态可用于组织适配内容；但页面个性化不应成为权限控制的替代品。真正的价格和商品可见性要由 Shopify 分配给已认证 B2B 上下文的目录及结账规则决定。主题代码可以改善导航、提示和表单体验，却不能只凭浏览器参数或用户输入的公司名决定折扣。零售访客、批发联系人和未授权用户应分别测试页面、搜索、快速加购、购物车和缓存行为。
Headless 并不是实现 Shopify B2B 的前提。若主题和账户扩展能满足采购流程，保持 Shopify 在线店架构通常更直接；只有当前台需要高度定制、复杂采购交互或已有统一前端平台时，才评估 Storefront API、Customer Accounts API 或 Hydrogen。无头前端必须把已登录身份、当前公司地点、目录及结账上下文正确传递到服务端和 Shopify API，不能只在客户端隐藏价格。还要核对可用 API、账户扩展和结账边界，避免在页面上显示可买，结账却按零售身份或错误地点计算。
选架构时列出每个上下文的来源、传递路径、失效条件和验证方式。比如切换地点后清空或重算购物车、会话过期后隐藏企业价格、缓存键区分不同 B2B 身份、分享商品链接时不把某客户的专属价暴露给公众。官方CompanyLocation API 文档有助于开发团队理解公司地点对象；具体字段和 API 版本需要随项目版本核实。
07 | 商家复核、买家审批与账期不是同一件事
Shopify 可按公司地点要求 B2B 订单先以草稿提交，让商家检查和调整后再确认。这适用于商家需要核实库存、报价或特殊运费的流程，但它不等于平台自动提供企业内部“员工提交—主管审批—财务批准”的通用多级审批引擎；官方说明将草稿定位为商家复核。若买家组织要求内部审批，应明确是通过采购单编号、外部采购系统、应用或定制流程完成，并记录谁拥有审批状态与拒绝原因。
将流程拆成两条责任线：买方授权决定采购员是否可以提交订单；卖方复核决定商家是否接受并确认订单。草稿状态、付款条款和信用审批不能混为一个按钮。付款账期可以在公司地点配置，支持的选项和额外功能需按当前计划核对；若页面允许“Net 30”，就要确定开票日期、到期日、部分付款、退款和逾期提醒由哪个系统负责。条件不满足时，买家看到的应是清楚的下一步，例如等待商家确认或联系账户经理，而不是模糊的“下单成功”。
应测试一张完整状态图：买家提交、商家审阅、修改价格或运费、买家确认（如流程需要）、订单确认、付款到期、取消与重建。明确哪些节点会发送邮件，哪些节点会生成 Shopify 订单号，ERP 何时接单，以及拒绝或修改之后是否保留审计信息。把买家审批与商家审核的职责写入实施说明，能避免销售团队把平台草稿误称为企业审批流程。
08 | ERP/WMS 集成先定义编号与失败责任
集成前先确定系统主责：Shopify 通常承载在线商品展示、公司地点采购体验和线上订单；ERP 可能负责客户主档、合同价、税务、财务及订单履约规则；WMS 负责仓库库存与拣货发货。实际分工依企业而异，关键是每个字段只有明确的主数据来源。不要让同一客户的税号、地点编号、货币或付款条件被 Shopify、ERP 和中间件各自人工维护却没有冲突处理机制。
建立编号映射表：ERP 客户号对 Shopify Company ID，ERP 地址或分支号对 Company Location ID，ERP 联系人或用户对 Customer ID，ERP 订单号与 Shopify order ID/订单名称互存。映射要覆盖新增、合并、停用和重建；仅靠公司名称匹配会在重名、改名和多门店下产生误关联。接口请求应有幂等键，重试前先判断目标系统是否已创建记录；失败消息需要可重放、可追踪，并保留源事件 ID、尝试次数、时间和错误原因。
订单契约写清推送时点、草稿处理、失败负责人、库存口径、取消、拆单、部分发货、退款和退货回传，并指定订单状态主责系统。对账核对地点、币种、SKU、单位、折扣、税费、运费、PO、账期和履约状态。开发可参考Shopify B2B 目录 API 指南，连接器仍需实测。
09 | 用验收矩阵和试点控制上线风险
验收矩阵建议按“角色 × 地点 × 目录 × 商品规则 × 订单流程 × 系统回传”展开。角色至少覆盖零售访客、未授权企业联系人、单地点采购员、多地点采购员和商家销售；地点覆盖正常、停用及跨市场；价格覆盖单目录、直接分配与市场分配重叠、固定价、折扣和阶梯价；订单覆盖数量错误、草稿复核、账期、取消、拆单和重试。每个格子写出预期页面、结账价格、Shopify 订单数据、ERP 收到的数据及失败时的责任人。
试点选择一个经销组织和有限商品，确认客户、目录、价格和库存来源，再让少量采购角色走代表性流程。记录问题步骤、影响对象、修复人和复测证据，不预设周期或收益。上线前确认价格地点组合、权限、数量一致性、编号映射、重试防重和例外处理均通过。
发布顺序可按数据、权限、目录、界面、结账、集成、监控逐层放开。先在测试环境准备公司和地点样本，再验证销售或运营手工处理路径，然后启用受控客户。上线后持续查看登录失败、价格投诉、草稿堆积、订单同步延迟、重复事件和库存差异；这些是运维指标，不应被包装成未经验证的商业成效。Shopify 的计划与 B2B 功能会更新，发布前将关键能力和限制再次对照官方文档并保存验收记录。
10 | WESWOO 交付的是可运行的采购链路
Shopify B2B 项目真正需要交付的，不只是一个能显示批发价的页面，而是一套能解释“谁代表哪家公司和地点采购、依据哪份目录定价、订单何时确认、数据由谁接收”的工作链路。WESWOO 可以从品牌与 Figma 采购体验设计开始，把地点切换、目录状态、数量规则和异常提示落到界面；再根据业务边界实现 Shopify Liquid 主题或评估 Headless 前端；随后配置 Plus/B2B 能力、打通 ERP/WMS 数据映射，并与业务团队一起完成场景测试和发布准备。
合作的关键是先把责任边界和验收条件写清，再按已确认范围实施。目录能不能表达价格政策、Shopify 与 ERP 谁维护客户资料、草稿如何转订单、接口失败由谁重放，都应在项目方案中有可核对的答案。需要了解 WESWOO 的 Shopify 设计、开发与集成能力，可访问WESWOO。规划示例中的品牌与数量仅用于解释设计方法；实际计划选择、配置规则和集成方案，应以企业的客户结构、合同政策、系统能力及官方当前文档为准。
本文沿用已审阅的中文完整稿，使用 AI 辅助整理。品牌页面与官方配图用于独立分析；方案示例、概念图均不代表已部署客户项目或实测经营效果。