01 它是干嘛的
Service Cloud 是面向售后与客服的工单系统。它把来自电话、邮件、网页、社交平台的求助统一收进来，编成工单，按规则分派给客服，并全程记录处理过程与响应时限。
02 为什么会有它
在工单系统之前：一封投诉邮件在部门之间来回转发
没有工单系统时，用户投诉最常见的归宿是邮箱。一封邮件被转发给客服，客服看不懂技术细节，又转给技术；技术看完转给产品；产品回复后再一层层转回来。中间只要有一个人休假或漏看，这封邮件就永远沉底了。
用户这边的体验更糟：他不知道自己那件事到底有没有人管，只能反复追问；换一个人接手又要从头讲一遍。而管理者根本答不上「我们平均多久响应」这类最基本的问题。
工单系统的价值就是给每件求助一个编号、一个负责人、一个时限和一个状态。它把散落在邮件、群聊、口头交代里的请求变成可统计、可追责、可优化的流水，这是客服这个岗位能否专业化的分水岭。
03 它怎么工作
所有渠道的求助都被归一化成一张工单，然后按优先级与技能自动分派，处理过程全程留痕，超时自动升级，最后沉淀成知识库条目。
一张工单从被创建到关闭的完整旅程
- 1① 多渠道归一化
电话、邮件、网页表单、聊天窗口、社交平台留言被统一转成工单，带上来访者身份与历史记录。
- 2② 自动分类与分级
按关键词与用户等级判断问题类型和紧急程度，并据此设定响应与解决时限。
- 3③ 分派与排队
按技能组、语言、忙闲程度把工单分给合适的客服，无人接手时进入队列等待。
- 4④ SLA 计时与升级
从创建时刻开始倒计时，临近时限自动提醒，超时则自动升级给主管。
- 5⑤ 解决与沉淀
处理过程与客户确认记在同一条时间线上；关闭后常见问题整理成知识库文章。
04 谁在用它
有一定规模的售后团队
每天几十上百条求助，靠群聊和邮件已无法保证不漏、不重复。
对响应时限有承诺的企业
合同里写了两小时响应，就必须有系统来证明做到了。
需要考核客服质量的团队
首次响应时长、一次解决率、满意度评分都来自工单数据。
想减少重复问题的公司
把高频问题做成自助知识库，工单量能明显下降。
05 怎么用
先定清楚什么算一张工单、多久必须响应，再谈系统配置。
- 01列出所有求助入口，把能接的渠道先接进同一个收件箱。
- 02定义优先级标准（谁算紧急、影响多少人），并配上对应的时限。
- 03建技能组与分派规则，避免所有问题都堆给同一个人。
- 04配置自动回复与升级规则，让超时不需要人盯着。
- 05每月复盘一次高频问题，把前二十个写成自助文档。
避坑提示
- !不要把内部沟通也记进工单正文，否则时间线会变成聊天记录。
- !SLA 时限要真的能做到再设，做不到只会让团队习惯性无视。
06 关键概念
- 工单
- 一件求助的唯一载体，有编号、状态、负责人、时限，全程留痕。
- SLA
- 服务等级协议，承诺多久响应、多久解决，超时触发升级。
- 首次响应时长
- 从用户提问到第一次有人回复的时间，是客服体验最关键的指标。
- 知识库
- 把已解决的问题写成可检索的文章，让用户自助解决。
07 容易混淆的对比
Zendesk更轻、更快上线，互联网团队常用；赛富时胜在与销售数据打通。
共享邮箱零成本，但无法分派、无法计时、无法统计。