我做了一个「雪梨智能工单客服系统」

我做了一个「雪梨智能工单客服系统」

最近把自己做的一套系统整理了一下，开源出来了。

它叫：

雪梨智能工单客服系统

项目地址：

https://gitee.com/sanbox/sherry-ticket/

这是一个把 工单、客服、知识库、SLA 和 AI 能力结合在一起的系统。

一开始做它的时候，其实没有想得特别复杂。

就是觉得很多企业的客服、售后、IT 服务场景里，都有一个共同的问题：

事情很多，但信息是散的。

客户的问题散在微信、邮件、网页表单里。

客服的处理记录散在聊天工具里。

历史解决方案散在文档里。

客户以前提过什么问题，也很难快速找到。

最后大家每天都在做一件事情：

不断重复处理以前处理过的问题。

所以我想试着做一个系统，把这些事情串起来。

---

工单不应该只是一个“待办事项”

很多工单系统给人的第一感觉就是：

创建工单 → 分配 → 处理 → 关闭。

看起来挺简单。

但真正做进去以后，会发现一张工单背后其实有很多事情。

客户提交了问题之后：

谁来接？

应该分给哪个部门？

优先级是多少？

多久必须第一次响应？

处理不了怎么办？

要不要转派？

需要等第三方的时候怎么办？

客户又回复了怎么办？

最后是谁解决的？

这些东西全部需要被记录下来。

所以在雪梨智能工单客服系统里，我比较重视的是​工单的整个生命周期​。

从创建，到受理、分配、处理中、转派、挂起、解决，再到关闭，每一个阶段都有对应的处理逻辑。

这样工单记录的不只是“一个问题”。

而是：

这个问题是怎么一步一步被解决的。

---

客服和内部人员，说的话不应该一样

这是做工单系统时一个挺容易忽略的问题。

客服回复客户的时候，可能会说：

您好，我们已经收到您的问题，目前正在处理。

但是内部人员之间可能会讨论：

看日志应该是接口超时，先让后端排查一下。

这两句话显然不是给同一个人看的。

所以系统里把公开回复和内部备注进行了区分。

客户看到的是应该让客户看到的信息。

内部人员可以保留自己的处理记录和讨论。

这样既方便协作，也不会因为内部沟通内容误发给客户。

这种事情看起来很小，但真正用起来以后，反而是非常重要的细节。

---

为什么叫“智能工单”？

因为我觉得现在的工单系统，如果只是把传统流程搬到网页上，其实还不够。

现在 AI 已经可以参与很多工作了。

所以雪梨智能工单客服系统也尝试把 AI 放进工单处理流程。

比如一个客户提交：

“系统从今天早上开始一直登录不上去，已经影响工作了。”

以前客服可能需要自己判断：

这是什么问题？

应该属于哪个分类？

优先级高不高？

以前有没有类似工单？

知识库里有没有解决方案？

现在这些事情可以让 AI 先帮忙分析。

包括：

工单分类、优先级判断、回复建议等。

但这里我并不希望 AI 直接替客服做决定。

我更倾向于把它当成一个助手：

AI 负责降低重复劳动，人负责最终判断。

这样可能比“AI 自动接管客服”更现实。

---

不同业务，需要不同的工单表单

做这个项目的时候，还有一个问题让我花了不少时间。

就是：

不同类型的工单，根本不是一回事。

比如 IT 报障可能需要：

• 设备编号
• 操作系统
• 故障现象

售后可能需要：

• 订单号
• 商品信息
• 购买时间
• 售后原因

物业报修又完全是另外一套字段。

如果每增加一种业务，就需要开发人员重新写页面、接口和数据库字段，后面维护起来会越来越麻烦。

所以系统里加入了​动态表单​。

不同业务可以配置自己的字段和表单。

业务发生变化的时候，不需要每次都重新开发一套页面。

我觉得这也是企业系统比较重要的一点：

不要假设业务永远不会变。

---

SLA，让“尽快处理”变成一个具体的时间

客服系统里经常会出现一句话：

“这个问题尽快处理一下。”

但“尽快”到底是多少？

10 分钟？

1 小时？

还是明天？

所以系统里加入了 SLA。

可以针对不同类型的工单设置：

• 首次响应时间
• 解决时间
• 超时提醒
• 工单升级

这样系统就可以告诉你：

哪些工单快超时了。

哪些已经超时。

哪些问题需要优先处理。

从“大家记得及时处理”，变成：

系统帮你盯着时间。

---

以前解决过的问题，不应该再解决一遍

这也是我做知识库的原因。

客服每天遇到的问题，很多其实并不新。

一个问题可能上个月已经解决过十次。

但如果解决方案没有沉淀下来，下个月还是得重新查。

所以系统把知识库和工单关联起来。

遇到问题的时候，可以搜索以前沉淀下来的知识。

AI 也可以辅助寻找相关内容。

慢慢把一次次客服处理经验，变成可以重复利用的知识。

这其实也是我觉得智能客服比较有价值的地方：

不是单纯回答问题，而是让系统越来越了解业务。

---

客户也应该被“记住”

一个客户今天提交一个问题。

过几天又提交一个问题。

再过几天又发了一封邮件。

如果每次客服都要重新了解客户背景，效率其实很低。

所以系统里也加入了客户信息和历史工单。

客服打开一个客户，可以看到这个客户之前遇到过什么问题、提交过哪些工单、历史是怎么处理的。

这样处理问题的时候，至少不用每次都从零开始。

---

技术上，我没有刻意搞得很复杂

后端主要使用：

Spring Boot 3

前端使用：

Vue 3 + TypeScript

同时使用 MyBatis Plus、Sa-Token、Quartz、WebSocket、SSE 等技术。

整个项目更希望做成一个真正可以运行、可以继续开发的业务系统，而不是为了展示技术而堆技术。

毕竟对于这种项目来说：

能把业务流程真正跑通，比用了多少新技术更重要。

---

现在的雪梨智能工单客服系统

目前已经把工单、客服、客户、知识库、SLA、动态表单以及 AI 能力这些核心部分串了起来。

后面还会继续往更多方向完善，比如：

多租户、工作流、移动端、小程序，以及更深入的 AI 自动化能力。

所以现在它更像是一个持续迭代中的项目，而不是一个已经结束的产品。

---

为什么开源？

其实就是想把自己做过的东西分享出来。

如果你正在做：

• 客服系统
• 售后系统
• 工单系统
• ITSM
• 企业内部服务平台

或者你也在研究：

AI 到底应该怎么真正落到业务系统里。

那么这个项目或许可以给你一些参考。

当然，也欢迎大家直接看代码。

觉得哪里设计得不合理，可以提 Issue。

觉得某个功能有意思，也可以一起交流。

我一直觉得，一个项目真正有价值的地方，不只是代码写完的那一天。

而是有人开始使用它，然后不断发现问题、提出问题，再一点一点把它变好。

这就是我做 雪梨智能工单客服系统 的原因。

项目地址：

https://gitee.com/sanbox/sherry-ticket/