从轨迹分析，投递邮件异常留存的原因

投递留存邮件的清理过程中，很多粉友们会发现，实际有很多邮件在轨迹上都已经妥投了，但怎么在留存邮件库表中仍有显示与统计？真要命啊，清也清不掉，理也理不顺。下面，小编与众粉友们一起环顾一下，从各类邮件的轨迹上一起分析滞留原因。

这里，小编要着重强调一下：异常原因可能是多种多样的，有可能是一个原因造成的，也可能是多个原因叠加造成的。因无法实际了解，小编只能带着大家按照标准作业规程，从邮件轨迹上查找分析留存信息滞留的原因。

首先，我们通过【更多】—【监控统计】—【投递质量监控管理】—【业务量统计分析】—【存局邮件统计】模块，查询相关机构留存邮件信息。

通过点击【当前存局数】所在列的数字，可下钻至相关邮件详情信息，如下：

通过对此件留存信息的轨迹查询，我们发现此件在同一机构已妥投且回班交接，符合我们通常认定的邮件妥投合规的作业标准。那为什么此邮件信息仍滞留在存局库表当中呢？

下面，我们就具体分析下案情：

刚开始，小编也认为此件从整体作业流程看，没啥问题，相关邮件解车接收后，下段、未妥投反馈、回班交接，次日出库后再重复上述动作，直到妥投且回班交接后结束。

当小编突然要放弃的时候，灵光一现，，如果发现一个说不上异常，但在基层经常发生的一个动作。依据标准操作规范，此动作结合其他操作就属违规，或是降低作业效率的动作了。最终，小编认为，邮件信息滞留在库表中的原因非此莫属。

此个动作，不知道粉友们发现没有：就是1月15日，此件采取出库操作后，相关人员又立即实施了【撤销下段】动作。

【撤销下段】动作应用场景主要包括：邮件不应下段，但进行下段时，可采取撤销动作的场景。按理，大家可能会说，那我下错段了，也可以撤销下段，然后再另下段。这个理解，没问题，但上述滞留的信息就反馈出新一代系统不是这么设计的。

小编分析，按新一代系统的设计理念，下错段，应适用【转接任务】功能，不应应用【撤销下段】。可能很多粉友会说，系统太僵化了，可小编认为此功能的设计符合作业效率提升要求，原因只有一个：

采取【撤销下段后，再下段】是两个动作工序；而【转接任务】是一个动作工序。

说的有点远，此邮件信息只留库存，按小编的分析就是15日下段后，操作人员撤销下段。导致相关邮件未从存局库表中销号（邮件存局详情表中的存局时间卡点显示予以了佐证）。

另外：需要注意的是，通过此邮件轨迹，该班组在业务内控上亦存在问题，即内勤参与了排班作业（正常情况下，新一代的系统操作，内勤人员无需参与道段排班）。