MSP流失神话
问一个MSP业主为什么他们最近失去的客户离开了。您将听到,大约按这个顺序:
- “他们被收购了。”
- “比价购物。”
- “他们内化了IT。”
- “我们不知道——他们就是不再回复了。”
您几乎永远不会听到”我们的技术工作不好。”
那是因为从MSP的角度看,技术工作并不糟糕。工单关闭。SLA大多达标。补丁部署。备份已验证。当业主审查流失账户的性能数据时,通常看起来没问题。
但离开的客户?他们有一个完全不同的故事。
数据实际说什么
多项行业调查——ConnectWise State of SMB IT、Kaseya的年度报告、MSP同行组基准——汇聚在一个与大多数MSP自我认知不协调的数字上:
大约60%的MSP客户流失是沟通驱动的,不是技术质量驱动的。
那不是也是沟通。那是主要是沟通。离开的10个客户中有6个不是因为某事坏了才离开。他们是因为在没有东西坏的时候感觉而离开的。
以下是这些流失事件以客户的话实际看起来的样子。
五个场景
场景1 — 周五下午5:30的语音邮件
客户CFO在周五17:28留下语音邮件。邮件服务器感觉慢——可能没问题,但想确认。语音邮件说”有时间回电,不紧急。“MSP团队正忙,17:45下班。没有回电。周一早上9:00邮件来了:“嘿——关于我周五的VM。一切都好吗?”
问题什么都没有。邮件没问题。但客户现在知道:他们说的”不紧急”对MSP意味着”周一之前没有动作”。八个月后,他们与”就是接电话”的竞争对手签了约。
**MSP的工单系统没有此流失事件的记录。**没有P1,没有违规,没有SLA。只有一个最终变成客户损失的语音邮件,MSP将其归因于”比价购物”。
场景2 — 6小时更新差距
帮助台工单在上午9:12打开:打印机不能双面打印。P3,例行。一名技术员在11:30接手开始调查。技术员在11:50被拉去处理P1故障。打印机工单搁置。下午3点客户给帮助台发消息:*“有人在看这个吗?”*工单最终在17:45解决——技术上在SLA内。
但客户的体验是六小时的沉默,间断地不得不追问。工单日志显示完全可以接受的解决时间。客户的感知是直到他们抱怨之前没人在意。
场景3 — 升级黑洞
运营副总裁在23:40打电话——勒索软件警报,可能是误报,但现在需要有人看看。值班技术员20分钟内处理,确认误报,回去睡觉。工单系统第二天早上技术员写下来时才获得条目。
副总裁的体验:“我半夜打电话问一个可能的勒索软件事件。我通话的人告诉我没事。我再也没听到任何关于它的消息。没有确认邮件。没有报告。什么都没有。”
MSP从未记录过客户的信任侵蚀。从其系统视角看,那是一次成功的隔夜解决。
场景4 — 永远不来的报告
客户签了一份包含”月度状态报告”的合同。MSP打算制作这些。高级技术员总是很忙。前三份报告准时。第4-5个月滑到季度。第6-12个月,没有报告产生。
当客户的CFO在续约时问为什么应该续约时,MSP引用正常运行时间统计和工单量。从未被主动展示这些数字的CFO无法将它们与价值情感上联系起来。
收到月度报告的客户续约率约为不收到客户的2倍。
场景5 — 不一致的分诊
一个客户的P2在Sarah那里45分钟解决。另一个客户结构相同的P2花了6小时,因为Mike是那天的技术员,按相反优先级处理它们。两个SLA都达标。
但两个客户在他们的行业会议上交谈,发现他们在同一份合同上得到不同的服务。经历较慢的客户不会立即离开——但再也不会向任何人推荐MSP。
推荐率是响应时间一致性的直接函数,而不是响应时间的速度。
为什么MSP对此视而不见
大多数MSP在评估运营健康时查看三个数字:
- 每期解决的工单
- 平均SLA合规性
- 退出调查的客户满意度得分
所有三个都是系统性隐藏沟通失败的滞后指标。
- 工单解决计数不捕捉成为失去账户的周五语音邮件。
- 平均SLA合规性可以是97%,同时仍产生导致流失的3%经验。
- 退出调查由已经决定离开的客户填写。
修复不是更好的工单系统
每次MSP流失一个客户然后决定”加强SLA跟踪”时,他们都在解决症状,而不是问题。
问题是沟通一致性需要在首次接触层执行——在发生客户互动的那一刻,在它成为工单之前,在被记录之前。
这需要:
- 无论时间如何,每次客户接触都立即得到确认
- 每个AI起草的响应在到达客户之前都通过人工审批队列
- 无论客户是否开启正式工单,每次互动都被记录
- 无论哪个技术员值班,每个客户都获得一致的服务质量
5分钟查看您自己的流失风险
我们构建了一个6问题诊断,揭示您MSP的运营泄漏——包括不在PSA报告中显示的沟通驱动风险。无需账户。
输出之一是基于您的组织记录了多少客户沟通与让它存在于头脑、Slack和邮件中的定性流失风险评分。如果评分回来是HIGH,那通常是关闭最大美元缺口的漏洞。