报修、派工、备件、回访怎么串成一条工单

装备企业的售后常见四段断点：报修没单号、派工不知道谁近谁闲、备件进度靠问仓库、回访全凭一句口头询问。本文给出一张工单从扫码报修到回访入库的状态机、工单主表要落的字段、备件三段的最小改造路径，以及按历史分位数定 SLA 的做法。

四段各断在哪里

客户的设备坏了，第一个电话打给谁？装备企业常见的情形是：客户打电话、发消息，客服记一笔再去找工程师，备件进度靠问仓库。

环节	现在的做法	断点
报修	客户打电话或发消息给客服	没有单号，事后查不到
派工	客服记下再找人	谁离得近、谁手上活少不知道
备件	进度靠问仓库	出库、在途、到场三段看不见
回访	修完的人随口问一句	满意度没有记录

客户不知道修到哪一步，只能一次次打电话问。工程师的工时、备件的去向，到月底都对不齐。

一张工单上要有哪几项

工单要素	什么时候产生	由谁填
设备编号、型号	客户扫码时自动带出	系统
保修状态	报修那一刻判定	系统
故障描述与照片	报修时	客户
工单编号	提交时生成	系统
责任工程师	派工时按区域和技能定	客服或派单规则
到场时间与工时	接单、关单	工程师
备件申请与到货	出库、在途、收货	仓库、工程师
处理结果	关单	工程师
满意度评分	关单后自动发起	客户

这张表可以直接拿去对照你现在用的报修单。多数企业的纸质报修单和聊天记录里，只有故障描述和处理结果两项，中间六项散在通话和留言里。

工单状态机

流程走向：

• 客户扫码报修 → 已受理：生成工单号
• 已受理：生成工单号 → 待派工
• 待派工 →（按区域 + 技能）已派工
• 已派工 → 已到场：记录到场时间
• 已到场：记录到场时间 →（需要备件）待备件：出库 / 在途 / 已收货
• 待备件：出库 / 在途 / 已收货 → 已到场：记录到场时间
• 已到场：记录到场时间 → 处理中
• 处理中 → 已完工：填工时与结果
• 已完工：填工时与结果 → 回访已发起
• 回访已发起 → 已关闭：评分进台账
• 待派工 →（超时）升级给上级
• 已派工 →（超时）升级给上级
• 待备件：出库 / 在途 / 已收货 →（超时）升级给上级

三个设计要点。已到场 必须由工程师在设备上定位或扫码确认，不能由客服代点；待备件 是一个子状态而不是新工单，否则备件消耗和工单工时算不到一起；超时升级是同一工单上的事件，不改变状态，只改提醒接收人。

字段与表结构（示意）

CREATE TABLE work_order (
  order_no        VARCHAR(32) PRIMARY KEY,
  device_code     VARCHAR(64) NOT NULL,   -- 扫码带出
  model_code      VARCHAR(64) NOT NULL,
  warranty_status VARCHAR(16) NOT NULL,   -- IN / OUT，报修时点判定
  fault_desc      VARCHAR(512),
  status          VARCHAR(16) NOT NULL,
  engineer_id     VARCHAR(64),
  arrived_at      DATETIME,
  closed_at       DATETIME,
  sla_response_ms BIGINT,                 -- 派单用时，用于分位数统计
  sla_repair_ms   BIGINT,                 -- 到场到完工
  csat_score      TINYINT                 -- 关单后回收
);

CREATE TABLE work_order_part (
  line_id     BIGINT PRIMARY KEY,
  order_no    VARCHAR(32) NOT NULL,
  part_code   VARCHAR(64) NOT NULL,
  qty         DECIMAL(12,3) NOT NULL,
  outbound_at DATETIME,                   -- 出库
  intransit_at DATETIME,                  -- 在途
  received_at  DATETIME                   -- 工程师扫码收货
);

CREATE TABLE work_order_labor (
  log_id      BIGINT PRIMARY KEY,
  order_no    VARCHAR(32) NOT NULL,
  engineer_id VARCHAR(64) NOT NULL,
  started_at  DATETIME NOT NULL,
  ended_at    DATETIME NOT NULL,
  hours       DECIMAL(6,2) NOT NULL
);

