低代码搭建工单系统实战：派单、SLA 与满意度回访

结论先行：一套能落地的工单系统 = 3 张数据表 + 6 个状态的生命周期 + 自动派单规则 + SLA 超时升级 + 关单后自动回访，用低代码（Low-Code）平台 2 天可上线。其中 SLA（Service Level Agreement，服务等级协议）计时与超时升级是"有没有人管"的分水岭——做了它，超时工单占比通常能从 20% 以上压到 5% 以内。

客服和运维团队每天面对的真实现状是：工单散落在微信群、电话和邮件里，谁在处理、处理到哪一步没人知道，客户催第三遍才有人回。本文按"建模 → 状态机 → 派单 → SLA → 回访"的顺序，给出完整搭建方案。

一、数据模型：3 张表 + 1 条派单依据

表名	关键字段	说明
工单表	标题、描述、分类、优先级、状态、提交人、处理人、提交时间、期望完成时间	核心业务表
处理记录表	工单（关联）、处理人、处理动作、内容、耗时	全程留痕，客户可查进度
客服坐席表	姓名、技能组、当前在办工单数	自动派单的依据

工单分类建议不超过 8 个（如账号问题、支付问题、故障报修、功能咨询），分类直接决定派给哪个技能组，分得太细反而派不准。

二、工单生命周期：6 个状态的状态机

提交 → 已受理 → 处理中 → 待确认 → 已关闭（含回访），外加"挂起"作为辅助状态。两条铁律：每个状态只能由特定角色的动作触发（如"待确认"只能由处理人提交、客户或客服确认后关闭）；每次状态变更写入处理记录表，形成完整时间线。以猫拽低代码（CatPull）为例，可以用工作流的页面跳转与变量赋值节点控制状态流转，状态非法跳转直接在工作流里拦截，前端只做展示，规则全在服务端兜底。

三、自动派单：3 条规则按序生效

规则一（分类路由）：按工单分类映射技能组，如支付问题 → 支付组；
规则二（负载均衡）：组内按当前在办工单数从少到多派发，坐席表实时更新计数；
规则三（指定兜底）：优先级为"紧急"的工单直接派给当日值班人，保证必有人接。

自动派单失败（如技能组全员满载）时走人工池：工单进入"待分配"视图并提醒主管，5 分钟内仍未分配则升级到主管本人，杜绝"系统里躺着没人看"。
物业报修几乎照抄这套派单规则，只是把技能组换成水电、门窗、电梯等工种，再叠加按房屋建档与物业费催缴，见物业报修与缴费管理方案。

四、SLA 计时与超时升级

给两个优先级先定标准（数字可按业务调整）：紧急工单响应 ≤ 15 分钟、解决 ≤ 4 小时；普通工单响应 ≤ 30 分钟、解决 ≤ 8 小时。用两条工作流实现计时：

工作流	节点序列	说明
响应超时升级	定时触发（每 5 分钟）→ 查询工单（已提交且未受理且超过 SLA）→ 条件分支（首次/二次超时）→ 提醒处理人 / 升级主管	二次超时抄送部门负责人
解决超时升级	定时触发（每小时）→ 查询处理中且超 SLA 的工单 → 通知处理人并要求填写延期原因	延期需主管审批，防止无限拖

SLA 数据同时是月度考核依据：按坐席统计响应达标率、解决达标率，报表页用现成的图表组件即可呈现。园区企业诉求工单是同一套 SLA 逻辑的政务变体，多了跨部门派单与督办升级，场景见园区政务低代码方案。

五、满意度回访：关单后的自动化

工单关闭后 24 小时，回访工作流自动触发：发送满意度评分（1~5 分）→ 收集评价内容 → 低分（≤ 2 分）自动生成"回访跟进单"并派给客服主管电话回访。回访结果回写工单表，季度即可统计 NPS 式的趋势数据。回访闭环让服务质量形成"处理—评价—改进"的循环，而不只是关单了事。

FAQs

Q1：工单系统要支持客户在小程序上提交和查询进度吗？

A：建议支持。低代码平台一次搭建可同时发布 H5 与微信小程序端，客户侧只需提交表单和进度时间线两个页面，服务人员用管理端处理，两端数据同库互通。

Q2：SLA 时间要不要扣除非工作时间？

A：对内支持场景通常不扣；对客户承诺的服务场景建议扣除，实现方式是把"提交时间 + 服务时长"的顺延规则写进 SLA 计算节点（跳过夜间与节假日），或在 SLA 表里为每个优先级配置工作日历。

Q3：工单量大了之后，查询和统计会变慢吗？

A：按月归档历史工单、给状态/分类/创建时间建索引，单表百万级数据内查询与图表统计都能保持秒级响应；再往上量可考虑读写分离或数据仓库出报表。