À quoi ressemble vraiment 60% de l'attrition MSP (Ce n'est pas technique)

Le mythe de l’attrition MSP

Demandez à un propriétaire de MSP pourquoi son dernier client parti est parti. Vous entendrez, approximativement dans cet ordre :

1. « Ils ont été acquis. »
2. « Comparaison de prix. »
3. « Ils ont internalisé l’IT. »
4. « On ne sait pas — ils ont juste arrêté de répondre. »

Vous n’entendrez presque jamais « notre travail technique était mauvais ».

C’est parce que du point de vue du MSP, le travail technique n’était pas mauvais. Tickets fermés. SLA pour la plupart respectés. Patchs déployés. Sauvegardes vérifiées. Quand un propriétaire examine les données de performance d’un compte perdu, tout a l’air bien.

Mais le client qui est parti ? Il a une histoire complètement différente.

Ce que disent vraiment les données

Plusieurs enquêtes sectorielles — ConnectWise State of SMB IT, rapports annuels de Kaseya, benchmarks des groupes de pairs MSP — convergent vers un chiffre qui s’accorde mal avec la plupart des auto-perceptions MSP :

Environ 60% de l’attrition client MSP est liée à la communication, pas à la qualité technique.

Ce n’est pas aussi de la communication. C’est principalement de la communication. Six clients sur dix qui partent ne sont pas partis parce que quelque chose s’est cassé. Ils sont partis à cause de ce que cela faisait ressentir pendant que rien ne se cassait.

Voici à quoi ressemblent ces événements d’attrition dans les mots des clients.

Les cinq scénarios

Scénario 1 — La messagerie vocale du vendredi 17h30

Le CFO client laisse un message vocal à 17h28 le vendredi. Le serveur de messagerie semble lent — probablement rien, mais veut confirmer. La messagerie dit « rappelez-moi quand vous pouvez, ce n’est pas urgent ». L’équipe MSP est occupée, se déconnecte à 17h45. Pas de rappel. Lundi matin 9h, l’e-mail arrive : « Salut — suite à mon VM de vendredi. Tout va bien ? »

Le problème n’était rien. L’e-mail fonctionnait. Mais le client sait maintenant : « pas urgent » de leur part signifie « rien jusqu’à lundi » du MSP. Huit mois plus tard, ils signent avec un concurrent qui « répond juste au téléphone ».

Le système de ticketing du MSP n’a aucune trace de cet événement d’attrition. Pas de P1, pas de breach, pas de SLA. Juste un message vocal qui est devenu une perte de client que le MSP a attribuée à « la comparaison de prix ».

Scénario 2 — L’écart de mise à jour de 6 heures

Ticket helpdesk ouvert à 9h12 : l’imprimante ne fait pas de recto-verso. P3, routine. Un tech le prend à 11h30, commence à enquêter. Le tech est tiré vers une panne P1 à 11h50. Le ticket de l’imprimante reste en attente. À 15h, le client envoie un message au helpdesk : « Quelqu’un regarde ça ? » Le ticket est finalement résolu à 17h45 — techniquement sous SLA.

Mais l’expérience du client a été six heures de silence ponctuées par le besoin de poursuivre. Le journal du ticket montre un temps de résolution parfaitement acceptable. La perception du client est que personne ne s’en souciait jusqu’à ce qu’il harcèle.

Scénario 3 — Le trou noir d’escalade

Le VP des Ops appelle à 23h40 — alerte ransomware, probablement un faux positif, mais a besoin de surveillance maintenant. Le tech d’astreinte gère cela en 20 minutes, confirme un faux positif, retourne au lit. Le système de ticketing obtient une entrée le lendemain matin quand le tech la rédige.

L’expérience du VP : « J’ai appelé à minuit pour un éventuel événement ransomware. La personne à qui j’ai parlé m’a dit que c’était bon. Je n’ai jamais rien entendu d’autre à ce sujet. Pas d’e-mail de confirmation. Pas de rapport. Rien. »

Le MSP n’a jamais enregistré l’érosion de confiance du client. Du point de vue de son système, ce fut une résolution nocturne réussie.

Scénario 4 — Le rapport qui n’arrive jamais

Le client signe un contrat qui inclut « rapports de statut mensuels ». Le MSP a l’intention de les produire. Le tech senior est toujours occupé. Les trois premiers rapports sont à temps. Les mois 4–5 glissent à trimestriel. Les mois 6–12, pas de rapports produits.

Quand le CFO du client demande au moment du renouvellement pourquoi ils devraient renouveler, le MSP cite les statistiques d’uptime et les volumes de tickets. Le CFO, qui n’a jamais vu ces chiffres de manière proactive, ne peut pas les connecter émotionnellement à la valeur.

Les clients qui reçoivent des rapports mensuels renouvellent environ 2× plus souvent que les clients qui n’en reçoivent pas.

Scénario 5 — Le triage incohérent

Le P2 d’un client est résolu en 45 minutes par Sarah. Le P2 structurellement identique d’un autre client prend 6 heures parce que Mike est le tech du jour et les traite dans l’ordre inverse de priorité. Les deux SLA sont respectés.

Mais les deux clients se parlent à leur conférence sectorielle et découvrent qu’ils obtiennent un service différent sur le même contrat. Le client avec l’expérience plus lente ne part pas immédiatement — mais ne recommande jamais le MSP à quiconque.

Le taux de recommandation est une fonction directe de la cohérence du temps de réponse, pas de la vitesse du temps de réponse.

Pourquoi les MSP sont aveugles à cela

La plupart des MSP examinent trois chiffres lors de l’évaluation de la santé opérationnelle :

1. Tickets résolus par période
2. Conformité SLA moyenne
3. Scores de satisfaction client des sondages de sortie

Tous trois sont des indicateurs retardés qui masquent systématiquement les échecs de communication.

• Les comptes de résolution de tickets ne capturent pas le message vocal du vendredi qui est devenu un compte perdu.
• La conformité SLA moyenne peut être à 97% tout en produisant les 3% d’expériences qui entraînent l’attrition.
• Les sondages de sortie sont remplis par des clients qui ont déjà décidé de partir.

Le correctif n’est pas un meilleur système de ticketing

Chaque fois qu’un MSP perd un client et décide ensuite de « resserrer le suivi SLA », il résout un symptôme, pas le problème.

Le problème est que la cohérence de la communication nécessite l’application au niveau du premier contact — au moment où se produit une interaction client, avant qu’elle ne devienne un ticket, avant qu’elle ne soit enregistrée.

Cela nécessite :

• Chaque contact client obtient une confirmation instantanée, quelle que soit l’heure
• Chaque réponse rédigée par IA passe par une file d’attente d’approbation humaine avant d’atteindre le client
• Chaque interaction est enregistrée, que le client ait ouvert un ticket formel ou non
• Chaque client obtient une qualité de service cohérente quel que soit le tech de garde

Voyez votre propre risque d’attrition en cinq minutes

Nous avons construit un diagnostic à 6 questions qui fait émerger les fuites opérationnelles de votre MSP — y compris les risques liés à la communication qui n’apparaissent pas dans vos rapports PSA. Pas de compte requis.

→ Faites l’audit des fuites opérationnelles MSP

L’un des résultats est un score qualitatif de risque d’attrition basé sur la quantité de communication client enregistrée par votre organisation, plutôt que de la laisser vivre dans les têtes, Slacks et e-mails. Si le score revient ÉLEVÉ, c’est généralement la fuite qui ferme le plus gros écart en dollars.