同一家公司既向区域经销商供货，也接零售门店的小批量补货，还与连锁客户签年度协议。把三类客户放进同一个订货商城可以减少多个系统、多个商品档案，但“共用商城”不等于“所有人看到同一货盘与同一价格”。经销商看到仅供项目客户的商品，会质疑渠道政策；门店看到批量采购价却不满足订货条件，会认为平台价格不透明；大客户虽有协议价，订单落到错误门店账号时，又可能触发错误的账期与收货地址。
管理目标是让每个登录客户在自己的身份下，看到可订商品、适用成交价及可执行的支付和配送条件，并让总部能从订单回查这些条件。决定客户身份、商品可见范围、价格、授信与履约的资料应分开维护，却要用同一组代表客户在手机商城验证。本文以经销、普通门店和协议客户三类交易为例；具体分类名称、合同与权益由企业自行确定，不把示例当作系统默认规则。
先写清每类客户应该看到和使用什么
不要先在系统里逐个商品点“屏蔽”，而应先做一张渠道交易矩阵。经销商买哪些品牌或区域货盘，是否有整箱起订和专属折扣？普通门店可买哪些常备品，允许哪种配送与付款方式？协议客户除标准货盘外，是否有项目清单、指定价格、单独收货点和账期？一列是商品范围，一列是价格依据，一列是交易条件，再写明负责人和生效期限。未签订协议的优惠不应因客户自称“大客户”而提前开通；已经到期的政策也不应在商城继续展示。
一件商品可以对多数客户开放，却对某区域或某客户类型限制；也可能商品可见，但价格、起订量或交付方式不同。两种情况不要混为一谈。商品看不到，应先查可见范围与上下架；看得到但价格不对，查客户身份、指定价和促销；能加入购物车但提交受阻，查起订、收货区域、授信、付款与库存等条件。给客服一张这样的排查表，比让客服重复说“刷新试试”更快定位问题。
图1：以商品可见范围、价格依据和付款交付条件三列定义三类客户；上线时要用实际合同和代表客户替换示例。
先把客户类型区域和账号归属整理正确
客户资料是政策命中的起点。PC管理端客户列表能按客户类型、所属区域和状态筛选；因此上线前应核对每个营业主体、门店和项目客户分别对应哪个档案。一个连锁客户有多家门店时，总部谈判主体与实际下单门店未必是同一账号，收货地址、对账主体和授信归属也不能凭名称推断。先确定一个账号能代表谁下单，谁看历史订单，谁收货，谁承担付款责任，再设置类型与区域。不要为了不同价格反复建立同一家门店，造成历史应收和订单分裂。
图2：客户列表展示客户类型、所属区域及状态；这些资料是货盘与交易规则核对的起点。
业务员归属、客户类型和区域是不同维度。某门店由业务员甲维护，不代表它属于“经销商”价格组；某集团采购在华南收货，也不意味着所有华南商品对它开放。资料调整要有审批和生效时间，尤其是客户从普通门店升级为协议客户时：先确认协议、可订商品、指定价、账期与收货点，再让代表账号重新登录验证。已经提交的旧订单应保留当时的成交记录，不能靠修改客户类型追溯性重算已发生交易。
商品范围优先按稳定分组再处理例外
商品管理员先按品牌、品类、渠道或销售区域设置稳定的可见规则，再处理少数特定客户的例外。PC管理端经营屏蔽列表提供按客户类型、区域和指定客户筛选的入口，也能查看商品是否上架；这说明商品“可见”和“可卖”至少要同时检查。一个商品被屏蔽给经销商，必须核实是否仍要提供给普通门店及协议客户；一个只供工程项目的SKU，不能因为销量好就无意间开放给零售端。屏蔽规则应记录原因和负责人，避免新员工看到销售不佳就擅自清空设置。
图3：经营屏蔽列表可按客户类型、区域、指定客户查询；商品上架状态与屏蔽范围都要核对。
若个别客户看不到商品，排查顺序应是“账号是否正确—客户类型与区域是否正确—商品是否上架—可见规则是否命中—是否被指定客户限制”。手机商城中的搜索无结果可以作为发现问题的线索，但单凭一张空搜索页不能证明原因就是屏蔽；也可能是关键词、商品下架或账号没有该商品范围。对应的真实手机页可用来复核“在此账号下确实未显示”，后台规则与另一类可见客户的对照才能解释为什么。
图4：手机商城示例账号搜索具体商品编号未返回商品；需要联同后台可见设置及另一代表账号对照，不能单凭空页断定屏蔽生效。
价格与信用条件分别落到相应资料
商品对客户可见之后，才核实本次成交价。销售价、客户类型价、客户指定价和促销价可能各有适用条件；指定价页面可以为具体客户和规格维护瓶价、箱价。截图中某个500毫升规格的指定价同时列出瓶和箱，说明按单位订货时不能只核一个单价。价格最终应以代表客户登录手机商城、选择具体规格和数量后的展示及订单结果为准，不能拿后台某个基础价格字段代替客户实际应付金额。
图5：指定价页按客户、500毫升规格、瓶价和箱价维护；价格是否生效仍须用相应客户账号下试单核验。
遇到促销与协议价重叠，要先核活动资格、有效期、适用商品和企业价格优先规则。不同价格条件不能只凭客服口头解释，尤其是客户已拿到报价或已提交订单时，后台调价不应让原交易无依据。零售客户可能当场支付，经销商可能有额度和账期，大客户可能按验收节点付款；信用条件与商品可见、价格是三套规则，不能因为给客户看了协议价就默认允许赊销。财务要确认欠款、额度和到期日期，销售要确认交付承诺，客户在下单时才能看到可执行的条件。
如果某客户同时属于渠道经销商又有项目协议，先按实际交易主体、项目范围和合同约定确定本单用哪个账号、哪个收货点、哪套价格。不要为了让一笔订单通过而临时把客户改成另一个类型，影响其全部后续交易。可对项目商品或指定客户维护例外，再由负责人审批，保留生效区间和对应客户；对短期促销则核活动是否与指定价叠加，不要让商品价格规则承担授信审批的职责。
用代表客户在手机商城验证商品与选购
上线前至少准备经销、普通门店、协议客户各一个真实配置的代表账号，再加一个边界账号：区域未开放、协议已到期或仅有部分商品权限。让他们在手机商城逐项完成搜索、打开商品、选择规格单位、加入购物车、查看成交价和提交试单；同时由后台按订单号核客户、金额、收货地址及订单状态。PC商城可以做补充对照，但客户实际使用手机商城时，手机端结果优先。只检查后台配置表而不登录客户账号，无法发现账号归属、缓存或交叉规则带来的实际显示差异。
测试要覆盖“应看见且能下单”“应看见但条件未满足”“确实不应看见”三类结果。前者验证正常成交；第二类要给客户能理解的提示，例如未达到起订量或额度不足；第三类验证货盘边界。若普通门店看见经销专供商品，先暂停该商品对相关账号的开放，核客户类型和屏蔽条件，再修复并复测；若协议客户看不见其专属商品，先检查协议期限和指定客户规则，而不是直接全局开放。测试记录应有客户账号、商品规格、测试时间、预期、实际、订单号或搜索结果，让问题可以重现。
正式运营后，每次新增客户类型、调整区域、上架新品、换价格政策或续签协议，都应重复相同的代表账号验收。可每周抽查不同客户类型的订单价格和异常客服反馈，重点看“看不到商品”“价格与报价不符”“提交时才发现信用受限”等问题。结果指标不能只看商城浏览量，还应核有效订单、价格投诉、撤单、欠款与实际履约。多渠道经营的价值不是把所有客户放在一个页面里，而是复用一套商品与订单基础，同时让每种客户的交易边界可解释、可验证、可持续维护。
共用商城的边界应由谁负责
商品员负责货盘与上架；销售主管负责客户分类、渠道政策和特殊报价；财务负责额度、账期与收款规则；运营负责代表账号验证和反馈收集。一个人可以兼任多个岗位，但每套规则要有确定的责任人和变更记录。规则冲突时，先停止影响面最大的错误展示，再按客户账号和订单核对事实；已经成立的订单按当时承诺处理，后续新规则从明确时间点生效。这样客户不会因为企业内部更换政策而在手机商城里忽然看见另一套价格。
老板可以用一张表检查这个模式是否健康：按客户类型比较可订商品数、成交价异常数、有效订单数、退单原因、账期占用和订单毛利。若某渠道订单增长，但优惠、退货及账期风险吞掉贡献，需要调整的是该渠道交易条件，而不只是增加屏蔽商品。经销、零售和大客户共用商城的前提是规则分明、订单可回查；若企业尚未搞清客户身份与合同边界，应先治理资料并试运行，再扩大到全部客户。