机床售后扫码报修与工单跟踪系统
设备存量上万台，过保设备占比高，报修靠微信群、工单靠人记、进度靠人问。客户已有的工单系统要求客户注册手机号，一线客户不愿意用。交付一套贴在设备铭牌上的二维码入口：客户扫码看设备档案并报修，工程师接单签到完工，主管在后台看单量与超时。不替换客户现有系统，只补客户侧入口。
- 报修走微信群，派工信息被日常消息刷掉
- 客户查进度、查快递单号必须打电话问人
两场现场会，只抽售后一条链路上的动作与卡点
客户当时卡在哪
- 报修走微信群，派工信息被日常消息刷掉不解决的代价：第二天要派人时找不到那条报修，一天几百条消息里翻记录
- 客户查进度、查快递单号必须打电话问人不解决的代价：一天发二十件货，逐个查单号十几分钟，客户还在等
- 设备台账不结构化，保修状态与维修历史查不到不解决的代价：过保设备上门服务无历史可依，同一台机器反复排查；配件按型号匹配靠人记
- 响应时长、满意度月底手工汇总不解决的代价：售后部门成立不久，缺一套能证明部门价值的量化依据
- 已有工单系统客户侧要求注册手机号不解决的代价：一线操作工不愿意注册，客户侧入口实际没跑起来
FDE 怎么干的
两场现场会，只抽售后一条链路上的动作与卡点
关键判断：不替换客户现有工单系统，做客户侧入口，数据按需导出
把知识库、AI 客服、配件商城、在线支付全部推到后续阶段
关键判断：验证阶段只做一条能跑通的主链路，范围写死，多一项就加钱
Node 22 内置 SQLite，原生 http 单文件路由，服务端模板，不引入构建链
关键判断：客户 IT 仅 4 人且 ERP 运维外置，交付必须 node server.js 就能跑；否决了 React/Next 前后端分离
12 张表，主键用可读文本（设备编号、工单号），状态用 CHECK 锁死枚举
关键判断：现场要能把单号念出来；同一台设备同时只允许一张未结束工单，重复提交返回 409 并跳原单
超时做成 SLA 计算字段，不设成工单状态
关键判断：派工 120 分钟、到场 1440 分钟；响应按工作分钟计（周一至周六 08:00–17:00），到场按自然 24 小时，两者性质不同不统一
部署到自有已备案域名下，nginx 子路径反代；二维码打印贴在设备上，把手机递给客户自己扫
关键判断：原托管域名在微信里打不开，域名必须自有且已备案；不投屏，演示前重置演示库，让工单号与日期自洽
完整经过
作者亲述：方案取舍、走过的弯路、怎么说服客户背景
设备存量上万台，过保设备占比高。报修走微信群，派工信息被日常消息刷掉；客户查进度、查快递单号必须打电话问人；设备台账不结构化，保修状态与维修历史查不到；响应时长、满意度月底手工汇总。客户已有的工单系统要求客户注册手机号，一线操作工不愿意注册，客户侧入口实际没跑起来。
怎么打
两场现场会只抽售后一条链路上的动作与卡点，定下不替换现有工单系统、只做客户侧入口。范围写死：知识库、AI 客服、配件商城、在线支付全部推到后续。技术选型上，客户 IT 仅 4 人且 ERP 运维外置，交付必须 node server.js 就能跑，否决了前后端分离。建模 12 张表，主键用可读文本，同一台设备同时只允许一张未结束工单。超时做成 SLA 计算字段而非状态，派工 120 分钟、到场 1440 分钟，响应按工作分钟计、到场按自然 24 小时。部署在自有已备案域名下，nginx 子路径反代。演示时二维码打印贴在设备上，把手机递给客户自己扫。
结果
需求确认到可点系统上线 5 天（2026-10-21 至 2026-10-26）。扫码主链路 8 项逐条通过（2026-10-27）。响应与超时判定口径写入数据模型并配 13 项单测，含等于 120 分钟算达标、121 分钟超时、周末顺延等边界。
边界
微信内可扫的网页，不是小程序；无登录与角色权限，后台和工程师端仅用于演示；未与客户现有工单系统对接，本期独立库运行；客户尚未签约与验收，无生产环境业务数据，本案例不含任何效率提升数字。
踩过的坑
只写顺利过程的案例，客户默认是包装过的这个方案解决不了什么
敢写边界，才说明真的做过- ×微信内可扫的网页，不是小程序；小程序需另走备案与审核，当前未包含
- ×无登录与角色权限，后台和工程师端仅用于演示，上线前必须补
- ×未与客户现有工单系统对接，本期独立库运行，按需导出；配件商城、在线支付与月结开票、知识库与 AI 客服均未做
- ×客户尚未签约与验收，无生产环境业务数据，本案例不含任何效率提升数字；演示数据为虚构，真实部署须换客户台账
结果
每个指标都附统计口径核验依据
仅对平台开放本案例已提交 5 项核验材料（验收单、周报、客户确认等），由平台逐项核对。原件含客户名称与金额，不对外展示。
客户见证人
本案例已获客户确认（L3）。见证人信息由客户自愿补充，用于进一步支持「可参考联系」（L4）。