warranty_status 要在报修那一刻判定并落库。事后回看时若按当前合同重算，同一张单在两个月前和今天会得出不同结论，扯皮就从这里开始。

备件那一段最难推

备件涉及仓库的操作习惯变化：出库要挂到工单，发货要有在途状态，工程师到场要扫码收货。技术上不难，难在仓库认为多了一道活。

我的做法是先只要求收货这一步扫码，出库和在途沿用现有单据，等一线习惯以后再把前面两段接上。反过来一上来就要求仓库改三个动作，多半会拖到项目结束。

落地上对应三种集成档位：

档位	数据来源	改造量	能看到什么
一	只记工程师扫码收货	小	到场时间、用了哪几件
二	加出库单同步	中	出库到收货的时长
三	加在途状态	大	全链路可视，客户自助查询

时限先按现有水平定

每个节点设时限之前，先把过去三个月的实际耗时算一遍：报修到接单平均多久、接单到到场平均多久、到场到关单平均多久。

-- 用历史工单算分位数，时限取 P75 左右，别取理想值
SELECT status_from,
       PERCENTILE_CONT(0.5)  WITHIN GROUP (ORDER BY elapsed_ms) AS p50,
       PERCENTILE_CONT(0.75) WITHIN GROUP (ORDER BY elapsed_ms) AS p75,
       PERCENTILE_CONT(0.9)  WITHIN GROUP (ORDER BY elapsed_ms) AS p90
FROM   work_order_event
GROUP  BY status_from;

第一版时限定在这个水平上下，超时提醒发给经手人，再超时升级给上级。一上来按理想值设，一线会用提前关单或者拆单来达标，数据看着好看，客户那边还是等。

这四段在平台上怎么串

这四段在 Dolphin Code 低代码平台上就能串起来。一张工单从客户扫码开始，到回访记录入库结束，中间每一次流转都有时间和经手人。

我们给一家半导体装备集团设计售后平台，也是这个思路：工单、备件、工时放在一个平台里，电脑和手机都能用。三类数据合到一张单上，效果落在两件日常事上。客户问进度，前台在工单里就能答；月底算工时和备件消耗，不用追着工程师补记录。

先接哪一段

四段不建议一起做。先接报修和派工，这两段最急，客户在催，领导也在催。备件那一段要等仓库愿意扫码收货才跑得动，回访那一段最后加上就行。

要不要串，看三个信号：客户有没有追问过这次谁来修；备件进度是不是靠人打电话问；月底工时和备件对不上账。中两条以上，前两段就可以排期。

上线检查清单

• 每台出厂设备有唯一码，扫码能带出型号与保修状态
• 保修状态以报修时点的合同有效期计算，结果落库后不再重算
• 派工规则里的区域与技能字段已维护到具体的人
• 到场确认必须工程师本人操作，客服账号无此权限
• 备件收货扫码在第一档先行，出库与在途按节奏跟进
• 工时由接单、关单两个时间自动算出，不靠月底补录
• SLA 时限按历史 P75 配置，超时提醒与升级的收件人落到人名
• 回访在关单后自动发起，评分为空时工单不算完成
• 开工前拿上个月十张报修记录，把等人、等件的耗时单独标出来

关于得帆智能

得帆智能成立于 2014 年，目前拥有 2100+ 家大型企业客户和 2400+ 个落地项目。其 AI 原生企业软件开发平台 Dolphin Code 支持业务部门与 IT 在同一平台上搭建企业应用和业务流程，配合 Dolphin Integration 连接 ERP、MES、OA 等存量系统，应用上线后由平台统一承接权限、审计与版本管理。

说明：本文由得帆智能整理发布，文中提到的 Dolphin Code 等产品为本公司产品。内容根据项目实施经验整理，仅作行业交流，不构成采购建议；文中表结构与 SQL 均为示意，实际字段以各平台元数据规范为准。