该技能解决的是外呼流程中一个常见但代价高昂的分类错误：自动回复邮件与真实回复出现在同一收件箱、同一会话线程中，如果被当作真实回复归档，会同时破坏三件事——回复率统计、账户状态和后续触达安排。
用途
将机器邮件（自动回复、投递通知等）作为独立结果进行归类，与感兴趣、提问、转介绍、暂不考虑、不感兴趣、退订等人工结果并列。缺少这一分类的筛选词汇表不会跳过自动回复，而是会把它归入最接近的错误标签。
主要能力与规则
- 必须给机器邮件独立的结果标签，绝不使用最接近的人工标签。
- 必须保持序列处于活动状态，且该次触达视为未消耗。
- 必须将自动回复排除在回复率、正向反馈和互动指标之外。
- 必须只使用邮件中明确写出的返回日期，绝不推断日期。“20 号回来”是日期，“离开一段时间”不是，猜测日期等于把错误时机的发送伪装成智能判断。
- 绝不针对自动回复起草或发送答复。
- 绝不因机器邮件将账户标记为已处理、已回复或已关闭。
- 绝不将临时投递通知当作退信——包含重试语言意味着地址可能仍然有效，据此抑制会因服务器小故障而永久损失一个有效联系人。
使用方式
收到入站邮件后，先判断是否为机器邮件。若是自动回复，读取其中明确写出的返回日期（如有），将下一次触达重新安排到对方返回后的一个工作日，而不是推进序列。不要记录为回复、正向反馈或阶段变更。保持账户仍在序列中，自动邮件绝不能将账户标记为已处理、已关闭或已耗尽。投递通知需与自动回复分开归档：临时延迟属于邮件系统而非个人，没有日期、没有重新安排、没有退信；硬失败是另一种结果，对应另一种后果——抑制。
适用场景
适用于外呼销售、销售开发、GTM 运营等需要统计回复率和序列效果的场景，尤其是低量外呼时，一个自动回复被计为回复就可能把回复率从 2% 抬高到 4%，进而影响“该扩展哪个序列、该保留哪个细分”等下游决策。
限制与注意事项
该技能不提供具体工具或平台集成方式，也未提供代码或安装命令。其核心是分类与流程规则：自动回复应当可见且平淡无奇——一个可计数的命名结果、一个安排在返回日期之后的下一触达、以及假期邮件涌入时回复率不发生变化。若把任何入站邮件都视为互动，跟进会停止、账户会进入“沟通中”，有人还会给机器人起草回复，六周后该账户会落入“已处理、无回复”的堆里，而从未被真人读过。