售后工单：微信群当工单的三个代价

先说结论

用微信群当工单系统，最大的代价不是「看起来不专业」，而是三件事同时失效：谁负责、到哪一步、什么时候回客户。

这三件事在群里都只能靠往上翻聊天记录来回答，而翻记录的人越多，越没人真去翻。

三件事是怎么失效的

一、没指派，就等于没工单

群里发一条「某某客户报修，麻烦看一下」，看起来是通知了所有人，实际上是「谁都可以接」。等到客户追问，第一条回复往往是「这个不是我对的吧」。

派单的第一要素不是速度，是唯一性。

二、没有计时，就没有优先级

客户投诉「等了三天没人理」时，团队往往说「我们当天就回复了」——两边都没撒谎。问题在于没有计时口径：从报修到受理算不算响应？受理到上门算不算？

没有计时，紧急与不紧急就只能靠喊。

三、没有台账，就没有复盘

同型号设备反复出同一个问题、某个师傅的返修率明显偏高、某批配件的问题集中爆发——这些结论都来自台账。群里能翻到的只有零散的对话，无法汇总。

售后最值钱的产出不是把这一次修好，是知道下一次该防什么。 客户资料层面的同类问题——记录留在个人手里、人一走就断——见客户资料：怎么从个人手里收进公司。

三个卡点

• 报修入口分散：客户打电话、发微信、找业务员、在群里说。入口一散，条数就永远对不齐。
• 派单靠喊：在群里问一句「谁有空」，谁在线谁接。忙的人永远不被派到，闲的人接过量。
• 进度没人回：处理的人知道，客户不知道，销售也不知道，于是销售去问处理的人，处理的人再解释一遍。

做法：把群当入口，把工单当载体

关键的一点是：不要去改变客户的行为。 客户习惯在群里说，就让他在群里说；要变的是内部的记录方式。

1. 群里建单。 客户在Spell IM的群里说一句报修，自动生成一条工单记录，带上客户、设备、时间和来源。
2. 自动派单与时限提醒。 按设备型号、区域或责任人规则派单；超过约定时长没有动作，自动提醒责任人并升级。
3. 回客户的话由记录生成。 当前状态、预计时间、处理人，回到同一个群里。销售不用再私下去问。
4. 月度汇总。 工单量、处理时长、重复报修项自动汇总成一张表。哪一个型号问题最集中，一眼能看出来。

工单台账与汇总用Spell Table，派单与超时升级走Spell Flow。

三条不能让步的要求

• 一条工单只在一个地方改。 允许两个地方同时改成两种状态，比没有系统更麻烦。
• 超时必须提醒，而不是月底统计。 超时提醒的价值在当天，月底统计的价值在明年。
• 客户可见的信息要收口。 客户看得到的是状态与时间，不是内部备注与成本信息。权限按角色划分。

常见问题

客户就是不肯用小程序或公众号报修怎么办？

那就不要强推。入口跟客户走、记录留在内部，是成本最低的组合。把要客户适应系统当成前提，多数售后改造会卡在第一步。

我们单量不大，值得做吗？

单量小的时候价值更明显：没有人专门盯工单，靠人记必然漏。判断标准是「上周有没有客户问过进度」，只要有，就值得先做第一步。

派单规则要不要写得很细？

第一条规则写简单一点：按区域或按型号。跑一段时间后，把实际派偏的案例补进规则。规则是收敛出来的，不是设计出来的。

和客服系统有什么区别？

客服系统处理的主要是「咨询与解答」，售后工单处理的是「到现场把事做完」。判断标准是这件事有没有物理动作和完成确认——有的话，本质上是工单，不是会话。

资料来源与说明

• 我方项目信息：来自已交付项目，可公开的部分已在正文中链至对应案例页。
• 行业通识：岗位与流程层面的公认常识，不另注来源。
• 判断性表述：我方基于上述资料的综合判断，以「通常」「普遍」表述，不作绝对化断言。