去年双十一前，我把同一款蓝牙耳机同时刊登到五个平台，用的是同一套成本数据、同一个加价率、同一次批量刊登。两周后拉数据复盘：亚马逊站点净利率 2.7%，速卖通 11.4%，Shopee 是 -3.1%。商品、供应链、图片、文案全都一样，唯一的变量是刊登价。那次复盘让我彻底改了做法，多平台刊登定价不是"算出一个价格"，而是"把一套商品数据映射成一组平台价格"。这篇手册讲的就是这套映射关系怎么在 ERP 里落地，包括成本参数表怎么建、价格瀑布怎么排、字段怎么映射、刊登前怎么复核、上架后怎么调价。
先把我最想说的一句话放在最前面：绝大多数多平台卖家的亏损，不是定价算错了，而是定价没有"流程化"。算错只影响一个 SKU，流程缺失会影响整店、整批、整年。
我在带团队时见过太多次同一个场景：运营在 Excel 里算得很精细，佣金、运费、汇率都考虑了，结果批量刊登时 ERP 里只填了一个"售价"字段，折扣价、促销价、参考价全靠平台默认，最后成交价和测算价差 15% 以上。问题不出在算，出在"算完之后怎么进入系统"。
我把这套东西拆成三层，任何一层缺失都会漏水。底层是成本参数层，它回答"这个商品卖到哪个平台，要摊掉哪些钱"。这一层必须是"平台相关"的，而不是一张全平台通用的成本表。
中层是定价规则层，它回答"用什么样的加价逻辑把成本推成价格"。这一层决定你是顺加、倒推还是混合，也决定不同 SKU 分层用不同毛利目标。
上层是平台落地层，它回答"这个价格最终写到平台的哪个字段上"。售价、促销价、划线价、参考价、会员价，字段不同，用户看到的成交价就不同。
三层之间的关系可以概括成一句话：成本参数决定底价，底价决定规则边界，规则产出刊登价，刊登价再被平台字段二次改写。
原因不复杂：平台与平台之间，变动成本的差异远大于固定成本的差异。采购成本、国内段运费这些平台无关的成本是固定的，但佣金、履约费、税费、广告效率、退货率这五项是高度平台相关的，它们动辄吃掉售价的 30% 到 45%。
加价率是乘数，成本差异是基数。基数在不同平台间来回摆动，用同一个乘数去套，结果必然是有的平台赚钱、有的平台亏钱、有的平台刚好白干。
更隐蔽的一点是：亏损的平台往往不是销量最差的平台，而是销量中等的平台。销量差你早就砍了，销量中等反而容易被"看起来还行"的报表掩盖过去。
我判断一套刊登定价机制是否健康，只看一个动作：能不能拿任意一个已刊登的 SKU，在 3 分钟内反推出它当前的真实净利率，并说清差额来自哪几个成本项。
做不到，说明你的定价还停留在"填数字"阶段，没有进入"可追溯"阶段。可追溯是后面所有自动调价、批量优化的前提。
我把一个多平台卖家的定价失控过程拆成四个阶段，这四个阶段几乎每个团队都完整走过一遍。问题不在最后那一步，而在最早那一步，成本参数表从来没按平台拆过。
刚开始做多平台时，团队通常在 Excel 里建一个"定价计算表"：采购成本、头程运费、平台佣金率、目标毛利率，几列公式一拉，价格就出来了。这个阶段的计算其实是对的，甚至是精细的。
但它有两个致命前提：一是所有数据靠人工维护，二是这张表只针对一个平台。当第二个、第三个平台进来时，多数人的做法是复制一个 Sheet 改几个数字，而不是重建一套参数结构。
结果就是五个平台五张表，公式各不相同，口径逐渐漂移。半年后没人敢说清哪张表是准的。
批量刊登时，ERP 的价格字段设计通常是"成本价 + 售价"这样的最小集合。运营为了让刊登跑起来，往往直接把 Excel 算出的售价填进"售价"字段，剩下的促销价、参考价用平台默认或留空。
这一步丢掉了三样东西：底价（不亏损的临界价）、平台差异化的成本参数、以及价格的版本记录。丢完之后，系统里只有一个数字，没有判断依据。
我见过最典型的后果是：一次全店 8 折活动，运营直接用 ERP 批量改价，把一批本来就贴着成本线的 SKU 打到了亏损区。活动结束后忘了改回来，亏了整整一个月才发现。
平台促销不是单一的。优惠券、满减、平台大促直降、新客立减、运费补贴，这几项经常可以叠加。你在 ERP 里设的"促销价"，用户实际成交时可能又被打掉一层。
如果你只按"促销价 = 售价 × 0.85"来算，而平台实际叠加后相当于 0.72，那么原本 15% 的毛利直接被吃光，还要倒贴履约成本。价格击穿往往不是一次事故，而是一类系统性缺口。
上架后的调价，大多数团队是没有触发条件的。运营早上看一下竞品，觉得贵了就改，改完不记录，也不看改价后的转化变化。改了三十次，说不出哪一次有效。
真正的问题不是"改得多还是少"，而是没有区分"该改的信号"和"不该动的噪音"。竞品偶尔降价是噪音，竞品连续 7 天低于你 8% 以上才是信号。
下面六个误区，我在不同阶段全都踩过至少一次。写出来的目的不是让你避免思考，而是让你知道该在哪一步停下检查。
这是最普遍也最致命的。加价率是结果，不是策略。正确的做法是：加价率由平台成本结构倒推出来，而不是先定一个数字再套所有平台。
同样是 40% 的加价率，在平台相关成本占比 50% 的平台上，净利率能到 15%，在占比 73% 的平台上可能只有 2%。你不会用一个体重标准去衡量所有运动员，同样不该用一个加价率去覆盖所有平台。
刊登价是你在后台填的数字，成交价是用户实际付的钱，两者中间隔着促销、优惠券、平台补贴和运费策略。把刊登价当成交价，测算出来的利润率会系统性偏高。
我的处理方式是：所有利润测算一律以"预估成交价"为分母，而不是刊登价。成交价怎么估？按该平台该品类过去 30 天的平均折扣深度折算，不用猜。
这个动作看起来天经地义，实际藏着两层损耗。第一层是汇率波动，第二层是结算与提现环节的手续费和汇损。
从你定价那天到平台结算打款，中间通常有 14 到 45 天。这段时间汇率变化 2% 到 3% 是常态。如果你的净利率本来就是 4%，一次汇率波动就能把它归零。
爆款、长尾款、测新款、清库存款，这四类 SKU 的商业目的完全不同。爆款要守利润，长尾要守周转，测新款要守曝光，清库存要守现金流。
给清库存款设 50% 毛利目标，结果就是永远清不掉；给测新款设 10% 毛利目标，结果是每一单都在亏。毛利目标应该按 SKU 角色分层，而不是按店铺统一。
这是最容易被忽略的认知差异。计算器是"输入一次、算一次"；规则引擎是"定义一次规则、持续应用"。多平台刊登的规模一旦超过几百个 SKU，靠计算器模式必然崩溃。
判断标准很简单：当你新增一个平台时，需要改多少个地方？如果答案超过"新增一条价格规则"，说明你还在计算器模式。
价格是店铺最敏感的资产，但很多团队对它的权限管理比库存还松。运营可以随时批量改价，没有审批，没有日志，改错了也不知道原来是多少。
我后来强制加了一条规则：批量改价必须有审批，单次调整幅度超过 15% 必须有第二人复核，所有改价必须留版本记录。这条规则救回来的钱，远超它带来的效率损失。
这一节是全文的方法核心。我把它拆成五步：拆成本、定底价、选思路、设缓冲、做映射。五步走完，你得到的不只是一个价格，而是一套可以复制到新平台的定价结构。
这一步的关键不在于成本项有多少，而在于分类。平台无关成本决定你的价格下限，平台相关成本决定你的平台间差异。
平台无关成本包括：采购成本、包装成本、国内段运费、质检与损耗。这些在你决定卖什么的时候就已经锁定了。
平台相关成本包括：平台佣金、支付手续费、履约与物流方案费、关税与增值税、广告费率、退货与售后计提、促销折扣成本。这些每换一个平台就要重算一次。
我在 ERP 里建成本参数表时，会明确分成两组字段，平台无关成本放在商品主数据里维护一次，平台相关成本放在"平台-店铺"维度里维护多次。这个设计决定了你后续能不能一键新增平台。
底价（Floor Price）是这套方法里最重要的一个数字，也是最常被跳过的。它回答的问题是："这个商品在这个平台上，最低能卖到多少钱而不亏钱。"
底价的公式结构是：
底价 = (平台无关成本 + 平台相关固定费用) / (1 – 平台相关变动费率 – 目标净利率下限)
其中：
平台相关固定费用 = 履约物流费 + 关税/VAT + 支付手续费固定部分
平台相关变动费率 = 平台佣金率 + 广告费率 + 退货计提率 + 促销折扣率
目标净利率下限 = 该 SKU 角色允许的最低净利率（清库存可设为 0）
这个公式的意义在于：底价是一个"红线"，不是"建议价"。任何刊登价、促销价、活动报名价，都不能低于它。有了这条红线，前面说的"价格击穿"就不会发生。
我建议把底价作为 ERP 里的一个独立字段维护，而不是每次临时算。因为临时算的东西，在批量刊登和批量改价时会被直接忽略。
顺加定价是"成本 × 加价率"，优点是快，适合铺货型卖家和测新款阶段。缺点是它从成本出发，不关心市场能不能接受这个价格。
倒推定价是"从目标净利反推售价"，优点是利润可控，适合精品型卖家和爆款。缺点是需要准确的费率数据，维护成本高。
我在实操中用的是混合模式：底层用倒推算出底价，中层用顺加生成初始刊登价，上层用市场比价做最终修正。三段式的好处是每一段都有明确的失败边界，不会出现"价格算出来但卖不动"或者"卖得动但不赚钱"的单边失控。
汇率缓冲不是玄学，它取决于你的结算周期。结算周期越长，缓冲要留得越厚。
我的经验做法是：结算周期在 14 天以内的，留 2% 到 3% 的缓冲；结算周期在 30 天以上的，留 4% 到 6%。这个数字是我自己团队的设定区间，不是行业标准，你需要按自己的结算节奏和收款币种调整。
利润底线则按 SKU 角色分层设定：爆款不低于 15%，常规款不低于 10%，测新款允许 0 到 5%，清库存允许 -3% 到 0（用亏损换现金流，但要设总量上限）。
这两项都必须在 ERP 里做成可配置参数，而不是写在文档里。写在文档里的规则，在批量操作面前等于不存在。
这一步是把前面四步的成果送进系统。多平台刊登最容易出错的地方不是价格算错，而是价格放错字段。
下面是我实际使用的字段映射逻辑，同一套商品数据在不同平台上的价格语义并不相同：
| 价格语义 | 业务含义 | 是否允许低于底价 | 维护频率 |
|---|---|---|---|
| 成本价 | 平台无关成本合计，商品主数据维护一次 | ， | 采购变更时 |
| 底价 | 该平台不亏损临界价，由公式倒推 | ， | 费率变更时 |
| 刊登价（售价） | 用户未使用任何优惠时看到的价格 | 否 | 按调价规则 |
| 促销价 | 活动期间实际成交价 | 否 | 每次活动前 |
| 划线价/参考价 | 用于展示折扣力度，部分平台有真实性校验 | 是（但需合规） | 活动前 |
| 批量采购价 | 面向 B 端的阶梯价，通常低于零售 | 否 | 按客户等级 |
这张表里最重要的一行是"底价"。只要底价在系统里是独立字段，任何批量改价动作都能被它拦住；如果底价只存在于某个人的脑子里，它拦不住任何东西。
上面讲的是方法，这一节讲落地。我用自己团队一次真实的流程改造来说明，改造前后的差异到底体现在哪些指标上。
改造前，我们有 5 个平台、9 个店铺、约 1400 个在售 SKU。定价靠 Excel，刊登靠人工填字段，改价靠平台后台逐个操作。
当时最突出的三个问题：一是刊登 100 个 SKU 平均耗时 6.5 小时；二是全店改价一次平均 3.2 小时，且经常漏改；三是价格配置错误率接近 9%，也就是每刊登 100 个 SKU 有 9 个价格填错。
错误率高不是因为不细心，而是因为人工在五个平台之间来回切换，字段名称、币种、小数位规则都不一样。这是结构性问题，靠培训解决不了。
我们做的最重要的一件事，不是换工具，而是把定价逻辑从"人对表格"改成"规则对字段"。具体是三步：
工具层我们用的是数跨境这类跨境电商 ERP（官网：https://shukuajing.jiushuyun.com/?utm_source=seo&utm;_plan=est&utm;_unit=gys）。选择它的原因不是它有多特殊，而是它的多平台刊登与价格模板结构，正好能把上面这套"平台无关 + 平台相关"的参数分层装进去。
需要提醒的是：不同 ERP 的字段命名、规则表达能力和支持范围差异很大，具体到某个平台是否支持某个价格字段、是否支持多币种自动更新，请以官方帮助中心和你自己店铺实测的结果为准，不要照搬任何一篇教程的字段名。我下面写的操作思路是通用的，工具只是载体。
在 ERP 里配置价格模板，我的顺序是"先建参数、再建规则、后建模板"，顺序颠倒会出现大量返工。
（1）先建成本参数。把平台无关成本维护在商品主数据，把平台相关成本维护在平台维度。这里最容易被忽略的是"退货计提率"，它对高退货品类的影响常常超过佣金本身。
（2）再建价格规则。每个平台一条规则，规则里至少包含四项：底价公式、默认加价率、汇率缓冲比例、SKU 角色对应的毛利下限。规则要能按店铺、按类目、按 SKU 标签覆盖。
（3）最后建刊登模板。模板负责把规则产出的价格写到正确的字段上，并决定哪些价格允许被活动覆盖、哪些不允许。
用一个简化的规则表达式说明结构（以下为通用示意，不是任何 ERP 的真实语法）：
rule: platform_price_template
scope: { platform: "amazon_us", shop: "US-01" }
floor_price: (base_cost + fixed_fee) / (1 – variable_rate – min_margin)
list_price: base_cost * markup_rate # 初始刊登价
promo_price: max(list_price * promo_depth, floor_price) # 促销价不得低于底价
reference_price: list_price * 1.15 # 划线价，需符合平台真实性要求
currency: { base: "CNY", target: "USD", buffer: 0.04 }
guard: list_price >= floor_price and promo_price >= floor_price
这段结构里最关键的是最后的 guard 条件。没有 guard 的批量刊登，等于把定价权交给了运气。
改造完成后运行了一个完整季度，几个指标的变化比我预期的更明显。最直观的不是利润，而是耗时和错误率，因为它们直接释放了人力，人力又被投到了选品和内容上。
改造后我们最意外的发现是：净利率的提升，主要不是靠涨价，而是靠"少犯错"。12.6% 对 7.8% 的差额里，约三分之二是过去被促销击穿、汇率漏算、退货未计提这三类问题吃掉的。
这个观察改变了我对定价的优先级判断。很多卖家把精力放在"怎么定一个更聪明的价格"上，但真正的利润增量在"怎么让已经定好的价格不被错误地执行"。
方法讲完之后，最关键的问题是"我现在该做什么"。不同阶段的团队，第一步该做的事情完全不同。下面按四类情况给出建议。
这个阶段不要上复杂的 ERP 规则。你真正需要做的是把成本参数表按平台拆开建好，并且把"底价"这个概念落实到每一个 SKU 上。
具体动作：用表格维护平台相关成本，为每个 SKU 算一个底价，写在备注里。所有促销报名前先对比底价。这一步不花工具钱，但决定了你后面能不能顺利扩展到多平台。
这是最需要"流程化"的阶段，也是最容易卡住的阶段。人工还勉强能撑，但错误率开始快速上升。
具体动作：引入 ERP 的价格模板，把每个平台做成一条规则，把底价、刊登价、促销价拆成独立字段。这个阶段的目标不是提升利润，而是把错误率压到 2% 以内。
不要在这个阶段追求全自动调价。先把"刊登时不出错"解决掉，再谈"上架后动态调整"。
这个阶段必须做三件事：价格规则按平台分层、调价走审批流、设置异常监控。
具体动作：为每个平台配置独立的加价率与汇率缓冲；批量改价设置审批阈值；建立每日价格异常巡检，重点看低于底价的 SKU 和连续多日无转化的高价 SKU。
这个阶段还有一个常被忽略的动作：定期做"跨平台价格一致性检查"。同一个商品在 A 平台卖 19.9、在 B 平台卖 12.9，如果两个平台的用户群有重叠，会引发比价投诉甚至平台处罚。
有人分工的团队，问题往往不在能力，而在权限边界。定价岗能改到什么程度、运营能自主调整多少、谁来判断一次降价是否值得，这些必须先定清楚。
具体动作：把调价分成三档。5% 以内运营自主，5% 到 15% 由定价岗复核，超过 15% 由负责人审批。所有调价必须记录原因标签，方便后续复盘哪类调价真实有效。
没有原因标签的调价记录，半年后就是一堆无法分析的数字。
上一节讲该做什么，这一节讲该放弃什么。多平台定价的核心矛盾永远是"广度"和"精度"之间的拉扯，想同时最大化，结果通常是两头都不到。
铺货型卖家的核心优势是选品试错速度，代价是单品定价精度。这个取舍不要试图绕过，要主动选择。
我的建议是：铺货阶段统一用较粗的加价率，但底价红线一秒都不能松。你可以接受某个平台利润薄一点，但不能接受有 SKU 在亏钱还持续出单。粗定价 + 硬底价，比精定价 + 无底价安全得多。
全自动调价的诱惑很大，但风险也真实存在。竞品可能在做短期引流，你跟着降价，最后两家一起把价格打穿。
我的取舍是：让系统负责"发现"和"预警"，让人负责"决策"和"执行"。系统每天扫一遍异常价格和异常转化，人只处理被标记出来的那部分。全自动只用在明确规则内的场景，比如汇率自动更新、促销结束后自动恢复原价。
低价冲量在平台早期有效，在多平台环境下往往无效，因为你的成本结构没有变，冲量的规模效应抵不过费率的固定占比。
判断标准：如果这个价格需要卖到当前销量的 3 倍以上才能摊平固定成本，那就不是冲量，是送钱。这种情况下更该做的是换平台或者换品，而不是继续降价。
一致价的好处是管理简单、避免比价投诉；差异化定价的好处是贴合各平台成本结构、利润最大化。
我倾向于：在主战场平台之间保持价格相对一致（差异控制在 5% 以内），在非重叠市场的平台做差异化定价。用户群重叠度是判断的核心依据，重叠度高就必须趋于一致，重叠度低就可以放开。
定价不是一次性动作。刊登完成只是开始，真正的利润管理发生在刊登之后的每一天。
我把调价触发条件分成五类，只有这五类信号出现时才动价格，其余一律视为噪音。
这五类信号里，成本信号和汇率信号应该由系统自动触发提醒，前两类需要人工判断，库存信号要结合现金流状况决定。
下面这份清单是我们团队每次批量刊登前必过的十项检查。建议直接复制到你的团队文档里，按项打勾。
这十项里，第 3、4、7 项是我遇到问题最多的三项。如果只能保留三项检查，就保留这三项。
调价必须复盘，否则你永远不知道自己的价格判断准不准。我的复盘只问三个问题：这次调价的原因标签是什么、调整后的 7 天与 14 天转化变化是多少、单件净利是升了还是降了。
三个问题的答案要写进价格变更记录里。积累到 100 次以上，你就能看出自己团队在哪些原因标签下的调价是有效的，哪些纯属自我安慰。我们团队的数据是：库存信号触发的调价正效率最高，竞品信号触发的调价正效率最低，因为竞品降价往往是短期行为。
回到文章开头那款蓝牙耳机。它在五个平台上产生五个完全不同的净利结果，原因不是我的算术水平在五个平台之间波动，而是我把"一个价格"当成"一套数据"用了。当我改成"一套商品主数据 + 一组平台参数 + 一套价格规则 + 一份复核清单"之后，结果才稳定下来。
如果这篇手册只能给你留下一句话，我希望是这句：多平台刊登定价的核心，不是找到一个正确的价格，而是建立一套让错误价格无法被刊登出去的机制。底价字段、促销校验、汇率缓冲、复核清单，这四样东西加起来的作用，远大于任何一次精妙的定价计算。
下一步你可以直接做三件事。第一，花两个小时把你现在所有平台的相关成本项列出来，按"平台无关"和"平台相关"分成两组，这是所有后续工作的地基。第二，为你销量最高的 50 个 SKU 逐一算出底价，写进 ERP 的独立字段，先把红线立起来。第三，把上面那份十项自查清单放到团队文档里，下一次批量刊登就用它过一遍，看看能拦下多少个本会出错的价格。
至于工具，无论是用数跨境（https://shukuajing.jiushuyun.com/?utm_source=seo&utm;_plan=est&utm;_unit=gys）还是其他跨境电商 ERP，判断标准只有一个：它能不能让你把"底价"作为一个独立字段维护、并在批量改价时拦住低于底价的操作。能做到这一点，工具就选对了；做不到，再多的功能也只是摆设。
我刚开始做多平台的时候，是把亚马逊的价格直接复制到其他平台，结果一个平台单量大但不赚钱，另一个平台根本没流量。后来才意识到问题不在选品，而在刊登价没有做平台适配。可我一直搞不清楚，ERP里到底该怎么给同一款货配出几个不同的价格？
核心做法是把「价格」从商品数据里拆出来，变成规则算出来的结果，而不是手工填的数字。第一步，在ERP里按 平台→站点→店铺→类目 的层级建价格模板，下级默认继承上级，只在有差异的地方覆盖，这样不会出现几百个SKU各配一遍的情况。
第二步，模板里存的是公式而不是固定值，常见的结构是：刊登价 = (采购价 + 国内段运费 + 头程分摊) × (1 + 平台综合费率 + 目标毛利率) + 该渠道固定物流费。
第三步，做字段映射，成本价字段只放采购价和国内段费用，头程、平台佣金、支付费、税费各自单独成列或单独维护成一张费率表，刊登价、活动价、划线价分开映射到平台对应字段，千万不要混用。判断标准很简单：如果某个平台的费率变了，你需要改的是费率表，而不是改公式或重填商品，这套结构就是对的。
批量刊登前一定先跑一次价格试算，把算出来低于你利润底线的行单独挑出来，这一步能挡掉大部分亏损上架。
我一开始是用Excel算价，一个商品一张表，后来越铺越多平台，改一次采购价就要改十几个文件，还算错过几次。我想把这套东西挪进ERP，但不确定哪些成本该写进商品主数据、哪些应该做成单独的规则。
我的做法是分两层。第一层是商品级固定项，写进商品主数据：采购价、包装耗材、国内段运费、质检和自然损耗，这些跟卖到哪个平台无关。
第二层是平台/订单级变量项，做成可维护的费率表或规则表：头程与国际物流（按重量、体积、渠道计费）、平台佣金、支付通道手续费、目的国税费与预扣、退货率折算、广告费占比、促销折扣、汇率缓冲。
判断依据是「这个数字会不会因为平台或时间变化」，会变的全部抽出去，只留不变的进主数据，否则一个商品的成本一调整，你就要动N行数据，出错概率极高。
数据口径上有个关键点：退货率和广告费占比不要用行业平均值，要用你自己店铺最近90天的实际数据反推，因为不同类目、不同站点的退货结构差别很大，用平均数会系统性低估成本。汇率缓冲按你的结算周期来设，结算越慢缓冲越大，而且这个缓冲要写在规则里自动生效，不能靠每次手工加。
最后提醒一句：平台佣金、税率、物流报价这类数字时效性很强，务必以平台官方政策页和物流商最新报价为准，并给费率表标注生效日期，过期就复核。
我吃过两个亏：一次是看竞品降价就跟着降，结果利润没了；另一次是大促前频繁改价，导致平台的促销校验出问题，活动没报上。现在我不敢随便动了，但不动又眼看着转化掉下来。想搞清楚到底什么信号才该触发调价，以及操作上要注意什么。
先建触发条件清单，别凭感觉调。我常用的信号有五个：竞品价格下移超过你设定的阈值；流量没变但转化率连续下滑；库存周转超过预期周期、需要清；汇率变动幅度超过你预留的缓冲；平台大促要求价格带达标。命中任一条件才进入调价流程，否则不动。
操作上关键是「先出工单再改价」，在ERP里设价格监控任务，监控结果只生成待调价工单，由人确认后再执行，不要做成自动改价。防翻车有几点必须守：涉及参考价、划线价机制的平台，频繁改价会让系统重新计算你的价格历史，促销价校验可能失效，所以改价要保留旧价记录，大促前一段时间锁定价格不要动；
调价权限要分层，运营提交、负责人确认，避免凌晨被人一键批量改价；批量执行前先抽3到5个SKU试跑，确认平台端展示正常再全量。最后，调价不是只调售价，降价的同一步要想清楚是压利润还是同步换更便宜的物流渠道，否则只是把亏损放大。
读者评论
去年我们也踩过一价通铺的坑，同款产品五个平台一个加价率，结果速卖通赚钱、亚马逊白干、Shopee亏。文章里促销叠加击穿底价那段特别真实，我们一次大促后忘了回价，亏了半个月。现在把促销折扣成本直接计入底价公式，感觉比事后调价靠谱。
从ERP实施角度看，三层结构说得清楚，但落地难在平台相关成本字段。很多系统只给成本价和售价两个字段，要按平台维护佣金、履约、退货计提就得自定义或用规则引擎。我们新增一个平台时改了七八处，明显还是计算器模式，不是规则引擎。
财务角度补充一点：汇率和退货计提最容易漏。文章帕累托图里汇率未更新占32%，我们也是，单次影响小但天天发生。退货如果按品类实际退货率计提，不少低价SKU的利润直接由正转负。建议把汇率自动更新和退货计提做成系统必填，不然反推净利率根本不准。
SKU角色分层毛利目标这点很实用。我们以前清库存款设50%毛利，结果半年清不掉；测新款设10%毛利，每单都亏。后来按爆款守利润、长尾守周转、测新款守曝光、清库存守现金流来定，亏损可控了。改价审批和版本记录也同意，批量改价没日志真的会出大事。