TikTok 发货超时,扣分只是最表层的一环。多数卖家关心的是被记了多少违规点,实际影响链条要长得多:指标超标会先压缩流量入口,再限制订单量,走到底才是店铺暂停。把这根链条看清楚,才知道哪一步最该防。

一、两项核心指标,先记住阈值

TikTok Shop 对发货履约的考核,主要看两个比率。

迟到发货率(Late Dispatch Rate,LDR),阈值是 4%。也就是在统计周期内,迟于规定时限发出货物的订单占比超过 4%,指标就亮了。

卖家责任取消率(Seller Fault Cancellation Rate,SFCR),阈值是 2.5%。因卖家原因导致的订单取消占比超过这个数,同样触发。

两个指标的统计口径都以订单数为分母,所以基数小的店铺更要注意——同样一笔超时订单,在大店铺里可能只是小数点的波动,在小店铺里就可能把比率推过线。

另外一项变化值得留意:账户健康评分(Account Health Rating)的评估窗口已调整为 180 天滚动(原为 90 天)。窗口变长,意味着单次违规的记录留存时间更久,恢复指标需要的时间也相应延长。

  • 要点:LDR 阈值 4%、SFCR 阈值 2.5%,是两条硬线

  • 要点:订单基数小的店铺,单笔超时的指标影响被放大

发货超时,店铺指标,处罚后果

二、后果链条:从流量到结算逐层收紧

指标超标之后,处罚不是一步到位,是逐层收紧。

第一层,流量侧。 搜索可见性下降、商品曝光被压制、失去促销活动的参与资格。这一层的影响最直接,表现为订单量下滑,但后台不会有一条明确的通知告诉你「因为发货慢,所以流量被砍了」。

第二层,订单侧。 平台对账户实施订单量限制(Open Volume Limit),也就是限制你能承接的订单规模。这一层开始影响日常经营节奏,补货计划和广告投放都要跟着调整。

第三层,资金侧。 结算周期被延长,回款变慢。对现金流紧的卖家,这一层的影响可能比前两层都明显。

第四层,账户侧。 指标持续不达标,最严重会走到店铺暂停。

违规点是在这条链条之前累积的:每笔超时订单都可能带来违规记录,记录叠加到一定程度,才触发上面四层。所以真正要防的不是某一笔超时,是违规点的累积速度

  • 要点:后果依次落在流量、订单、资金、账户四侧,影响逐层加重

  • 要点:违规点累积到临界才触发,防的是累积速度不是单笔

三、平台要求的具体时限

时限是判断超时与否的基础,不同站点的口径不同。

以美国站为例,常规要求是下单后 2 个工作日内进入在途状态,6 个工作日内送达。这两个节点分别对应「发货」和「妥投」,是两个独立的考核点。

「在途」的判定以承运商首次扫描为准。这里有一个卖家最容易踩的坑:标签已经生成、但承运商还没扫描的这段空隙。在系统里看,订单似乎已经处理,但物流轨迹上没有记录,一旦超出 2 个工作日,仍然算超时。真正稳妥的做法是把包裹交给承运商并确认扫描,而不是打完单就算完成。

  • 要点:2 个工作日在途、6 个工作日送达,是两个独立节点

  • 要点:标签生成不等于在途,要等到承运商首次扫描

四、有保护机制,也有红线行为

平台对卖家责任有区分机制。承运商保护机制是一条:如果你使用的是平台指派的承运商,且物流事件明确显示问题出在承运商侧,由此造成的指标损伤可以豁免。这条机制的前提是「用平台指派承运商」,自发货渠道不适用。

另一侧是明确的红线行为。平台会识别几类滥用追踪号的操作:包裹实际不存在却上传单号、上传从来不扫描的单号、把同一个单号复用到不同订单、用刷单号填充履约数据。这些行为一旦被识别,处理力度比单纯超时重得多。

下面这张表把常见情形和对应的影响放在一起,对照自查用。

情形指标影响是否有豁免空间
平台指派承运商导致延误计入但可申请豁免有,需物流轨迹佐证
自选承运商导致延误计入 LDR 或 SFCR
标签生成但未扫描超过 2 个工作日算超时
上传不扫描的单号计入并可能升级处罚
单号跨订单复用计入并可能升级处罚
  • 要点:走平台指派承运商是拿到豁免的前提

  • 要点:追踪号滥用比单纯超时的处理力度重得多

五、把超时压下去的四个动作

落到日常经营,能做的其实不多,但都有效。

一是把备货节奏对齐时限。 2 个工作日的窗口很短,备货、拣货、打包、交运这几个环节需要留出缓冲。旺季前把打包人力配足,是成本最低的做法。

二是订单生成后立刻进处理流程。 不要等批量处理,订单流入即时分配到打包环节,能省出关键的一天。

三是交运后确认扫描。 每天固定一个时间点核对当天交运包裹的扫描记录,发现异常当天就问承运商。这一条能挡住大部分「标签打了但没上网」的超时。

四是盯住未收到货纠纷指标。 履约问题最终会反映到买家侧,纠纷率是更靠前的预警信号,比等 LDR 亮灯要早。

判断标准可以简化成一句话:超时的代价不在那一笔订单,而在指标的累积和权限的收紧,所以要防的是流程稳定性,不是某一次补救。