DW功能的全称是送达时段自动更新，是亚马逊 FIST 体系里三项服务之一。它做的事很小：让完成对接的承运商，根据实时物流动态替卖家更新货件的预计送达时段。小到很多人开通以后就忘了它的存在，直到某天发现时段一直没变、货已经在仓门口等着，才回头查它到底有没有生效。这篇把它的含义、开通动作与责任边界讲清。

一、DW 改的是送达时段这一个变量

货件创建时要填一个预计送达时段，亚马逊按这个时段安排收货资源。填得太早，货没到，仓里空等；填得太晚，货到了挤不进当天的收货计划。

传统做法是卖家自己盯。货在海上、在清关、在铁路上，卖家要一层层问货代，问到大概时间再回后台手动改。单量大的时候，这件事会占掉运营不少精力，旺季尤其明显。

DW 把这一步交给承运商。承运商的系统里有轨迹、有清关状态、有末端派送安排，由它来推算送达时段，比卖家凭电话问来的消息准。卖家省下的不只是操作时间，还有反复沟通带来的误差。

需要说清的是，它只改这一个变量。货还是那批货，船还是那条船，DW 不会让船开快一点，它只是让后台显示的时间更接近真实。

FIST承运商,送达时段,DW功能

二、三项服务怎么分工

FIST 是亚马逊为 FBA 头程做的追踪体系，全称是入仓货件追踪智控系统。它对接了一批第三方承运商的系统，把货件轨迹拉到卖家后台统一显示。这套体系下有三项服务。

一项是轨迹对接。承运商把发货、离港、到港、清关、送仓这些节点同步过来，同时自动回传货件追踪单号。这一项带来的实际好处是：因追踪单号填写不准造成的入库缺陷，可以豁免，不影响卖家绩效。

一项是 DW。由承运商替卖家更新预计送达时段，前提是这家承运商完成了该项功能的对接。

还有一项是智能转仓。遇到计划外延误时，系统根据动态数据给出转仓选择，避开拥堵的仓，降低入仓延误。这一项不是所有承运商都有。

三项全部具备的，亚马逊单独列了一个层级。选承运商时先看这个层级，再看报价，顺序别反。

三、后台两处勾选缺一不可

功能开不开得起来，取决于货件创建页面的两处勾选，两处都要对。

一处是送达时段那一栏里的授权项，要勾上允许 FIST 承运人更新我的送达时间。另一处是承运人那一栏，要保持默认的非亚马逊合作承运人下面的 FIST 承运人选项，不要改成别的。

只勾一处不行。只勾授权、承运人选项改错了，系统不认这票货走的是 FIST 通道；只勾承运人、授权没勾，承运商没有权限动你的时段。

12 月 9 日中国时间之后新建的货件，系统默认把授权打上了勾，所以多数人不需要额外操作。此前创建的、以及正在途中的货件，可以手动去补勾，让承运商接着推。

四、开通之后责任还在卖家

这一条最容易被误读。无论时段是卖家自己填的，还是承运商自动更新的，货件在该时段的表现，仍由卖家承担。

所以首次创建货件时填的那个时段，还是要按最佳预估来选，不能随手挑一个近的日期指望后面改。时段填得太近，承运商揽收后就失去了更新的空间，等于把功能关掉了。

还有一种情况用不上：通过稍后包装方式创建的货件，目前不支持这项功能。走这条路线的卖家，时段仍要自己管。

责任边界还有一层：时段改得准不准，会体现在货件的收货表现上。时段填得离谱、承运商又没来得及修正的，最终计入的还是卖家这一侧的数据。

如果发现授权了、承运商也接了，时段却始终没动，处理办法很直接：联系承运商跟进，而不是在后台反复改。

五、它省的是沟通成本不是时效

把 DW 理解成提速工具，会失望。它不改变船期、不改变清关速度、不改变仓库的收货能力。

它改变的是信息流转方式。以前是卖家追着货代问，问到了再回后台填；现在是承运商的系统直接把结果推给平台，中间的转述环节被拿掉。

对单量大的卖家，这层价值更明显。几十票货同时在途时，人工逐票更新几乎做不到，能自动更新的那部分，等于把运营从重复劳动里解放出来。

换个角度看，它把「谁知道货在哪」这件事重新分了工。承运商手上有一手动态，卖家手上只有电话与聊天记录，让信息从有数据的一端流向需要数据的一端，本身就是效率。

所以判断要不要用，标准不在「能不能更快」，在「这票货的时段有没有人盯」。没人盯的，交给系统比放着不管强；有人盯且盯得准的，功能只是锦上添花。