货到付款不亏钱：如何减少派送失败和退回发货地（RTO）

上周，一家网店发出了 1,000 单货到付款订单。周一早上 9:10，运营负责人打开周报：78% 签收。剩下的 22% 正在退回途中：80 单客户在门口直接拒收，60 单电话没人接，50 单快递员找不到地址，还有 30 单丢在了某个中转站。这里的数字只是举例，但凡是做现金收款生意的人，对这幅场景都不陌生。

这 220 个包裹，每一个都经过打包、付了运费、一去一回跑了两趟，库存还白白压了两周，期间无法再卖。已签收的 780 单，利润有相当一部分已经填进了这 220 单的窟窿。

本文的观点很简单：退回发货地（RTO）的结局，在包裹出库之前和首次派送失败后的 48 小时内就已经定下，而不是在客户门口。订单先确认、风险先评估、快递的第一条未妥投通知及时回应，这 220 单里大部分要么根本不会发出，要么不会退回来。

一个货到付款失败包裹到底亏多少

货到付款在中东、南亚和东南亚、拉美、非洲，以及中东欧部分地区至今仍然常见。买家选它，是因为不信任银行卡支付页面、没有银行卡，或者想先看到货再付钱。对卖家来说，这等于把全部风险推到了最后一公里。

先说清两个术语。未妥投通知（NDR）是快递在一次派送失败后给出的状态：客户不在、地址不全、拒收。此时包裹仍有机会挽回。退回发货地（RTO）则是派送次数用完后，包裹运回你手里，费用由你承担。

看一个举例订单，所有数字使用同一货币单位：

项目	签收订单	失败订单（RTO）
收回的订单金额	40.00	0.00
商品成本	-22.00	0.00（货已退回）
去程运费	-3.00	-3.00
回程运费	0.00	-2.50
包装	-0.50	-0.50
拣货打包	-1.00	-1.00
验货并重新入库	0.00	-1.00
代收货款手续费	-0.80	0.00
退回途中的损耗（22.00 的 8%）	0.00	-1.76
贡献利润	12.70	-9.76

两种结果相差 22.46。也就是说，一单失败包裹会吃掉 0.77 单成功订单的贡献利润，而这还没算上那些没人记账的损失：商品两周无法销售，货款晚到甚至收不回来。

包裹为什么送不出去：三类不同的问题

20% 的 RTO 率不是一个问题配一个解法。它至少是三个问题，每个都要用不同的办法。

买家本来就没打算收货

冲动下单、恶作剧下单，或者中途在别处看到了更低的价格。货到付款取消不花买家一分钱，所以在门口拒收是零成本的。对策要落在意愿上：订单确认、定金、激励。

联系不上买家

手机号错了一位，派送时段手机关机，快递员只打了一次电话。对策在联系渠道上：校验过的号码，WhatsApp 或短信这样的第二渠道，以及改约时间的机会。

包裹找不到买家

没有地标的自由文本地址，区县写错，或者快递在该区域服务本来就弱。对策是提高地址质量，并按区域选快递，而大多数店铺恰恰从不统计这一项。

从下单到回款的漏斗

把一笔货到付款订单当作每个环节都会漏的支付漏斗来看。数一数进来多少单、出去多少单，漏损就不再是凭感觉的事。

在这个与周一场景吻合的示意中，1,000 单全部发货，690 单首次派送成功，重新派送后达到 780 单，30 天内有 770 单完成款项对账。靠重新派送救回的 90 单，说明快速响应值多少钱；已签收却没有回款的 10 单，说明财务为什么需要自己独立的一环。每个环节都要有负责人：订单确认归客服，首次派送归快递，重新派送归处理 NDR 的人，款项结算归财务。没人负责的环节，漏损也就没人看得见。

发货前先确认、先打分

最便宜的 RTO，是你根本没发出去的包裹。在结账和拣货单之间加两道关口：风险评分和订单确认。

用现有信号做风险评分

起步不需要模型。订单库里已有的字段加一张积分表就够用，客服团队也能看懂。以下是起步权重，请按自己的历史数据调整：

• 手机号格式校验不通过，或曾以另一个客户姓名使用过：+20
• 该客户的首单：+15
• 订单金额超过平均值的 3 倍：+15
• 所在区域的 RTO 率超过平均值的两倍：+15
• 地址没有地标或门牌信息：+10
• 此前有货到付款订单被拒收或退回：+40
• 此前已成功签收三单及以上：-30

举个算例：首次下单的买家在凌晨 2 点下了单，金额是平均值的 3.4 倍，来自弱势区域，地址又很短。得分是 15 + 15 + 15 + 10 = 55。低于 20，订单直接发货；20 到 49，需要确认；50 及以上，要求先付定金或全额预付。看到效果后，阈值可以自己调整。

几秒钟就能完成的确认

确认可以是一通电话、一条带两个按钮（“确认”和“取消”）的 WhatsApp 消息、一条短信回复，或一段自动语音。消息里要重复商品、到时需付的总金额、地址和派送时段。肯回复的买家，是在等这个包裹的买家。

每一步都记录在订单上：评分、产生评分的信号、发出的消息、回复内容和时间。开始分析 RTO 时，这份记录能让你看清哪条规则有效，哪条只是惹恼了好客户。

预付、手续费与激励

