设备售后工单：小程序与 App 协同方案解析

方案示例说明：本页为假设业务场景的功能与实施解析，不代表已交付客户案例，文中数字不作为项目效果证明。

以设备报修、派单、缺件暂停和维修确认为示例，说明小程序、工程师 App 与调度后台的分工、状态设计及验收重点。

01 / 场景设定与使用角色

设想一支负责设备售后的团队：客户打电话报修，调度人员在群里找工程师，维修过程和备件用量分散在聊天记录中。方案通过工单连接客户、调度和工程师。

本页是项目方案示例，未使用真实客户或上线成绩。是否需要同时开发小程序与 App，取决于使用频率、设备能力和现有入口，不要求所有项目都做齐多个终端。

客户选择设备并提交故障描述，调度人员受理后派单，工程师检查发现需要更换配件。工单转入待配件状态，记录原因和预计下一步，客户可以看到进度说明。

配件到位后继续处理，工程师提交维修内容与更换记录，再由客户确认。等待配件不直接等于维修完成；处理耗时如何扣除等待时间，应由业务规则明确。

客户小程序展示自己的设备、报修记录和确认入口；工程师端展示分配给自己的任务、处理记录和备件申请；调度后台用于分配人员、调整安排与处理超时事项。

如果现场存在弱网，可评估 App 本地草稿与延迟上传；附件上传成功前不显示“全部提交完成”。定位、拍照和消息提醒按实际需要接入，并明确授权与可用条件。

工单、设备、服务人员和备件记录使用稳定标识关联。每次派单、转派、暂停和关闭都保留操作时间与原因，避免只保存最终状态而丢失处理过程。

客户只能查看自己有权限的设备与工单，工程师不能通过修改链接查看其他任务。关键操作除页面限制外，还需在接口处验证身份、权限和当前状态。

验证重复报修、工程师拒单、客户改约、备件延迟、照片上传失败和关闭后返修。对需要重试的提交检查是否重复生成记录，通知发送失败也不能导致工单丢失。

验收时由不同角色走完一条工单，并对照操作日志。若希望统计响应时间，应先明确从哪个事件开始、到哪个事件结束，再检查暂停和重新打开工单的处理方式。

首期可聚焦设备档案、报修、派单、维修记录和客户确认，在一组设备与工程师中试运行。库存、收费结算和企业知识库作为后续独立模块评估。

交付需约定终端代码、后台、接口、部署资料和使用说明。是否上架应用商店、申请平台账号及接入短信等服务，应在项目范围中明确责任与依赖。