客服工单SLA怎么设计？区分响应、解决与暂停计时

客服工单SLA要先分清两件事：多久给出有效响应，多久达到约定的解决状态。这通常是两套不同的计时规则。仅写“4小时处理”，却不说明工作时间、等待资料和结束条件，客服、技术支持与客户很容易理解成不同的承诺。

设计规则时，可以先用Boardmix 流程图把接单、响应、补充资料、处理和确认的路径画出来，再为每个状态标明两个时钟是否继续。白板适合共同走读规则；实际计时、提醒和工单记录仍由团队使用的服务系统执行。

响应时间和解决时间，分别从哪里开始、到哪里结束

首次响应关注客户提出请求后，多久得到符合约定的回复；解决时间关注请求经过处理后，多久达到约定的完成条件。首次响应完成了，解决时钟通常仍在继续。不能因为客服已经回了一句话，就认为整张工单已经满足服务目标。

“已收到，请耐心等待”是否算响应，不能靠各人临场判断。若团队希望衡量实质服务，可以约定：回复应说明已理解的问题、下一步或确需补充的信息，单纯自动回执不作为首次有效响应。这个标准需要提前约定，并在实际系统中核对能否识别相应事件。

解决与关闭也不一定相同。工单可以先进入“处理完成、等待确认”，之后再关闭；也可能要求客户确认才停止解决计时。应把业务认可的完成条件落实到状态事件，而不是只挑一个方便统计的按钮。

先确认日历，再谈“几个小时”

服务时间可以按自然时间计算，也可以只统计工作日历内的时间。工作日历至少要写清时区、工作日、每日时段和节假日。例如周一至周五9:00—12:00、13:00—18:00，中午休息和周末不计入，和“每天9:00—18:00连续计时”会得到不同结果。

Atlassian的SLA日历说明将时区、工作日、多个工作时段与假期分别配置。设计自己的规则时，也应把这些条件分开检查，不要把系统预设的营业时间当作已经对客户作出的承诺。

跨地区服务尤其要避免“周一上午”这种写法。记录中保留明确时区，向客户说明对应服务窗口。调整班次或节假日后，还要确认规则从何时生效、对在途工单是否有影响，保留版本依据。

一张跨周末工单，怎样算出响应30分钟、解决4小时

以下用一组练习数据演算跨周末工单的用时。假设服务按北京时间，工作日为周一至周五9:00—12:00、13:00—18:00，本例两天都不是节假日；首次有效响应目标为1个工作小时，解决目标为4个有效工作小时。

两时钟都从工单创建开始。首次响应不设置业务状态暂停，以人工发送有针对性的公开回复为结束；解决时钟允许在确需客户资料且已明确发出补充请求后暂停，资料收到并满足恢复条件时继续。内部转交不暂停，处理结果已提供且符合约定时停止解决计时。

因此，首次响应为17:00减16:30，等于30分钟；解决有效时间为周五60分钟＋周一上午120分钟＋周一下午60分钟＝240分钟，即4小时。在本例“用时不超过目标”的约定下，两项都达到目标，解决用时恰好到达上限，没有剩余余量。

周末不计时，等待客户状态也覆盖了周末，但不能把周末扣两遍。更稳妥的算法是：只累计同时满足“在工作日历内”且“未处于允许暂停状态”的时间段。不要先随意算一个自然时长，再反复减掉彼此重叠的休息与等待时间。

没有资料等待暂停时，周五16:30—18:00有90分钟，周一9:00—12:00有180分钟，13:00—14:00有60分钟，共330分钟。这里的差额90分钟，才是本例等待状态与工作时间重叠的部分；不能把整个周末都当成客服处理时间。

等待客户、内部转交和换班，不要混成一种暂停

暂停是一条服务规则，不能成为让超时消失的操作技巧。进入等待客户前，要说明缺什么、为什么处理需要它、怎样提供，以及谁在跟进。只说“资料不全”后无限等待，会让工单在统计上停止，却没有解决客户的问题。

Atlassian的起停条件说明将暂停作为可选条件，等待客户回复是其举例之一。是否采用这个条件，应由团队的服务约定决定，而不是所有工单系统都应如此。

• 等待客户资料：若规则允许暂停，记录具体资料、请求时间、恢复事件及提醒负责人。收到无关回复是否恢复，也要提前定义。
• 内部部门转交：通常仍是服务提供方的处理过程；本例明确继续计时，不能因换一个负责人把时间归零。
• 等待第三方：是否暂停取决于适用约定。即使允许暂停，也应记录交付依赖和客户更新安排，不能把所有外部原因一概排除。
• 换班或个人下班：看服务日历与整体服务安排，不按当前个人是否在岗决定。需要交接时，把剩余时间和下一步一起交给接班人。

换班交接还需要确认接收人和回执，具体可参考客服工单换班交接的组织方法。交接记录解决“谁接着做”，SLA规则解决“哪些时间应累计”，两者应关联但不能互相替代。

上线前，把这些边界情况走一遍

如果当前服务系统不能准确表达某条规则，先明确记录与复核办法，或调整规则设计再上线。不要让文字承诺与系统实际计时各算各的，最后只能凭记忆解释差异。

用流程图做一次计时规则走读

在Boardmix画布中，将“创建—首次响应—处理中—等待资料—恢复—解决”排列成实际路径；从等待资料画回处理中，不把它画成结束。节点旁分别标注响应时钟与解决时钟的状态，必要时将服务日历单独放在图侧。

不要只画正常路径。用前面的跨周末案例，再补非工作时间提交、内部转交、重开和优先级变化，邀请客服、技术支持和服务负责人逐条计算。每出现不同答案，就定位是开始事件、暂停条件、日历还是完成标准没有说清楚。

规则确认后，留下适用服务、规则版本、生效时间、负责人以及与工单系统配置的对应关系。实施人员按该规则配置，服务负责人用样例工单核对实际结果；白板上的“已确认”不代表系统已经正确执行。

看达标率时，也检查未完成工单和真实等待

有了计时规则，还要统一报表口径。统计周期内是按创建、解决还是完成的SLA周期归属？取消和重复工单是否排除？仍未解决但已超时的事项怎样展示？这些会改变达标率的分子与分母，应在报表旁说明。

响应达标率与解决达标率分别看，不能平均成一个模糊的“服务效率”。同时观察未解决超时、等待资料、重开以及客户实际等待时间。一个工单即使按规则暂停很久，客户仍在等待；持续发现同类等待时，应改进资料收集或处理安排，而不只是庆祝计时数字好看。

好的SLA能让团队知道什么时候需要响应、怎样推进到解决、哪些时间需要解释。先把规则讲清并走读一致，再交给系统计时，才有可能据此发现真正的服务问题。