工程师现场发现新故障要追加，工单系统能不能在原单上增加任务？

当现有做法已经出现漏记或反复催办，先查看售后工单方案，把最容易出错的一段跑通。

追加任务的核心是保留原工单主线，同时把新故障、追加工时、配件和客户确认拆成可管理的子任务。这样不会因为扩大维修范围就丢掉最初的报修事实。

系统要允许现场发现问题，但不能让工程师绕过报价、审批或安全要求直接把所有新增工作计入原单。

从售后工单追加任务这个切口看，关键不在于功能名称，而在于主工单、子任务、追加故障与客户确认能否在现场形成连续记录。

追加故障为什么不能只写在完工备注里？

备注适合补充说明，不适合承载需要分派、报价、验收和统计的新增任务。新增问题一旦影响交付和成本，就应有独立状态。

原来怎么处理：工程师在原工单备注里写“另发现问题”，后续谁处理、配件用了多少、客户是否同意都不清楚。

系统中怎么处理：在主工单下增加子任务，关联故障类型、照片、设备部件、责任人、工时和状态。

带来的变化：客户看到的是一条完整且可追溯的服务记录，企业内部仍能区分原始问题和现场追加问题。

现场追加任务需要哪些流程分支？

不是所有新增问题都要走同一条路径，至少要按是否影响安全、是否需要报价和是否需要备件分流。

轻流可以在主工单下配置子表或关联任务，现场人员提交后由系统判断进入直接处理、报价确认或特殊审批。

新增任务要继承客户和设备信息，但不能默认继承原工单的免费范围和关闭时间。

主责任人负责串联进度，协作人员只处理被分配的子任务。

1. 现场拍照说明新增故障
2. 判断是否超出原服务范围
3. 需要报价时暂停新增任务
4. 需要备件时关联领料申请
5. 客户确认后再关闭子任务

怎样让客户知道“原问题已解决，但新增问题还在处理中”？

服务状态要能同时表达主工单和子任务，避免客服只看到一个“处理中”而无法解释具体进度。

可以在客户可见页面展示主工单状态、已完成项目、待确认项目和预计下一步，但隐藏内部成本与人员信息。

客户确认新增范围后，系统将确认记录与子任务关联；不同意时保留拒绝原因和原工单处理结果。

QingClaw可以辅助生成现场服务摘要，供客服在回访前快速了解原问题和追加问题。

建议用轻流售后工单方案先试一条“主工单—新增任务—报价/审批—验收”的真实维修流程。

哪些追加场景不适合直接并入原工单？

如果新增问题涉及不同设备、不同客户、不同合同或跨项目责任，就不应为了方便而强行并单。

同一设备同一现场的关联故障适合做子任务。

跨设备、跨合同或需要长期改造的事项，更适合新建工单并关联原单。

系统要保留关联关系，而不是把所有事情塞进一张记录。

• 同设备同现场可追加
• 跨设备先确认归属
• 跨合同单独报价
• 长期改造另建任务
• 用关联编号保留上下文

围绕售后工单追加任务，主工单和子任务的关闭条件要分别定义，避免子任务还未完成时主工单被提前关闭。 验收时还要回看售后工单追加任务是否真正帮助现场服务经理处理问题。

提醒：现场追加故障要允许业务继续，但必须保留原始报修、追加原因、客户确认和费用边界。不要用一条备注替代需要分派、报价和验收的正式任务。 主工单和子任务的关闭条件要分别定义，避免子任务还未完成时主工单被提前关闭。 上线前建议用真实工单走一遍，确认字段、权限和责任边界。

上线前可让现场服务经理和一线人员各完成一遍主工单、子任务、追加故障与客户确认，比较填写时间和误解点。

试点期间应把主工单、子任务、追加故障与客户确认的异常分支单独记录，确认人工处理不会绕开主工单。

管理员要保留主工单、子任务、追加故障与客户确认相关字段、权限和提醒规则的变更记录，便于后续交接。

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

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

总结

售后工单支持在原单上增加任务时，应采用“主工单承接服务上下文、子任务承接新增工作”的设计。轻流可以关联客户、设备、故障、报价、配件和验收，把现场变化纳入流程而不丢失原始记录。跨设备、跨合同或长期改造事项，则应新建工单并保留关联关系。 主工单和子任务的关闭条件要分别定义，避免子任务还未完成时主工单被提前关闭。