大家好，我是十三。
导言：同一个商品，为什么卖不同客户不同价
在第 12 篇中，我们聊完了 CRM 的三层模型。客户已经被分层、被识别、被管理，接下来一个很自然的问题就是：面对不同客户，同一个商品到底该卖多少钱
如果你说"统一定价，一视同仁"，财务可能会摇头：大客户一年采购上千万，和小客户买一两件，怎么能一个价？销售也会皱眉：年底冲业绩时，不给点折扣怎么促单？
但反过来，如果价格全凭销售一张嘴，系统里又没有统一规则，那同一个客户两次下单可能出现两个价。客户投诉不说，财务核算也会变成一锅粥。
价格策略要解决的，正是这个矛盾：既要灵活，又要可控；既要让客户觉得值，又要让企业有利可图。
价格策略解决什么问题
在展开具体模型之前，先理解"为什么不能一个价卖所有人"。
不同客户带来的成本不同。大客户虽然采购量大，但通常账期长、需要专属客服、甚至要求定制服务，这些隐形成本都要算进去。小客户采购量小，但现款现货、回款快，资金成本反而更低。
不同客户的价格敏感度也不同。制造业客户对原材料价格波动极其敏感，而政府机构对价格敏感度相对较低，但对合规和服务要求极高。
如果没有分层定价体系，企业要么丢了利润（该高的没高上去），要么丢了市场（该低的没低下来）。
业务定义：价格策略是企业根据客户类型、交易规模、市场环境和经营目标，对同一商品制定差异化价格规则的管理体系。它回答的核心问题是：什么客户、在什么场景下、应该以什么价格成交。
你可以把它理解为餐厅的菜单。大厅散客看的是挂牌价，VIP 会员享受会员价，工作日午餐有特惠套餐。同一道菜，三种价格，三种规则，互不冲突。
三层定价体系：标准价、协议价与促销价
我把企业常用的定价体系归纳为三层：标准价 → 协议价 → 促销价。它们不是三个独立的价格，而是一个逐层覆盖、优先级递减的规则栈。
第一层：标准价（List Price）
标准价是定价体系的"原点"。
业务定义：标准价是商品对外公示的基准销售价格，是所有定价计算的起点。它不针对任何特定客户，而是企业对外宣称的"官方指导价"。
标准价的作用类似于地图上的坐标原点。不管后续怎么折扣、怎么促销，都需要先有一个基准，才能算出"到底打了多少折"。
标准价通常基于商品成本、目标毛利率和市场竞品价格综合制定。它一般不频繁变动，否则会让客户对品牌定价产生不信任感。
标准价的维护通常由产品部门或财务部门负责，销售无权擅自修改。这是为了确保对外报价的一致性，防止不同销售报出不同价格。
标准价的核心数据：
| 字段 | 说明 | 示例 |
|---|---|---|
| 商品编码 | 对应哪个 SKU | SKU-001 |
| 标准价 | 基准售价 | 10,000 元 |
| 币种 | 适用货币 | CNY |
| 生效日期 | 从哪天开始执行 | 2025-01-01 |
第二层：协议价（Contract Price）
协议价是面向特定客户的专属价格。
业务定义：协议价是企业与特定客户通过合同或年度协议约定的销售价格。它通常低于标准价，以换取客户的大规模采购或长期合作承诺。
在第 8 篇中我们提到的销售订单，如果客户是大客户，订单上的价格往往不是标准价，而是从协议价直接带出的。这是 O2C 流程中价格进入订单的主要路径之一。
协议价的核心价值在于"以价换量"。企业牺牲一部分毛利率，换取稳定的订单量和更可预测的生产计划。对于客户而言，协议价意味着采购成本的可预期性，便于其做预算。
协议价到期后通常有两种处理方式：一是自动失效，客户重新按标准价采购；二是触发续约谈判，根据上一年度的实际采购量调整新协议价。如果客户未达到最低采购量，系统通常会在续约时发出预警。
协议价的核心数据：
| 字段 | 说明 | 示例 |
|---|---|---|
| 客户编码 | 适用哪个客户 | CUST-001 |
| 商品编码 | 对应哪个 SKU | SKU-001 |
| 协议价 | 约定售价 | 8,500 元 |
| 协议有效期 | 从哪天到哪天 | 2025-01-01 至 2025-12-31 |
| 最低采购量 | 享受此价的门槛 | 100 件/年 |
第三层：促销价（Promotional Price）
促销价是临时性的价格让利。
业务定义：促销价是在特定时间段、针对特定客户群或满足特定条件时临时生效的优惠价格。它通常具有明确的起止时间和适用范围。
促销价就像超市的限时特价。它的目标不是常态运营，而是解决特定经营问题：清库存、推新品、抢市场、或者季度末冲业绩。
促销价如果设计不好，很容易"杀敌一千自损八百"。我见过一些企业促销结束后的常态销量反而下滑，因为客户已经养成了"等促销再下单"的习惯。
因此，好的促销价设计必须考虑"促销退出机制"。例如，设置促销期间的限购数量，或者促销结束后自动发送优惠券作为过渡，避免销量断崖式下跌。
促销价的核心数据：
| 字段 | 说明 | 示例 |
|---|---|---|
| 活动编码 | 促销活动的唯一标识 | PROMO-Q3-001 |
| 商品编码 | 参与促销的 SKU | SKU-001 |
| 促销价 | 活动期间的售价 | 7,500 元 |
| 起止时间 | 活动有效期 | 2025-07-01 至 2025-07-31 |
| 客户范围 | 哪些客户可参与 | 全部 / VIP 客户 / 新客户 |
三层定价的优先级规则
当三个价格同时存在时，系统必须有一个明确的优先级。否则同一个客户、同一个商品、同一时间，可能匹配到多个价格，导致歧义。
最常见的优先级是：
促销价 > 协议价 > 标准价
也就是说，如果当前有生效的促销活动，优先走促销价；如果没有促销，但客户有协议价，走协议价；如果两者都没有，才 fallback 到标准价。
这个顺序背后的逻辑是：促销价是时效性最强的临时规则，协议价是契约性最强的长期规则，标准价是兜底规则。临时规则优先于长期规则，这是为了保证促销的"限时感"真正生效。
价格瀑布模型：从标准价"跌"到净利润
理解了三层定价体系后，我们再往下走一步。客户真正付的钱，往往不是简单的一个"成交价"，而是经过层层折扣和费用调整后的最终数字。
这个层层递减的过程，在业财领域被称为 Price Waterfall（价格瀑布）。
你可以把它想象成一条从山顶流下来的瀑布，每经过一个断崖，水量就减少一些。标准价是山顶的源头，最终成交价是山脚的出水口，中间每一层都是一次"减扣"。
graph LR
A[标准价] --> B[数量折扣]
B --> C[客户等级折扣]
C --> D[促销折扣]
D --> E[折后净价]
E --> F[运费与杂费]
F --> G[最终成交价]
让我逐层解释这条瀑布。
第一层：标准价
这是瀑布的起点，也是所有计算的基准。比如一台设备的标价为 100,000 元。
第二层：数量折扣
客户采购数量达到一定门槛后，系统自动给予的折扣。例如采购 100 台以上，享受 95% 的折扣率，即减少 5,000 元。
第三层：客户等级折扣
基于客户等级（如 VIP、A 类、普通）的固定折扣。在第 12 篇中我们讲过，客户等级是属性层的关键字段。例如 VIP 客户额外享受 92% 折扣率，在数量折扣基础上再减少一定比例。
第四层：促销折扣
如果当前有生效的促销活动，再叠加一层折扣。例如季度末促销，额外 90% 折扣率，进一步降低价格。
第五层：折后净价
经过上述折扣后的净价。假设标准价为 100,000 元，经过三层折扣后的净价约为 78,660 元。到这里，商品的理论售价已经确定。
第六层：运费与杂费
如果合同约定运费由客户承担，或者需要加急配送产生额外费用，会在净价基础上进行调整。例如运费 500 元，最终成交价变为 79,160 元。
第七层：最终成交价
这是客户发票上看到的、实际需要支付的金额。
为了更直观地理解，我们用一张表来展示整个过程：
| 层级 | 项目 | 计算方式 | 金额 |
|---|---|---|---|
| 起点 | 标准价 | 基准价 | 100,000 元 |
| 减扣 1 | 数量折扣 | 100,000 × 95% | 95,000 元 |
| 减扣 2 | 客户等级折扣 | 95,000 × 92% | 87,400 元 |
| 减扣 3 | 促销折扣 | 87,400 × 90% | 78,660 元 |
| 加项 | 运费 | 固定运费 | 500 元 |
| 终点 | 最终成交价 | 78,660 + 500 | 79,160 元 |
从 100,000 元到 79,160 元，中间差了将近 21%。如果企业不做价格瀑布分析，很可能只知道"打了折"，但不知道到底让了多少利，更不知道哪一层折扣对利润侵蚀最大。
这个价格瀑布模型对企业的意义在于：它让"价格是怎么来的"变得完全透明。 财务可以清晰看到每一层折扣对利润的影响，销售也可以知道到底给了客户多少让利。
定价决策树：什么场景用什么价
规则有了，但一线销售面对客户时，最头疼的往往不是"规则是什么"，而是"这个客户现在该用哪个价"。
我用一张简化的决策流程图来回答这个问题：
graph TD
A[客户询价] --> B{有生效协议价}
B -- 是 --> C{有生效促销}
B -- 否 --> D{有生效促销}
C -- 是 --> E[使用促销价]
C -- 否 --> F[使用协议价]
D -- 是 --> E
D -- 否 --> G{达数量折扣门槛}
G -- 是 --> H[标准价乘折扣]
G -- 否 --> I[使用标准价]
我把常见场景归纳为三张决策清单。
场景一：新客户首次询价
| 判断条件 | 决策 |
|---|---|
| 无历史交易记录 | 使用标准价 |
| 无年度协议 | 不参与协议价 |
| 无生效促销 | 不参与促销价 |
| 最终定价 | 标准价，或申请新客户首单折扣 |
场景二：老客户日常复购
| 判断条件 | 决策 |
|---|---|
| 存在生效的年度协议 | 协议价优先 |
| 当前有促销活动 | 促销价覆盖协议价 |
| 采购量达到数量折扣门槛 | 叠加数量折扣 |
| 最终定价 | 促销价（如有）→ 协议价 → 叠加数量折扣 |
场景三：大客户年度谈判
| 判断条件 | 决策 |
|---|---|
| 客户历史采购额大于阈值 | 启动协议价谈判 |
| 客户要求独家供应或排他 | 可进一步让利 |
| 承诺下一年度采购量 | 按阶梯设定多级协议价 |
| 最终定价 | 签订年度框架协议，锁定协议价 |
这三张表不是标准答案，但适合作为系统设计和销售培训的起点。
价格在销售订单中的应用
在第 8 篇中我们详细讲过销售订单（SO）的结构。其中有一个关键字段就是"单价"。这个单价到底是怎么来的？又能不能改？
价格字段从何而来
当销售人员创建 SO 时，系统会根据以下逻辑自动带出价格：
- 读取客户编码，查询该客户是否有生效的协议价。
- 读取当前日期，查询该商品是否有生效的促销活动。
- 读取采购数量，判断是否达到数量折扣门槛。
- 按"促销价 > 协议价 > 标准价"的优先级，计算最终单价。
这个过程本质上就是价格瀑布的前四层计算。
价格如何锁定
订单确认后，价格必须锁定。原因很直接：销售订单是具有法律效力的合同，价格如果还能随意改动，合同就失去意义了。
在第 9 篇中我们提到，信用检查是在订单确认前执行的风控动作。价格锁定和信用检查，实际上是订单确认的"双保险"：一个防利润流失，一个防坏账风险。
价格何时可变
锁定的价格并非完全不可变。在以下场景中，系统通常允许价格调整，但需要走审批：
- 订单变更：客户要求增减数量，导致数量折扣档位变化。
- 促销到期：订单创建时促销有效，但发货时促销已结束。
- 价格错误：销售录入时选错了价格类型，需要更正。
这些调整都需要记录变更原因、变更前后值，并通常需要销售经理或财务审批。这是审计合规的基本要求。
SO 中的关键价格字段
一个完整的销售订单，价格相关字段通常包括：
| 字段 | 来源 | 是否可改 |
|---|---|---|
| 标准价 | 商品主数据 | 否 |
| 协议价 | 客户合同 | 否 |
| 促销价 | 营销活动 | 否 |
| 成交单价 | 价格引擎计算 | 确认前可改 |
| 折扣率 | 系统计算或人工录入 | 需审批 |
| 运费 | 物流规则计算 | 确认前可改 |
| 价税合计 | 系统汇总 | 否 |
"成交单价"是订单最核心的价格字段，它由价格引擎按瀑布模型计算得出。订单确认后，这个字段应该被快照保存，即使后续价格主数据发生变化，也不影响已确认订单。
价格策略的产品设计思考
作为工程师，理解了业务规则后，还需要考虑如何在系统中落地。价格体系的产品设计有几个常见的坑。
价格主数据如何维护
不要把价格当成商品表的一个字段。随着业务复杂度增加，价格会演变成一张多维规则表。更合理的做法是：
- 标准价由商品主数据维护，但单独放在价格表中，支持历史版本。
- 协议价由客户合同模块维护，与 CRM 中的客户编码关联。
- 促销价由营销活动模块维护，支持时间窗口和客户范围过滤。
价格版本控制
价格不是静态的。年初定的标准价，年中可能因为原材料涨价而调整。如果系统不保留历史版本，就会出现一个问题：上个月下的订单，这个月发货时，系统按新价格开票，客户当然不干。
合理的做法是：每个价格记录都有生效时间和失效时间。订单创建时，系统"快照"当时生效的价格版本，后续即使价格调整，也不影响已确认订单。
// 计算最终成交价的简化逻辑
function calculateFinalPrice(sku, customer, quantity, orderDate) {
// 1. 获取标准价
const listPrice = getListPrice(sku, orderDate);
// 2. 查询生效的协议价
const contractPrice = getContractPrice(customer, sku, orderDate);
// 3. 查询生效的促销价
const promoPrice = getPromoPrice(sku, orderDate);
// 4. 按优先级选择基础价
let basePrice = promoPrice || contractPrice || listPrice;
// 5. 应用数量折扣
const qtyDiscount = getQuantityDiscount(sku, quantity);
let netPrice = basePrice * qtyDiscount;
// 6. 应用客户等级折扣
const tierDiscount = getCustomerTierDiscount(customer);
netPrice = netPrice * tierDiscount;
// 7. 加上运费等杂费
const surcharge = calculateSurcharge(customer, sku);
return Math.round(netPrice + surcharge);
}
这段代码只有 20 多行，但基本覆盖了价格瀑布的核心计算逻辑。真实系统中，还会加上缓存、并发控制和详细的计算日志，方便审计和排查。
常见陷阱
在设计和实施价格策略时，有几个坑特别容易踩：
- 价格重叠冲突：同一时间段内，一个客户同时命中多个促销活动，系统不知道该用哪个。解决方式是为促销设定明确的互斥规则或优先级。
- 时间窗口漏洞：协议价昨天刚到期，销售今天下单，系统按标准价执行，客户投诉。解决方式是增加"宽限期"或提前续约提醒。
- 折扣叠加失控：数量折扣、客户折扣、促销折扣三层叠加后，最终价格跌破成本价。解决方式是在价格引擎中设置"底价红线"，任何计算结果低于成本价时自动拦截。
总结
价格策略不是"想卖多少卖多少"的艺术，而是"在什么条件下卖什么价"的工程。
今天我们梳理了三个核心要点：
- 三层定价体系是规则基础。标准价兜底、协议价换量、促销价应急，优先级必须是促销 > 协议 > 标准，否则规则会互相打架。
- Price Waterfall 让价格透明。从标准价到最终成交价，每一层折扣和费用都清晰可见，财务才能核算清楚利润，销售才能讲清楚逻辑。
- 订单中的价格必须可锁定、可追溯。SO 确认时快照价格版本，后续变更走审批留痕，这是业财一致性的底线。
在下一篇文章中，我们将继续深入 O2C 的财务闭环：当销售订单已经确认、货物已经发出、发票已经开具，企业如何系统性地管理应收账款，确保资金按时回笼？
往期回顾
- 业财通识12：一个客户，为什么会有三条记录？——CRM 作为主数据底座的三层模型
- 业财通识11：从开票到收款，企业如何收回每一分钱？
- 业财通识10：当货物发出，系统里发生了什么？
- 业财通识09：订单确认前，系统如何防止坏账风险？
- 业财通识08：企业赚钱的第一步，从"潜在客户"到"销售合同"
- 业财通识07：业财难点之"暂估入账"与冲销
- 业财通识06：什么是采购在途？它对库存预测的价值
- 业财通识05：商品世界的基石——SPU与SKU
- 业财通识04：采购结算与付款，企业花钱的最后一步
- 业财通识03：收到供应商账单，能直接付款吗？
- 业财通识02：当货物上门，系统里发生了什么？
- 业财通识01：企业花钱的第一步，从"购物清单"到"法律合同"
关于十三Tech
资深服务端研发工程师、架构师、AI 编程实践者。
专注分享真实的技术实践经验，持续记录企业系统、架构设计与 AI 编程实践。