项目速览：8 项关键事实
下面是可以直接引用的事实口径。客户的服务网络、工程师规模与结算规则属于客户资产，本页不展开。
| 项目名称 | 设备仪器售后工单小程序 |
|---|---|
| 客户与行业 | 某设备仪器服务商（按客户要求未公开名称），设备安装维修与技术服务业 |
| 承接方 | 南京易企达网络科技有限公司（南京本地团队，可线下对接） |
| 项目定位 | 客户报修进得来、工程师派得出去、现场做得完、账算得清；维修之外的服务也能跑在同一条线上 |
| 交付形态 | 微信小程序（客户提交端与工程师端同一小程序，按角色区分）+ PC 调度后台 |
| 覆盖范围 | 报修提交与进度跟踪、派工与接单、上门打卡与回单、维修/移机/安装/培训多类型服务、备件与费用、服务统计 |
| 技术栈 | 前端微信小程序（uni-app / 原生），服务端 Java（Spring Boot）+ MyBatis-Plus，数据 MySQL + Redis + 对象存储 |
| 交付与归属 | 源码、数据库脚本、部署文档与接口文档按合同随验收移交；小程序主体与管理员账号由客户持有 |
六块功能：从客户报修到费用结算
顺序按一次服务的实际路径排：报修 → 派工 → 上门 → 回单 → 备件与收费；最后一块是管理者看的数据。
报修提交与进度跟踪
客户扫设备上的码或进小程序填单：设备编号、故障现象、照片视频、期望上门时间。提交后能看到派给谁、什么时候来、处理到哪一步，不必打电话追问。
派工、接单与改派
调度按区域、技能与当前工单量派单，工程师在手机上接单或申请改派。改派留痕，谁在什么时候把单转给了谁，事后查得到，不是口头协调。
上门打卡与回单
到场用定位打卡并记录时间，处理过程可加照片与说明；完成后客户在小程序上确认签字，服务才算结束。回单没确认的单，系统会标出来催办。
多类型服务：维修、移机、安装、培训
移机和培训不是维修，但流程骨架一样：受理、派工、到场、完成、确认。用同一套工单承载不同类型，各自带自己的表单字段，不做四套系统。
备件与费用
现场更换的备件从库存领用并挂在工单上，收费项逐条列出、客户确认后计入结算。一台设备一次服务的成本构成，事后能拆开看。
服务统计
响应时长、到场时长、一次解决率、人均工单量、客户评价按人或按区域汇总。哪类故障反复出现、哪个环节最耗时，报表里能看出来。
项目架构：三个入口，一条工单主线
工单系统的关键是状态清楚：谁在处理、卡在哪一步、超时了没有。状态一乱，派工与结算全都失去依据。
L1 · 入口层（3 个）
客户提交端（小程序）
扫码报修、传照片、看进度、确认签字
工程师端（小程序）
接单、导航、打卡、回单、申请备件
PC 调度后台
派工、改派、备件与收费、统计报表
L2 · 业务域（4 块，同一套服务端）
工单与流转
状态机、超时提醒、催办与关闭
派工与人员
区域、技能、负荷、改派留痕
现场与回单
打卡、处理记录、客户签字确认
备件与结算
领用、收费项、成本归集与对账
L3 · 服务端（Java · Spring Boot）
工单状态机
受理、派工、到场、完成、确认
派工与提醒
区域技能匹配、超时催办
结算与对账
备件成本、收费项归集
L4 · 数据层
MySQL
工单、备件、费用与人员档案
Redis
提醒队列、待办计数缓存
对象存储
现场照片、签字图、附件
主线：工单状态。每一次推进都要有责任人、有时间、有记录。状态不清，派工与结算就都成了口头约定。
技术选型
- 客户与工程师端：
- 微信小程序，同一套代码按角色显示不同界面，扫码即用不装 App
- 服务端：
- Java（Spring Boot），按业务域分模块，对外 RESTful 接口
- 工单流转：
- 状态机驱动，每个节点可配置提醒与超时规则
- 数据访问：
- MyBatis-Plus，工单查询与统计报表分开写
- 数据与存储：
- MySQL 存工单与备件，Redis 做提醒队列，现场照片走对象存储
- 位置能力：
- 微信定位接口 + 服务端距离校验，打卡位置与工单地址比对
客户与工程师共用一个微信小程序，按角色显示不同界面，省掉一次审核与一次推广。
三条设计取舍
一套工单模型装四类服务
维修、移机、安装、培训的差别在表单字段与作业内容，不在流程骨架。为每类各建一套，调度就得在四个后台之间切换，统计也永远合不到一起。
打卡只认现场，不认事后补录
允许补录，就等于承认记录可以是编的。定位与时间戳在到场那一刻写下，范围不符的会标异常由调度核实——这条守住，服务记录才有结算价值。
备件与收费挂在工单上
备件单独记账、收费单独开单，最后就得靠人把两本账对起来。挂在工单上，一次服务的成本与收入天生在一起，毛利能算到单。
这个项目做对了四件事
售后工单的价值不在「有个系统在跑」，而在服务过程能被核对、成本能被算清。
客户不再靠电话追问
报修之后最消耗信任的是「不知道有没有人管」。进度在小程序里可见，派给谁、几点到、处理到哪一步都在，客服的电话量自然下来。
服务过程留得下痕迹
定位打卡、现场照片、客户签字三段记录形成闭环。事后有争议时，能拿出的是证据，不是「我记得我去过」。
派工不全靠调度记忆
谁在哪个区、擅长什么设备、手上还有几单，系统里有。调度可以按建议派，也可以手动改派，但改派要留记录。
备件与费用不再两本账
备件领用与收费挂在工单上，一次服务的成本与收入在同一处。月末不用再把领料单和收费单人工对到一起。
适用边界：什么情况适合做，什么情况先别做
适合：四条同时成立
- ✓有多名外勤工程师，派工靠电话与微信群协调。
- ✓服务类型不只维修：还有移机、安装、培训等需要同样流程的作业。
- ✓客户经常追问进度，客服被同一类问题反复打扰。
- ✓需要按单核算备件与人工成本，现在靠人工对账。
不建议直接上系统：先简化或另找方案
- —只有一两个人接单：用群和表格更轻，上系统反而增加录入负担。
- —纯线上远程支持：不需要上门打卡与备件管理，工单系统价值有限。
- —客户全是内部部门、不涉及对外服务确认：可以简化成内部任务看板。
- —已有 ERP 且工单模块在用：先评估能否扩展，别重复建设。
售后工单系统常见问题（7 条）
客户不愿意装 App，怎么提交报修？▾
维修、移机、培训流程不一样，要做几套系统？▾
派工是自动还是人工？▾
工程师在现场信号不好怎么办？▾
备件和维修费用怎么管？▾
能和设备档案或生产系统打通吗？▾
多少钱、要做多久？▾
本页信息
- 发布方：
- 南京易企达网络科技有限公司（微信官方合作伙伴）
- 本页发布：
- 2026-10-30
- 内容范围：
- 项目结果与交付范围说明，不含报价与实现方案；客户的服务网络、工程师规模与结算规则不对外披露
- 联系方式：
- 400-885-7836 · service@eqiday.com
也在管外勤与售后工单？
先把三件事说清楚：有哪些服务类型、派工按什么规则、上门记录要留到什么程度。这三件定下来，功能清单和排期才有意义。