对高风险档的买家，要给他一条保住订单的路。用银行卡或手机钱包先付 10% 到 20% 的定金，既证明了诚意，包裹万一退回，回程运费也有着落。在结账页（而不是门口）显示一笔小额代收手续费，会让预付变成更便宜的选择。给预付订单打折或包邮，也是从另一头起到同样的作用。

把这些当作实验来跑，不要当作定死的政策。对所有订单收手续费，转化率可能下降。只对高风险档收，影响的只是一小部分订单，却能筛掉最可能拒收的那批。

快递说“送不了”之后：头 48 小时

首次派送失败的那一刻，是挽回包裹的最佳时机。各家快递的状态名称不同，但套路一致：带原因代码的 NDR 出现，快递约定一两天后再派送，最后一次派送失败后包裹转入退回。

把每种原因对应到几小时内要做的动作：

• 客户不在：发消息，附上改约链接或时段。
• 地址不全：请对方补充地标或发定位，并把更正同步给快递。
• 拒收：给一次折扣或改期的方案；对方仍不收，就接受退回。
• 电话打不通：在下一次派送前，改用第二个渠道联系。

当天回复的 NDR，会让下一次派送有真正的成功机会。没人看的 NDR，默认就会变成 RTO。

按区域选快递，别只看报价单

快递在有些区域很强，在另一些区域很弱。把包裹按快递公司和派送区域分组，比较每个格子的首次派送成功率和 RTO 率，再据此分单：在表现好的区域用便宜的那家，在表现差的区域换更好的那家。

下面这段简短的 StoreConsole 配送演示，展示了快递、区域和实时状态数据放在同一个屏幕上是什么样子。

把回款这个环闭上

签收不等于收到钱。快递代收货款，扣掉自己的费用，再分批打款，往往要一周甚至更久。把每份打款明细和它声称覆盖的订单逐一对账。对完账会得到三类结果：足额到账的订单、少付的订单（手续费或四舍五入造成的差额），以及已签收却不在任何一份打款里的订单。

每笔订单都要保留这些字段：快递公司、运单号、应收金额、实际打款金额、被扣手续费、打款流水号和日期。显示已签收 14 天仍没有打款流水号的订单，要进入催收清单。没有这套对账，未收回的包裹就只会躺在表格里，直到有人发现现金出现缺口。

六周行动计划

一次只调整一个杠杆，这样才能分清到底是哪一步起了作用。

1. 第 1 周：按漏斗各环节、按快递和区域、按原因代码测出基线。暂时什么都不改。
2. 第 2 周：先治数据。校验手机号，把地标设为必填，并把 NDR 原因记录到订单上。
3. 第 3 周：对中风险档开启订单确认，比较已确认和未确认订单的表现。
4. 第 4 周：加上 NDR 处理手册，指定一名负责人，响应时限四小时。
5. 第 5 周：对高风险档一半的订单提供定金或预付优惠，另一半作为对照组。
6. 第 6 周：把一个表现差的区域切换到另一家快递，并对照第 1 周复盘全部结果。

该盯哪些指标

指标	计算方式	为什么重要
RTO 率	退回包裹数 ÷ 已发货包裹数	最直接的损失，按快递和区域拆开看
首次派送成功率	第 1 次派送即签收数 ÷ 已发货数	反映地址和联系方式的质量
确认率	已确认数 ÷ 发起确认的订单数	说明有多少订单背后是真实意愿
NDR 挽回率	NDR 之后签收数 ÷ 产生的 NDR 数	衡量的是你的响应，不是快递的表现
回款天数	打款日期减去签收日期	每单占用的营运资金
单均净贡献	总贡献利润 ÷ 已下单数	决定一项改动值不值得的那个数字

评判任何改动，都要看单均净贡献，而不是只看 RTO。回到前面的示例：确认成本每单 0.30，在 20 单注定失败的订单中，6 单发货前被取消，2 单在门口被救回。这样每 100 单里，82 单签收，每单贡献 12.70；12 单失败，每单 -9.76；另外确认环节花掉 30。合计 894.28，而不是 820.80，每 100 单多赚 73.48，约 9%，价格一分钱没动。

回到周一早上

六周后，运营负责人打开同一份报表。1,000 单里有 60 单在确认环节就取消了，根本没有打包。每个失败的首次派送都有原因代码，也都有回复；最弱的那个区域，现在改由另一家快递负责。RTO 从 22% 降到了 12%，上周签收订单的货款也已经和打款明细对完。

商品和价格都没变。变的只是：现在每个订单出库前要过一道关，失败之后身后有一个在走的计时器。

核心要点

• 一个货到付款失败的包裹，成本包括双向运费、处理费、损耗和被压住的库存；示例中它吃掉了一单好订单超过四分之三的利润。
• 把 RTO 拆成意愿、联系和地址三类问题，因为每一类的解法不同。
• 用手头已有的字段给每个订单打分，确认中风险档，向高风险档要定金。
• 每条 NDR 都在几小时内回应，并把各区域分给在当地表现好的快递。
• 把快递打款和订单对账，并以单均净贡献来评判每一项改动。

Anichur Rahaman 是一名软件架构师，也是 StoreConsole 的创建者。他为成长型企业设计电商与 ERP 系统，专注于事件驱动架构、数据完整性和自托管部署。