围绕工程师到场后缺件、客户暂停或任务跨天，说明如何保留已完成工作，重新安排人员，并核对下一次上门的准备条件。
AI生成示意图，用于说明业务场景，并非真实客户或产品截图。
假设一家设备服务企业安排工程师到厂排查故障。工程师已完成诊断，但现场缺少确认后的替换件，只能等备件到货后再来。如果为了释放当天日历就关闭整张工单，客服会以为问题已经解决；如果把原时间直接拖到明天，今天发生的诊断和客户沟通又容易丢失。本文用这个假设场景讨论派工系统的业务设计，不涉及真实客户成果，也不规定维修时限或收费办法。
一张客户工单，可以对应多次到访
客户工单描述要解决的事项、服务对象及当前整体进展；每次到访记录实际安排了谁、去哪里、计划与实际时间、做了什么和留下什么。两者分开后，本次到访结束不必等同于客户问题已经关闭。下一次由其他工程师上门，也能继续处理同一事项，而不是另建一张互不相关的工单。
Microsoft的Field Service官方文档也区分工单与资源预订的生命周期，并支持一张工单关联多个预订。这可作为需求讨论时的对象拆分参考，不意味着企业必须采用该产品，更不代表广深互联现有系统已具备其中全部功能。定制开发应使用员工熟悉的名称，重点是能解释每次实际服务与整体事项的关系。
工程师离场前，留下能接手的剩余任务
在假设场景中，离场记录不宜只写“缺件，下次再修”。应说明本次观察与已执行动作、尚未完成的具体项目、所需备件的已确认标识、待核实条件及接续责任人。诊断意见和已确认结论分别呈现，避免接手人员把初步推测当成最终处理指令。
照片、附件和客户提供资料应关联设备与本次到访，只保留必要内容。客户现场可能包含人员和其他商业资料，不能以“方便交接”为由全量拍摄。下一位工程师查看交接包时，应能区分上一轮上传的资料与后续补充版本；已完成工作不因换人而被覆盖或要求无理由重做。
再次派工前，先核对真正缺的条件
仅把时间改到明天，并不能解决缺件问题。调度应先核对备件是否已准备、工程师技能是否匹配、客户是否提供进场条件，以及该次服务还需要哪些工具。具体资质、安全作业条件与技术方案由企业专业人员确定，排班界面空闲不能代替现场作业许可。
小团队可以先由调度人工确认后派工，界面展示明确的待准备项。业务量增加时，再考虑与备件、客户窗口和人员安排联动。后一种方案减少重复录入，但依赖源数据及时准确，也增加对接与异常处理范围。采购时应说明首期采用哪一种，不把“自动派最合适的人”当成没有规则也能实现的功能。
延期、换人与客户取消应保留不同原因
客户暂时无法停机、备件未到、工程师行程受阻，都会造成延期，但下一步处理责任不同。系统应保留原安排、变更原因、发起人和当前有效安排。客户取消后续到访，也不必自动抹去已经发生的诊断记录；工单接下来如何结束或保留，按照企业与客户确认的处理办法执行。
正在进行中的到访不宜像尚未开始的安排一样任意挪动。若已到场，再将人员改给另一位同事，应保留原人员的实际活动，并新增接续关系。系统要能提示新安排与其他任务冲突，保留人工处理结果；预计出发、实际到场和离场时间分别记录，不能为了匹配计划把真实时间改成预计时间。
内部派工成立，不等于客户已接受新时间
调度确认了新人员和时间，只代表内部安排。还需要记录客户是否已经确认、通过哪个已授权渠道沟通，以及未联系上时由谁跟进。发送通知、收到回执和客户明确接受是不同证据。消息失败时，可以生成待人工联系事项，不能在客户页面显示成双方已约定。
若移动端离线提交了离场记录，恢复网络后应先核对同一次到访的保存结果，避免重复生成下一次派工。多人同时调整时，需要让后提交者看到已有变化并重新确认，不能让旧页面无提示地覆盖新安排。这里要核对的是到访记录和接续任务的关系，不把技术保存成功等同于维修完成。
用一张未完成清单判断是否真的接上了
验收可围绕同一张自制工单连续操作，而不是只分别演示建单和排班两个按钮：
- 本次诊断结束、备件未到：本次活动可收尾，整体事项仍显示剩余任务与负责人。
- 次日换人上门：接手者能查看已做工作、待核实意见、当前备件与有效附件版本。
- 客户未确认新时间：内部安排与客户确认分别展示，不能自动写成已接受。
- 两位调度同时修改：不产生互相冲突且无人知晓的有效安排，变更过程可查询。
- 离线记录重复上传：同一次到访不会无依据变成两次活动或两张后续任务。
- 客户取消后续服务：已发生的活动仍可查询，未完成项依据确认结果处理。
关闭整张工单前，应能逐项核对原诉求、实际处理结果及仍未解决事项。若还有待执行项目，需要明确后续承接方式，而不是因工程师点了离场就显示全部完成。准备需求时，可提供一张脱敏的跨天工单及现有派工表，先讨论任务和责任如何接续。本文由广深互联整理；广深互联提供软件定制与业务系统开发服务，实际开发范围、对接条件和交付安排以评估及约定为准。
可通过广深互联的软件定制开发服务了解业务系统评估范围，再用现有跨天工单讨论实施。本文建议的接续流程不代表已有标准产品功能；品牌与服务信息可在广深互联官网核对。
资料来源
项目开始前，需要准备什么？
可以先整理业务目标、使用角色、当前流程和参考资料。我们会围绕需求范围、优先级和交付边界展开沟通。
已有系统可以保留并接入吗？
可以先评估已有系统的接口、数据权限与维护条件，再确定接入方式。无需因为新项目就默认替换所有系统。
软件开发费用如何评估？
费用取决于功能范围、设计、数据迁移、集成、测试和维护安排。先明确交付范围，再形成可比较的报价。
项目会交付哪些资料？
按约定交付设计、源码、部署说明及测试资料。依赖、第三方账号与素材权利等边界应在项目范围中写清。
AI应用如何保护企业数据？
先明确数据来源、访问角色、使用目的和模型接入边界；对于不确定结果与重要决策保留人工复核。
上线后如何维护？
根据系统使用情况约定维护范围、备份恢复、故障反馈与版本更新方式，具体响应时间以服务约定为准。