El mito del churn MSP
Pregúntele a un propietario de MSP por qué se fue su último cliente perdido. Escuchará, aproximadamente en este orden:
- “Fueron adquiridos.”
- “Comparación de precios.”
- “Internalizaron IT.”
- “No lo sabemos — simplemente dejaron de responder.”
Casi nunca escuchará “nuestro trabajo técnico era malo.”
Eso es porque desde la perspectiva del MSP, el trabajo técnico no fue malo. Tickets cerrados. SLA mayormente cumplidos. Parches desplegados. Backups verificados. Cuando un propietario revisa los datos de rendimiento de una cuenta perdida, por lo general se ve bien.
Pero el cliente que se fue? Tiene una historia completamente diferente.
Lo que realmente dicen los datos
Múltiples encuestas de la industria — ConnectWise State of SMB IT, informes anuales de Kaseya, benchmarks de grupos de pares MSP — convergen en un número que se sienta incómodamente con la mayoría de la autopercepción de los MSP:
Aproximadamente el 60% del churn de clientes MSP es impulsado por la comunicación, no por la calidad técnica.
Eso no es también comunicación. Es predominantemente comunicación. Seis de cada diez clientes que se van no se fueron porque algo se rompió. Se fueron por cómo se sentían mientras nada se rompía.
Así es como se ven realmente esos eventos de churn en las palabras del cliente.
Los cinco escenarios
Escenario 1 — El buzón de voz del viernes a las 17:30
El CFO cliente deja un mensaje de voz a las 17:28 el viernes. El servidor de correo se siente lento — probablemente bien, pero quiere confirmar. El mensaje dice “llámenme cuando puedan, no es urgente.” El equipo MSP está ocupado, se desconecta a las 17:45. Sin devolución de llamada. Lunes 9:00 AM llega el email: “Hola — siguiendo mi VM del viernes. ¿Todo bien?”
El problema no era nada. El correo estaba bien. Pero el cliente ahora sabe: “no urgente” de ellos significa “nada hasta el lunes” del MSP. Ocho meses después, firman con un competidor que “simplemente contesta el teléfono.”
El sistema de ticketing del MSP no tiene registro de este evento de churn. No P1, no breach, no SLA. Solo un mensaje de voz que eventualmente se convirtió en una pérdida de cliente que el MSP atribuyó a “comparación de precios.”
Escenario 2 — La brecha de actualización de 6 horas
Ticket de helpdesk abre a las 9:12 AM: la impresora no hace dúplex. P3, rutina. Un técnico lo toma a las 11:30, comienza a investigar. El técnico es tirado a una interrupción P1 a las 11:50. El ticket de la impresora queda. A las 15:00 el cliente mensajea al helpdesk: “¿Alguien está mirando esto?” El ticket finalmente se resuelve a las 17:45 — técnicamente bajo SLA.
Pero la experiencia del cliente fue seis horas de silencio puntuadas por tener que perseguir. El registro del ticket muestra un tiempo de resolución perfectamente aceptable. La percepción del cliente es que a nadie le importó hasta que molestaron.
Escenario 3 — El agujero negro de escalación
El VP de Ops llama a las 23:40 — alerta de ransomware, probablemente falso positivo, pero necesita ojos ahora. El técnico de guardia lo maneja en 20 minutos, confirma falso positivo, vuelve a la cama. El sistema de ticketing obtiene una entrada a la mañana siguiente cuando el técnico lo redacta.
La experiencia del VP: “Llamé a medianoche por un posible evento de ransomware. La persona con quien hablé me dijo que estaba bien. Nunca escuché nada más al respecto. Sin email de confirmación. Sin informe. Nada.”
El MSP nunca registró la erosión de confianza del cliente. Desde la vista de su sistema, fue una resolución nocturna exitosa.
Escenario 4 — El informe que nunca llega
El cliente firma un contrato que incluye “informes de estado mensuales.” El MSP pretende producirlos. El técnico senior siempre está ocupado. Los primeros tres informes son a tiempo. Los meses 4–5 se deslizan a trimestrales. Meses 6–12, no se producen informes.
Cuando el CFO del cliente pregunta en el momento de renovación por qué deberían renovar, el MSP cita estadísticas de uptime y volúmenes de tickets. El CFO, a quien nunca se le mostraron esos números proactivamente, no puede conectarlos emocionalmente con el valor.
Los clientes que reciben informes mensuales renuevan aproximadamente 2× más que los clientes que no.
Escenario 5 — El triage inconsistente
Un P2 de un cliente es resuelto en 45 minutos por Sarah. Un P2 estructuralmente idéntico de otro cliente toma 6 horas porque Mike es el técnico del día y los maneja en orden inverso de prioridad. Ambos SLA se cumplen.
Pero ambos clientes se hablan en su conferencia de industria y descubren que están obteniendo servicio diferente en el mismo contrato. El cliente con la experiencia más lenta no se va inmediatamente — pero nunca recomienda el MSP a nadie.
La tasa de recomendación es una función directa de la consistencia del tiempo de respuesta, no de la velocidad.
Por qué los MSP son ciegos a esto
La mayoría de los MSP miran tres números al evaluar la salud operativa:
- Tickets resueltos por período
- Cumplimiento promedio de SLA
- Puntajes de satisfacción del cliente de encuestas de salida
Los tres son indicadores rezagados que sistemáticamente ocultan fallas de comunicación.
- Los conteos de resolución de tickets no capturan el mensaje de voz del viernes que se convirtió en una cuenta perdida.
- El cumplimiento promedio de SLA puede ser 97% y aún así producir el 3% de experiencias que impulsan el churn.
- Las encuestas de salida son completadas por clientes que ya decidieron irse.
La solución no es un mejor sistema de ticketing
Cada vez que un MSP pierde un cliente y luego decide “apretar el seguimiento SLA,” está resolviendo un síntoma, no el problema.
El problema es que la consistencia de comunicación requiere aplicación en la capa del primer contacto — en el momento en que ocurre una interacción con el cliente, antes de que se convierta en ticket.
Eso requiere:
- Cada contacto del cliente recibe un reconocimiento instantáneo, sin importar la hora
- Cada respuesta redactada por IA pasa por una cola de aprobación humana antes de llegar al cliente
- Cada interacción se registra, ya sea que el cliente haya abierto un ticket formal o no
- Cada cliente recibe calidad de servicio consistente sin importar qué técnico estuviera de turno
Vea su propio riesgo de churn en cinco minutos
Construimos un diagnóstico de 6 preguntas que emerge las fugas operativas de su MSP — incluyendo los riesgos impulsados por comunicación que no aparecen en sus informes PSA. No se requiere cuenta.
→ Haga la Auditoría de Fugas Operativas del MSP
Uno de los resultados es un puntaje cualitativo de riesgo de churn basado en cuánta comunicación con el cliente registra su organización versus cuánta vive en cabezas, Slacks y correos. Si el puntaje regresa ALTO, esa suele ser la fuga que cierra la mayor brecha en dólares.