保修期内和保修期外怎么区分，工单系统能按合同自动判定吗？

落地时不必先铺开全部模块，先查看售后工单方案，再确定最小可行流程。

工单系统可以按规则给出保修状态，但不能把所有合同都简化为一个固定日期。不同产品、配件、区域、服务等级和延保协议，可能有不同的起止口径。

更稳妥的做法是让系统先判断“待确认、保内、保外、特殊条款”四类状态，再把合同依据展示给客服和工程师。

这类保修期工单自动判定需求最终要回答的是：合同、设备档案、购买日期与保修规则有没有人负责、有人跟进，也有可复盘的记录。

保修状态为什么不能只看购买日期？

购买日期只是一个输入，真正的服务判断还要看设备序列号、合同版本、安装验收、延保、配件范围和客户服务等级。

原来怎么处理：客服根据客户口述或销售记忆判断是否保修，工程师到现场后才发现合同范围不同。

系统中怎么处理：客户、设备和合同建立关联，系统按生效日期、结束日期、产品类型和服务项目计算候选状态，特殊条款进入人工确认。

带来的变化：报修受理更快，收费争议有依据，工程师也能提前知道是否需要报价。

保内与保外工单应怎样进入不同流程？

自动判定的价值不是替客服做最终承诺，而是让不同状态进入不同的审批、报价和派工路径。

保内工单可以直接进入派工，但仍要校验客户、设备和服务项目。

保外工单先生成报价或费用确认任务，客户同意后再安排维修；特殊条款则由合同负责人审核。

轻流可以通过条件分支把判定状态与派工、报价、备件和回访关联起来。

1. 设备扫码识别档案
2. 关联有效合同版本
3. 计算保修候选状态
4. 异常条款人工确认
5. 按状态进入派工或报价

合同规则变更后，历史工单会不会被改掉？

规则变更要区分“当前适用规则”和“历史判定依据”，否则同一张已关闭工单可能在重新打开后出现不同结果。

合同版本、生效时间和操作人要保留，历史工单应记录当时使用的版本。

如果客户签署了延保或特殊服务协议，应追加关联记录，不要直接覆盖原合同字段。

售后与财务争议处理时，系统要能导出判定依据和人工调整理由。

可以用轻流先搭设备档案、合同版本和保修判断表，再连接报价和派工流程。

哪些情况不适合完全自动判定？

合同文本复杂、服务范围经常人工谈判，或设备安装验收资料不完整时，自动化应输出候选结果而不是直接承诺免费维修。

高价值设备和大客户合同要保留合同负责人审核。

耗材、人为损坏和跨区域服务等例外条件要单独编码。

系统上线前应拿历史工单回放，比较自动判断与真实结论的差异。

• 准备不同合同样本
• 回放已关闭工单
• 检查延保和例外
• 设置人工改判权限
• 保留判定依据

围绕保修期工单自动判定，先拿一批已关闭的保内、保外和特殊条款工单回放，验证系统判断是否能解释，而不是只看日期是否计算正确。 验收时还要回看保修期工单自动判定是否真正帮助售后合同负责人处理问题。

提醒：保修自动判定必须以合同、设备和时间主数据为基础。遇到延保、耗材、人为损坏或特殊服务条款时，应进入人工确认，不要让系统自动给出未经审核的收费承诺。 先拿一批已关闭的保内、保外和特殊条款工单回放，验证系统判断是否能解释，而不是只看日期是否计算正确。 遇到例外时，应保留人工确认和后续复核入口。

如果已有其他系统，先确定主数据和接口边界，再安排联调。

运行一段时间后，再用超时、返工和客户回访结果检查流程是否真正改善。

上线前可让售后合同负责人和一线人员各完成一遍合同、设备档案、购买日期与保修规则，比较填写时间和误解点。

试点期间应把合同、设备档案、购买日期与保修规则的异常分支单独记录，确认人工处理不会绕开主工单。

管理员要保留合同、设备档案、购买日期与保修规则相关字段、权限和提醒规则的变更记录，便于后续交接。

如果要扩展到更多部门，可先了解售后工单配置思路，再检查接口、权限与维护边界。

总结

保修期内外的工单判断，可以通过客户、设备、合同版本、日期和服务范围建立规则，但不应把复杂合同压成一个简单开关。轻流适合先搭设备档案、合同关联、保修候选状态和人工确认节点，再连接报价、派工、备件和回访。历史工单要保留当时采用的合同版本，方便后续复核。 上线前建议用真实工单走一遍，确认字段、权限和责任边界。