后台刚延长了交货时间,下一次文件上传后又变回原值;运输组已改,商品页面却没有采用新的时间。Kaufland的交货承诺由不同位置的数据共同形成,也可能经过智能调节。要解释买家看到的日期,得先找到这条报价当前采用什么数据,再把仓库交接、运输线路与实际妥投接起来看。
Kaufland的报价信息官方说明把交货时间分成两段:订单处理时间与运输时间。处理时间属于商品报价,覆盖接到订单后分拣、包装、交给承运商的准备;运输时间放在运输组里,表示承运商把包裹送到相应地区买家手中的时间。这两段相加,才形成通常显示的交货范围。
这对同仓发货的商品也有区别。拿两件家居用品作例子,一件已包装好,另一件要检查配件再装箱,走的是同一条快递线路,仓库准备却可能不同。运输组里的线路时间可以相同,报价上的处理时间仍应反映各自的出库工作。把运输时间一并延长,虽然让数字变大,却没有说明问题出在交接前还是交接后。
订单准备先在仓库完成,再交给承运商。
官方提供的计算示例是:处理需要1天,运输需要1—2天,买家看到的交货时间为2—3天。这里的1—2天是示例中的运输设定,并非所有德国订单的固定时效。卖家可以用自己商品的实际准备时间与目的地线路,理解为什么同一个运输组下的两条报价会显示不同时间。
有一个更容易漏掉的条件:若报价仅提交最短、最长交货时间,虽然运输组已设运输时间,系统也不会把它加入计算。官方明确,只有报价同时填写处理时间,运输组中的运输时间才会参与相加。遇到“组里改了,商品没变”,先看当前报价采用的是哪套字段,比反复保存运输组更有用。
随后确认报价实际关联哪一个运输组。运输组名称需要与报价文件中shipping group列的名称一致,手动上架也要选择对应组;接口上架同样要保持关联。若运营改的是一组,商品引用的却是另一组,页面显示旧安排就有了具体原因。商品、组名和目标地区应该连起来核对,不能只凭组的保存结果判断整批商品已更新。
处理时间的调整方式与上架方式有关。英文版报价管理说明分别列出接口、文件和手动管理:使用API上架的报价,需要在相应软件里设置处理时间,无法通过卖家后台集中控制这一项。运营已经在前台排查出时间不合适,接下来应找到实际向平台发送数据的系统。
通过Inventory-Feed文件管理时,可以在报价管理的导入配置里填写统一的默认处理时间,保存后重新上传报价文件。但这个默认值只适用于文件没有填写处理时间的情况。文件中已经有商品自己的值,不能因为后台设置过默认值,就认为全部商品都会采用同一个数字。
这项规则适合用一个明确的对照来查:先打开有问题商品所在的文件行,查看处理时间是否已有值;再看导入配置中的默认值。若商品行填的是原来的准备时间,排查对象就是文件内容。若该列为空,才继续检查统一默认值及文件是否重新上传。两处看清,便不需要凭印象猜测哪项设置优先。
手动上架的报价则可以在报价概览中选择商品,用批量编辑调整处理时间。这里应先圈定准备流程相同的商品。普通现货与需要组装的商品一同选中,修改虽然方便,却可能把两种实际准备工作压成一个承诺。批量功能解决的是重复操作,商品之间的差异仍要在选择范围里体现。
官方还明确提醒:手动修改之后,如果接口或文件再次提交其他处理时间,手动值会被覆盖。因此,交货时间“改了又变回”时,可以把变化与最近一次导入对应起来。后台修改记录说明操作发生过,文件或软件中保留的旧值,则可能解释它为什么没能持续保留。
一个实用的处理是让维护人员确认最终的数据来源。例如仓库提出某类商品需要多一天准备,运营应把这个调整落实到持续上传的文件或软件配置,再看报价里的结果。只在后台临时改一遍,下一轮更新仍带旧值,团队就会反复处理同一个问题。运输时间另外按运输组维护,也要确认改的是相关商品真正采用的组。
交货时间采用工作日计算,星期六不计为工作日。官方报价说明还写明,系统考虑的是销售站点所在国家的全国性法定节假日。例如Kaufland.de采用德国全国性节假日,Kaufland.cz采用捷克节假日。这让“设置了三天”与“从今天起三个自然日后到货”存在区别。
对跨国发货卖家,容易混淆的是仓库在哪里休假,与买家在哪个销售站点下单。Kaufland的全国性法定节假日期间绩效说明给出德国公司经营捷克站点的例子:德国法定假日不会自动从捷克站点的统计中排除,卖家需要提前调整交货时间;捷克当地的相应假日才会由该站点考虑。
例如,一家德国仓库在当地假日不交货给承运商,但还在接受捷克站点订单。这一天的仓库停工是真实的处理能力变化,平台却不会仅因公司或仓库位于德国,就为捷克站点自动延长承诺。卖家应在假日前,把受影响商品的准备或交付安排调整到能实现的范围。
同样,不能把地方性休假一律当作系统已处理。官方节假日说明明确区分全国性与非全国性节假日。仓库所在地区休息、承运商当天不揽收、团队另行安排停工,都应结合实际交接确认。判断日期时,先看站点规则,再看仓库与运输环节还有哪些时间没有被自动覆盖。
这里也关联当日发货截止时间。运输设置中的截止时刻,表达的是订单在什么时候收到,仍能当天交给选定承运商。仓库已经完成包装,但错过当天交接,就不能只用“已打包”解释当日发货能力。订单进入、包装完成、交接班次三处时间对齐,截止时刻才有实际用途。
交接时点把订单处理与运输两段连接起来。
跨站点经营时,可以把同一仓库服务的销售渠道分别列出来,逐个看假日和交接。一个报价适合德国站点,不代表移到另一个站点后承诺仍准确。需要调整的是受影响的商品和线路,运营与仓库共同确认之后,再用报价当前显示的时间检查结果。
为了少出现延迟,有些卖家会把交货范围整体写长。但Kaufland的物流绩效指标同时关注准时、延迟和提早交货。准时的判断,是商品是否在所设时效范围内妥投;比窗口更早到达,也属于需要观察的另一种偏离。
因此,设定时间不只是找一个足够晚的截止日期,还要让窗口贴近通常交付。假设一条线路多数包裹较早到达,卖家却一直沿用很长的准备和运输时间,实际结果就可能频繁落在窗口之前。商品确实送到了,页面向买家表达的等待时间却没有准确反映这条线路。
官方会参考过去30天物流绩效,并考虑每周数据的较大波动,给出交货范围建议。查看建议时,先找到涉及哪些商品及线路,再区分延迟发生在哪一段:仓库准备变慢、错过交接,还是承运商送达变慢。运输问题与商品准备问题用不同位置的数据表达,才能避免一改动就影响同组所有商品。
范围跨度也需要合理。官方举例,交货范围小于10天时,建议跨度不超过3天,例如2—4天。这是帮助卖家设置窗口的建议,文章中的数字不代替某条具体线路的结果。实际维护时,可以结合报告中已经妥投的商品,看看早到与晚到分别集中在哪里。
承运商造成的延迟,也属于设置交货承诺时要考虑的情况。平台说明并没有把这类延迟从卖家的时间设置责任中直接移走。仓库准时交接可以帮助定位原因,最终买家何时收到,仍要回到运输安排和妥投记录。不断使用理想时效,会让页面承诺与最近的实际线路表现越离越远。
在运输设置官方说明中,Smart Delivery Time Automation会分析以往配送表现,同时考虑提早和延迟交付,优化报价的交货窗口。功能位于运输设置的Delivery times页签,通过自动优化运输时间选项启用,并在需要时调整相关时间。
官方FAQ说明,系统只调整它发现优化空间的交货窗口;没有这种空间时,原有处理和运输时间不会改变。看到一些报价被调整、另一些仍保留原值,不应直接认定功能没有运行。先查看实际涉及的商品,再把当前窗口与报告中的配送表现对应起来。
历史包裹能够反映过去怎样发出,却不能替仓库说明今天新增的加工或缺货。比如某款商品原来现货充足,接下来改为接单后组装,准备环节已经不同。这时应先更新商品当前的处理能力,让持续上传的数据采用新的处理时间,而不是只等系统根据过去顺畅的配送自动认识这次变化。
供应短缺时,官方提供Pause Now暂停自动调节七天的安排,也可以关闭该功能。暂停解决的是是否继续让系统调节窗口,商品能否继续按现有报价履约,则还要另外看库存和准备情况。使用这一选项时,应同步认识受影响商品,确认这几天实际能够接受怎样的订单。
官方FAQ还说明,经智能调节优化的相应报价不会因为偏离相关交货指标而被停用。这里的说明指向这项配送指标流程,不能延伸成所有客服或履约问题都不再需要处理。卖家仍应查看具体订单的交付与买家问询,并让包裹状态表达实际进度。
Kaufland的服务绩效基本说明指出,绩效单独按产品计算。一笔订单包括10个产品,会按10个订单单位计算。若同一产品填写多个追踪号,系统默认采用最后妥投的物流信息。这也解释了为什么只数“几笔订单迟到”,不一定能对应平台显示的结果。
对分包商品,应该确认哪个追踪信息属于哪个产品。例如一件商品的配件另箱送出,两箱到达时间不同,卖家应按实际产品与包裹关系核对,不能只拿先到的一箱代表整件商品的交付。订单打包方式与追踪号的对应,是解读绩效时需要带上的业务信息。
发出之后,还要按商品对应实际妥投信息。
标记发货时,填写承运商与追踪信息能够让买家收到追踪链接。订单已经交给物流,和买家已经收到商品,是两个具体时点。查看延迟时,应沿商品的妥投记录回看所设窗口;查看仍未发出的产品,则应先检查仓库动作与标记发货是否正常,找出它现在停在哪一步。
物流绩效页要求卖家尽快处理超过交货日期仍未发出的产品,并通过Ticket通知买家延迟情况。这类订单不能仅靠延长未来报价来处理。当前商品是否还能完成交付、买家是否已得到实际进度,需要围绕这笔订单继续安排;后续报价的时间,则用来表达今后的准备与运输能力。
最终核对设置,可以在报价里查看,也可以下载上架产品报告检查当前交货时间。将有问题的商品、它采用的数据来源和运输组,以及实际妥投结果放在一起,通常能找出“改了没生效”或“设置与交付偏离”的具体位置。正确维护交货承诺,依赖的是这几处持续对应,而非某一次把数字填长。
声明:本文系作者独立观点,不代表ESG跨境立场。文中涉及的平台规则、费率及出海政策具有时效性,实际运营请以平台官方最新公布为准。如有版权争议、内容勘误或业务交流,欢迎随时与我们联系。
二维码加载中...
使用微信扫一扫登录
使用账号密码登录
平台顾问
微信扫一扫
马上联系在线顾问
小程序
ESG跨境小程序
手机入驻更便捷
返回顶部