同一款饮料在管理端有销售基础价，普通客户有等级价，南山门店又签了指定价，本周运营还做限时促销。销售在微信里报了“5.6元一瓶”，客户在手机商城看到5.4元，财务月底拿一张6元的基础价表解释，两边都觉得系统算错。问题不是价格层数多，而是四种价格分别服务什么对象、什么规格、什么时间没有说清，也没有把商品页、购物车、订单确认和原订单价一起核对。本文用一款500毫升饮料、瓶与12瓶一箱两种订货单位，讲清如何建立可执行的价格政策。
先写“谁买什么”而不是先谈优先级
定价会议先把客户、商品、单位和时间放在一张表里。客户包括未签协议的普通门店、某一类获批客户、单独签约的南山门店，以及符合本次活动条件的消费者；商品要精确到条码和500毫升规格；单位要分瓶和箱；时间要记录指定价与促销的生效及到期。没有这些条件，“这款商品今天多少钱”没有唯一答案。更不能看到客户投诉就改商品销售基础价，因为这个动作可能让所有未设置特殊价格的客户一起变化。
图1是本篇的报价判定卡。它刻意不写死“促销永远覆盖指定价”之类规则，而要求每次先识别候选价格、适用范围、单位和权益叠加，再用目标客户账号形成订单结果。不同租户、活动类型或下单入口的设置可能不同，企业必须以当前真实环境的试单为准。运营负责说明活动给谁，销售负责协议客户范围，商品员核规格单位，财务核订单最终金额；四人不应各持一张只对自己有用的价格表。
图1：价格不是一个商品字段，而是客户、规格单位、时点和权益共同决定的本单结果。
基础价是商品销售的统一底稿，等级价用于同一类客户共享政策，指定价用于少数客户的协议条件，促销价或优惠权益用于一个有明确范围与期限的活动。本例基础价设6元/瓶、72元/箱；普通客户类型价为5.8元/瓶、69.6元/箱；南山门店指定价为5.6元/瓶、66元/箱。66元/箱并不等于5.6乘12，说明箱价本身也属于独立的交易条件，不能在报瓶价时机械推导箱价。所有数值只用于说明核对方法，不是任何客户应采用的系统默认价格。
基础价和等级价：让一类客户不必逐一手调
商品销售基础价应由有权岗位维护，作为没有其他有效条件时的价格起点。一次采购成本上升，如果直接把基础价从6元改成6.4元，受影响的可能是没有协议的客户、未配置等级价的规格及未来新客户；已经谈妥的指定价不应未经复核就跟着变。调整前先拉出受影响客户、商品和在途报价，明确新价生效时间与已提交订单的处理方式。商品员核箱规和单位，财务核税费及毛利，销售负责通知实际受影响客户。
等级价针对同一类客户。图2是管理端设置等级价的真实画面，分别可看到客户类型、销售价与该类型价格的栏位；它能证明价格层的配置入口，但不能单凭画面证明客户最终成交价。普通客户5.8元/瓶与69.6元/箱属于同一客户类型的政策。如果个别门店只因谈判更强就拿到另一价格，应该记录明确的批准理由和到期日，不应新建一类只有一个客户、无人复核的“等级”。客户类型变更也要检查仍在途的订单和报价，不能用修改客户类型来追溯性改写历史成交。
图2：同一类型客户按瓶和按箱分别维护价格；页面设置仅是试单前的一环。
销售与客服共用一张“适用价说明”即可，不必向客户暴露其他门店的协议价。客户问价时先问订购规格与数量，再核当前客户分类；报价应写“南山门店本月订这款500毫升饮料、按箱购买的条件”，而不是只发一个“66元”截图。对常买客户，还要把配送、付款、起订和退换条件一起写清，否则不同渠道虽然看到同价，实际承担的服务成本仍不一致。企业内部可以用价格表组织审核，但客户实际下单的金额必须从系统订单验证。
指定价：协议例外不要污染全体等级价
南山门店单独签了季度采购协议，指定5.6元/瓶和66元/箱。图3是真实管理端指定价画面，显示价格关联到某个客户与商品；本文需要读者看的是“客户指定”及瓶、箱两个金额，而不是示例客户名称。保存前销售核合同主体、客户账号、商品规格、数量承诺和有效期，财务核毛利、账期及已逾期应收。协议未批准时，不能为了让客户先下单而临时改全体普通客户等级价。指定价到期也不能理解为“价变成0”，应以目标客户账号验证之后到底回到了哪项有效政策。
图3：协议价格限定到客户与规格，瓶价和箱价分别核，不用一处变更影响所有普通客户。
手机端是发现“后台设对了、客户仍看错价”的关键证据。图4的手机商城商品页展示普通客户看到5.8元/瓶与69.6元/箱；图5是指定客户看到5.6元/瓶与66元/箱。两张图的角色不同，不能把图5发给所有客户当作统一报价。若客户账号切错、归属类型设置不对，页面的金额就会变；若商品有多个单位，还要从商品页进入购物车核选购单位没有被转换。销售能解释价格从哪里来，客户才能相信这笔交易，不必每次找老板特批。
图4：普通客户账号看到的是对应等级价；应记录账号类型、商品规格与取证时点。
图5：同款商品在协议客户账号显示指定价，说明核价必须以实际购买身份为准。
促销先算叠加后的真实收入，再决定发布
促销可能是商品直降、满减、券、赠品或运费减免，它们不是同一种成本。运营要写清目标客户、商品和单位、门槛、起止、每人上限、叠加方式、退款回退、预算及停止条件。假设本周某活动给符合资格客户5.4元/瓶，不代表南山门店所有订单都按5.4元，更不代表66元的协议箱价应自动变成64.8元。活动可能只覆盖瓶装、可能有每单数量限制，也可能与客户指定价不叠加；必须以具体活动设置和真实账号试单核实。不能把一个演示价格顺序写成所有版本的固定规则。
活动预算应算最终到手收入而非只看名义售价。示例：南山门店按66元/箱购买两箱，商品合计132元；若订单确认页另有配送费或优惠，最终应付可能与132元不同。图6的手机商城确认页显示本次订货单和应付金额，证明核对必须走到提交前的最后一步；图中金额只对该测试订单有效，不能从一张图推断所有客户的运费或优惠。财务复核应看“原商品金额、活动减免、运费、实际应付、收款与退货”是否能落回同一订单。赠品还要算出库成本与退货后能否追回，不能因为售价没有变就认为活动没有成本。
图6：商品页价不等于本单应付；订单确认还要核数量、地址、优惠和配送费用。
若运营把指定客户也放进全场券活动，可能形成意外的双重优惠。发现后先暂停新活动对该客群继续生效，列出活动开始到修订期间的订单，不删除已经成交的记录。再由销售核客户承诺、运营核实际券规则、财务核减免金额与退款，决定后续是缩小适用客群、调整门槛还是修改基础政策。先看系统记录的实际结果，再决定责任，不把全部差额归为“系统自动给错价”。
四类账号、两种单位、一笔异常单，才算完成验价
上线前至少准备四类账号：只有基础价适用的客户、普通等级价客户、南山协议客户，以及符合本次活动资格的客户。每个账号分别检查瓶和箱，记录商品页、购物车、订单确认页、订单详情的金额及时间。试单矩阵还要记录付款方式、配送费、券的使用状态和预期结果。如果目标客户在管理端看起来是普通类型，在手机商城却命中指定价，先查是否留有过期但未清理的客户指定价；如果按瓶正确、按箱异常，查商品单位和独立箱价；如果确认页比购物车高，查地址及运费；如果活动已结束仍低价，查实际活动终止与其它有效权益。
异常单不要只选“系统报错”。应故意让一个不在促销范围的普通客户领券、让协议价刚到期的客户重新下单、让同一客户把订单从一箱改为十二瓶。期望是哪些价格和权益应出现、哪些不应出现，都由批准规则写清。试单只使用受控环境和可识别的测试账号，不在客户真实业务里随意创建虚构订单。若要借真实订单验证，也须按实际业务授权和正常支付、发货流程处理，避免为制作知识内容污染客户往来。
成交后订单必须保留当时的商品金额、优惠、最终应付和客户身份。今天更新了等级价，不意味着上月客户应收应付就该重算；客户投诉时，客服应先找原订单和当时有效政策，再决定是否按审批走售后补差。财务不能拿现在的基础价解释过去指定价订单，销售不能只发当时的聊天报价覆盖系统成交记录。四类账号至少跑通一次正常单，再跑过期、单位切换或权益误叠加的异常单，才能说“客户报价一致”。
用一周建立价格变更与跨岗位交接机制
第一天梳理主力商品的瓶、箱规格和当前基础价，列出客户类型、有效指定价与正在运行的促销；发现同一客户同一规格同时有几条解释不清的价格规则，先冻结新增例外。第二天由销售核协议客户、期限和付款，商品员核单位换算，运营核活动覆盖与优惠叠加，财务核毛利底线及往来风险；经营负责人只审批写清对象、原因、金额与截止日的例外。第三天按四类账号、两种单位完成手机商城试单，填实际结果表。剩余几天跟踪真实下单、退款、活动到期与客户问价，把错误归到“客户身份、商品单位、规则范围、活动叠加、配送应付”之一，不把所有差异笼统记为报价混乱。
价格调整后要让受影响岗位知道同一件事：销售拿到批准的客户报价和解释口径，客服知道如何定位原订单，运营知道活动何时终止，仓配知道按订单商品与单位出库，财务知道优惠和应收从何而来。判断是否有效，不看价格表建了多少项，而看客户在手机商城看到的金额、业务员给的书面报价、订单确认金额以及财务回查原单的结果能否互相解释。若订单条件变化，重新试单并记录新生效日；若解释不了，就先缩小优惠范围，保留旧单，修清规则再扩大。这才是多层价格并存时仍让客户报价一致的经营纪律。