Castro Podcasts : pourquoi la tentative de créer une relation via le support client a échoué
(uncommonapps.nyc)- Après le rachat de Castro, l’équipe a voulu se différencier avec un support humain en utilisant le produit tous les jours et en répondant à tous les e-mails, mais cela n’a pas généré autant de fidélité ou de sympathie client qu’espéré
- Quand une solution correcte pouvait être donnée immédiatement, la satisfaction était élevée, mais la plupart des réponses attentives ne correspondaient pas aux attentes des utilisateurs et ont parfois accentué leur frustration
- Les demandes liées au prix de l’abonnement, aux bugs difficiles à reproduire ou aux demandes de fonctionnalités pouvaient signaler des pistes d’amélioration produit, sans pour autant constituer une solution suffisante pour les clients
- Les problèmes complexes qu’un humain pouvait réellement résoudre, comme les comptes App Store ou les abonnements, étaient bien reçus, mais représentaient moins de 1 % de l’ensemble des e-mails de support
- Pour l’équipe Castro, il valait mieux lire les e-mails et se concentrer sur l’amélioration du produit que de fournir de longues explications, et les expériences positives naissaient davantage de vraies améliorations produit que des conversations avec le support
Le modèle de support qu’attendait Castro
- Lors du rachat de Castro, l’équipe pensait qu’un support humain fondé sur une vraie expérience utilisateur pouvait être un facteur de différenciation facile à mettre en place
- Comme elle recevait rarement des réponses utiles du support des services qu’elle utilisait au quotidien, elle s’attendait à ce que les clients apprécient le fait d’utiliser le produit elle-même chaque jour, de lire tous les e-mails et d’y répondre avec soin
- Quand le volume d’e-mails est devenu difficile à gérer, l’équipe a rémunéré un utilisateur qui connaissait très bien le produit et écrivait souvent pour prendre en charge les réponses du support
- Cet utilisateur obtenait notamment de bons résultats pour résoudre directement les problèmes des utilisateurs
- Les résultats ont été différents de ce qui était attendu
- Lorsqu’il était possible de répondre immédiatement et d’apporter une solution précise, cela pouvait surprendre agréablement les clients
- Mais la plupart des réponses consciencieuses n’apportaient pas une grande satisfaction aux clients et les rendaient parfois encore plus agacés
Questions sur l’abonnement et le prix
- Les e-mails concernant l’abonnement et le prix n’ont presque pas aidé à créer une relation
- Castro avait déjà longuement réfléchi à sa tarification et à son modèle d’abonnement, et ne modifiait pas sa politique à cause d’un seul e-mail
- Il était possible d’expliquer pourquoi une app essentielle mérite qu’on la paie ou pourquoi un logiciel se prête bien à un modèle par abonnement, mais les utilisateurs étaient en général peu satisfaits de cette réponse
- En deux ans, il n’y a eu qu’environ une personne à accepter avec surprise l’idée qu’un abonnement était justifié parce qu’un logiciel coûte de l’argent et nécessite du travail chaque jour
- Dans 99 % des cas, même avec une explication prudente et aimable, la réponse revenait plus négative que l’e-mail initial
- Castro a aussi essayé d’offrir 30 jours d’essai supplémentaires à ceux qui en faisaient la demande, mais cela n’a pas changé le ton des échanges, et le taux de conversion de cet essai était nettement inférieur à celui de l’essai gratuit standard
Ce que signalent les bugs, et leurs limites
- Les e-mails de bug sont réellement utiles pour l’équipe qui les reçoit
- Ils permettent d’identifier les problèmes que les utilisateurs rencontrent au quotidien
- Si le bug est déjà connu et en cours de correction, ou déjà corrigé, il est possible d’apporter une réponse satisfaisante au client
- À cause du mode de distribution de l’App Store, il arrive souvent qu’un bug soit corrigé mais pas encore déployé
- Le problème, c’est que beaucoup de bugs n’entrent pas dans ce cas idéal
- Certains bugs ont déjà été signalés, mais ne peuvent pas être confirmés ni reproduits directement
- Cela conduit soit à demander davantage d’efforts à l’utilisateur, soit à ne pas lui apporter de solution, ce qui est une mauvaise expérience pour les deux parties
- Très occasionnellement, un rapport détaillé avec des étapes de reproduction ou des conditions utiles arrive
- Il y a aussi des bugs dont l’équipe entend parler pour la première fois
- L’utilisateur peut fournir des détails, mais si le problème n’apparaît pas chez d’autres, il risque d’être peu prioritaire
- Certains e-mails se limitent à dire « ça ne marche pas »
- Sans informations supplémentaires de l’utilisateur, il n’y a presque rien à faire
- D’autres problèmes sont déjà connus, mais leur correction demande trop de travail, leur impact est faible ou ils touchent trop peu d’utilisateurs pour être prioritaires
- Certains bugs ont déjà été signalés, mais ne peuvent pas être confirmés ni reproduits directement
- Les réponses dans ces catégories n’ont pas créé de véritable proximité
- Répondre honnêtement quelque chose qui revient à dire « nous ne pouvons pas résoudre ce problème aujourd’hui et nous n’allons même pas essayer » peut être une très mauvaise expérience pour l’utilisateur
- Les e-mails de support sont utiles comme signaux de problème, mais Castro obtenait en général de meilleures données via la télémétrie et les crash logs
Les rares cas où l’intervention humaine aide vraiment
- Il arrive de recevoir des questions complexes sur les procédures App Store, des problèmes de boutique, certaines régions ou des cas très spécifiques liés aux podcasts
- Un utilisateur avait un abonnement Castro sur deux comptes différents à des moments différents, et voulait en laisser un expirer tout en conservant la période déjà payée
- Castro a résolu ce problème rapidement, et ce type de réactivité est réellement apprécié par les utilisateurs
- Mais ces demandes représentaient moins de 1 % des e-mails de support, ce qui leur donnait trop peu de poids pour faire du support une stratégie de différenciation
Clients perdus et charge répétitive
- Il arrive que des clients écrivent parce qu’ils sont perdus sur le fonctionnement des podcasts, de l’App Store, de leur Mac ou d’autres problèmes périphériques
- Ce type d’échange était celui qui se rapprochait le plus de la relation client que Castro espérait construire, mais c’est aussi celui qui a donné les pires résultats
- Les mêmes utilisateurs revenaient souvent, et une fois qu’ils comprenaient que Castro répondait, leurs demandes avaient tendance à devenir plus fréquentes et plus lourdes à gérer
- Au lieu de construire une relation et de la fidélité, cela amenait en pratique à consacrer beaucoup de temps aux personnes les plus exigeantes
- Leur abonnement n’était pas plus cher
- Elles étaient rarement satisfaites
- Au final, cela donnait le sentiment de se faire exploiter
Demandes de fonctionnalités et orientation produit
- Les demandes de fonctionnalités et les retours généraux sont en théorie intéressants et parfois utiles, mais ils viennent souvent de manière répétée d’un petit groupe d’utilisateurs très engagés et peu représentatifs
- Mettre en œuvre des suggestions reçues par e-mail expose rapidement au risque de recevoir la roadmap produit complète
- Castro est une app à la direction très affirmée, et l’équipe a déjà beaucoup réfléchi à ce qu’elle veut construire et à ce qu’elle veut faire ensuite
- Les demandes de fonctionnalités ont peu de chances d’être réellement implémentées
- Se plier davantage aux power users risque d’éloigner les nouveaux utilisateurs, qui comprennent moins bien le fonctionnement du produit
- Les power users sont une catégorie d’utilisateurs relativement moins susceptible de partir
- Éloigner les nouveaux utilisateurs serait critique pour le produit
- Du point de vue des utilisateurs, toute réponse qui n’est pas « nous allons le faire tout de suite » est généralement reçue de manière tiède ou négative
- Même une réponse honnête expliquant que l’idée avait déjà été envisagée ou testée sans succès n’a pas beaucoup aidé à créer de la fidélité ou de la proximité
Le mode de fonctionnement du support choisi par Castro
- Pour Castro, consacrer trop de temps au support n’était pas un facteur de différenciation et produisait souvent l’effet inverse
- Les clients qui paient leur abonnement sans rien demander gratuitement par e-mail méritent tout autant une bonne app que ceux qui écrivent chaque semaine
- Lorsqu’il existe une solution claire ou un correctif précis à un problème, il est préférable d’intervenir activement
- Dans les autres cas, il vaut mieux répondre brièvement que l’e-mail a bien été reçu et lu, et que le produit continue d’être amélioré pour corriger le problème
- Éviter les explications et les détails permet généralement d’obtenir une réaction neutre, sans entraîner personne dans de longues conversations ni y consacrer trop de temps
- Pour Castro, l’approche utilisée par la plupart des entreprises était en réalité la plus adaptée
- Quand un utilisateur est frustré et que quelque chose ne fonctionne pas, il est difficile de créer de la fidélité ou de la proximité, et les vraies expériences positives surviennent quand le produit s’améliore
1 commentaires
Avis de Hacker News
Il m’est rarement arrivé d’obtenir une réponse utile du support client des services que j’utilise. Je me disais donc que si j’utilisais mon propre produit tous les jours, que je lisais tous les e-mails et que j’y répondais avec sérieux, les gens seraient reconnaissants et qu’un certain niveau de fidélité et de sympathie se créerait.
Je gère une app utilisée par 16 000 personnes, je reçois 2 à 5 tickets de support par semaine et je les lis tous.
Environ 20 % de l’app a été construit à partir de suggestions d’utilisateurs, et les gens sont globalement aimables et font gratuitement la promotion de l’app sur plusieurs plateformes. Il n’y a pas de budget marketing.
Les utilisateurs n’expriment pas toujours leur gratitude avec des mots, mais ils aident activement à résoudre les problèmes en envoyant des étapes de reproduction claires, des captures d’écran ou des vidéos, et en répondant rapidement aux questions de suivi. Il m’arrive aussi souvent d’être surpris en voyant des gens recommander mon app dans des commentaires Reddit ou YouTube.
Si vous soutenez bien vos utilisateurs, il y a de fortes chances qu’ils vous le rendent déjà à leur manière.
Ce n’est pas un commentaire particulièrement passionnant, mais comme les réactions semblent très négatives, j’aimerais apporter un peu d’équilibre.
Le fait d’avoir mené l’expérience est intéressant, et merci d’en avoir partagé les résultats. C’est un peu déprimant, mais globalement cela paraît raisonnable.
Assurer le support de clients entreprises qui dépensent jusqu’à plusieurs millions de dollars par an, et celui d’utilisateurs finaux qui scrutent chaque centime dépensé, ce sont deux mondes totalement différents en matière d’attentes, de compétences techniques, de professionnalisme, etc.
À mon avis, ce billet résume bien le fait qu’on ne peut pas toujours aider tous les utilisateurs. C’est une leçon difficile à apprendre dans le support technique, et tout le monde aimerait être le chevalier brillant qui résout les problèmes des clients, mais la capacité à dire « non » de la bonne manière est rare.
À ceux qui attaquent l’auteur : même si vous payiez des gens pour utiliser votre logiciel, il y en aurait encore énormément pour se plaindre et vous insulter. Composer avec les intérêts des clients, la pression du temps, la santé mentale individuelle, etc., c’est quasiment tel quel le travail de support technique.
Comme c’est un retour d’expérience qui mérite réflexion, je l’ai immédiatement envoyé à quelques fondateurs en phase initiale qui brûlent une quantité surprenante de temps avec des clients qui ne sont pas les bons.
L’idéalisme ne tient pas longtemps face à la réalité.
Le cœur du texte, c’est ceci : « Autrement dit, la meilleure approche pour nous est celle que la plupart des entreprises adoptent. »
Tout fondateur inexpérimenté commence en promettant qu’il ne fera pas un support aussi médiocre que les grandes entreprises comme Google ou Comcast, et croit que ce sera une voie vers le succès.
Mais il finit par apprendre qu’il doit proposer le même niveau de support que les autres entreprises de son marché. Même si le support est vraiment meilleur, personne ne le remarque vraiment, et cela ne change pas grand-chose.
Les fondateurs inexpérimentés sont têtus, et c’est aussi une qualité. C’est pourquoi ils n’apprennent généralement cette leçon qu’après l’avoir vécue eux-mêmes.
Mais le support façon grande entreprise n’est inévitable que lorsque l’entreprise doit absolument passer à l’échelle. Dans beaucoup de marchés, on peut très bien survivre avec des marges plus élevées et un produit/support premium.
Voir le support client comme un « facteur de différenciation » ou comme une façon de générer du revenu est déprimant. Il faudrait simplement essayer de faire ce qui est le mieux pour les clients.
Le feedback reçu actuellement vaut de l’or et, s’il est bien traité, il peut être exploité plutôt qu’ignoré. Le fait de présumer que les gens opposés au modèle de prix ne comprennent rien au business en dit aussi long.
Il faut reconnaître que son modèle de prix ne convient pas à certaines personnes, en particulier à celles qui souffrent de fatigue des abonnements, puis décider si l’on accepte de perdre leur argent, ou de ne jamais l’obtenir.
La stratégie de support ne prévoit pas de canal pour les utilisateurs qui ont beaucoup de questions, ce qui revient en pratique à reprocher aux clients les défauts de sa propre structure. Il serait facile de créer au moins un forum où les utilisateurs avancés s’entraident et où les développeurs interviennent de temps en temps pour aider ou consigner les problèmes.
En plus, les processus de développement et d’assurance qualité doivent clairement être réexaminés. Si les signalements de bugs donnent l’impression d’être « une perte de temps pour tout le monde », c’est probablement parce que l’app elle-même ne dispose pas d’une journalisation des erreurs ou d’une télémétrie appropriée. Le simple fait de devoir attendre les rapports de bugs manuels des utilisateurs est déjà un échec.
Définir le produit comme on le souhaite et refuser des demandes de fonctionnalités, c’est tout à fait acceptable ; mais dire qu’on a pensé à tous les problèmes tout seul assis sur sa chaise, par comparaison avec la pensée distribuée de tous les autres, c’est assez arrogant.
Une app appelée PhotoSync propose son option premium à 1 dollar par mois ou 24 dollars à vie. C’est probablement parce qu’ils ont regardé la durée moyenne d’abonnement et qu’elle tournait autour de 2 ans. Sans même parler de la valeur temps de l’argent et des frais de traitement par transaction.
Personnellement, même sans être sûr d’utiliser encore cette app dans 24 mois, l’achat unique me convenait beaucoup mieux. Cela correspond davantage à ma façon un peu chaotique de gérer mon argent.
Quand on déploie une mise à jour auprès de 2 % des utilisateurs, il faut disposer de suffisamment de logs et de télémétrie pour savoir si quelque chose s’est très mal passé avant de l’envoyer aux 98 % restants.
En revanche, on ne veut probablement pas une télémétrie capable de détecter qu’un problème WebRTC survient quand le client Jim Smith rejoint un appel sans micro avec le split tunneling de Firefox et Cloudflare Warp activé.
L’auteur a écrit qu’ils disposaient déjà d’une télémétrie suffisamment bonne, et que ce qu’ils pouvaient répondre au client par e-mail se limitait à des messages génériques du type « nous sommes au courant du problème et merci de l’avoir signalé », ce qui n’était utile ni au client ni à eux-mêmes.
À l’université, j’ai travaillé dans une boulangerie, et en discutant avec les clients qui venaient au magasin, je me suis fait quelques vrais amis durables.
Plus tard, grâce à cette expérience, j’ai obtenu un poste de support par e-mail, où je répondais aux questions des utilisateurs sur des plugins logiciels. Même quand un client envoyait un e-mail une fois par mois, je ne m’y suis jamais fait d’amis durables.
La différence, c’est que le support par e-mail ou en ligne n’a pas ces temps morts humains. À la boulangerie, pendant qu’on attendait que la commande soit réchauffée ou cuite, la conversation naissait naturellement. Du moins c’était le cas il y a dix ans, quand les téléphones n’étaient pas encore aussi omniprésents qu’aujourd’hui.
Je me demande si, dans le contexte du logiciel, quelque chose comme des « open office hours » mensuelles sur Zoom pourrait recréer un peu cette sensation. Probablement pas, mais ce serait peut-être mieux que de répondre à des e-mails.
Je comprends bien le passage disant que « dans 99 % des cas, même si l’explication est aussi prudente et aimable que possible, la réponse est plus négative que le premier e-mail ».
Quand j’étais product leader, j’aimais prendre en charge moi-même une partie du support client, et c’est une expérience fréquente. Un client qui écrit un e-mail en colère ne s’intéresse pas à vos raisons. Il veut quelque chose — un tarif moins cher, une fonctionnalité précise, une remise, un avantage gratuit — et le reste lui est égal.
C’est la version numérique du client du type « je veux parler au responsable », qui pense que s’il a ne serait-ce que 10 % de chances d’obtenir ce qu’il veut en insistant grossièrement, ça vaut le coup de mettre la pression jusqu’au bout.
Parfois, on tirait une petite satisfaction de quelqu’un qui réalisait qu’il y avait une personne concernée de l’autre côté de l’adresse e-mail, et dans ces moments-là, ça semblait en valoir la peine.
Mais la plupart du temps, ça ressemble plutôt à un jeu transactionnel, mené par des gens qui pensent qu’en se plaignant assez fort, ils peuvent exercer un pouvoir sur l’entreprise.
Il y a aussi de grandes différences culturelles. Les contacts clients venant d’un pays où nous fournissions notre service étaient d’une agressivité incontrôlable. Il y avait parfois de légères menaces de violence, et 90 % d’entre elles venaient d’un seul pays ; je ne le nommerai pas, mais je l’ai ajouté à ma liste mentale des « endroits où ne pas aller ». C’était tellement constant que c’en était bizarre.
Tout n’était pas négatif, c’était simplement différent. Dans certains pays, les gens commencent par de longs compliments avant de demander indirectement une remise. Dans d’autres, ils contactent le support pour un problème légitime ou un bug, puis une fois celui-ci résolu, ils s’attendent à une compensation pour le désagrément. Même quand ils en étaient eux-mêmes la cause.
Ailleurs encore, même quand la conversation pourrait être terminée, ils rouvrent systématiquement le ticket pour remercier longuement et exprimer leur gratitude.
Cela m’a poussé à repenser ma propre attitude quand j’interagis comme client, et aussi la façon dont les gens d’autres pays peuvent percevoir le mien.
Les récits d’échec sont très précieux, et je les trouve plus utiles que les success stories. Les récits de réussite sont souvent des rationalisations a posteriori.
C’est dommage de voir les génies de fauteuil de ce fil se comporter comme s’ils étaient bien plus intelligents et ne pouvaient jamais échouer, ou du moins comme s’ils n’admettraient jamais l’échec.
L’article contient beaucoup d’observations utiles, mais le cadrage me semble un peu à côté. Il sonne transactionnel et centré sur les chiffres.
Le fait que les utilisateurs les plus bruyants ne soient pas forcément représentatifs est assez bien connu. La plupart des utilisateurs satisfaits ne contactent pas le support, mais ce sont aussi les utilisateurs les plus importants à interroger pour améliorer le produit.
Pour interpréter les demandes des utilisateurs, il faut construire son propre modèle de qui sont ses utilisateurs. Autrement dit, déterminer si telle demande de support est un signal ou du bruit.
Si la demande vient de quelqu’un qui appartient au marché cible et exprime une douleur, cela peut être un signal important. Une demande consistant à ne payer que 20 % du prix actuel n’est utile que si vous êtes prêt à envisager une restructuration de votre offre. S’il y a beaucoup d’e-mails de ce type, cela peut indiquer une opportunité pour un produit moins cher ne contenant que certaines fonctionnalités. Sinon, il suffit de répondre « merci pour votre e-mail, nous n’avons actuellement pas prévu de modifier nos tarifs » et de passer à autre chose.
Cela dit, je trouve impressionnant qu’une telle conversation soit possible pour un développeur qui vend via l’App Store. J’ai toujours eu le sentiment qu’Apple, en s’interposant, avait détruit la capacité à entretenir une relation client. Je n’ai jamais publié moi-même sur le Mac App Store.
Parler à des utilisateurs satisfaits pour améliorer le produit, oui, mais cela ne s’appelle pas du support client : cela s’appelle de l’étude de marché.
L’auteur a embauché quelqu’un avec des connaissances techniques, mais cela ne suffit pas.
Les connaissances techniques et les compétences relationnelles sont deux choses différentes.
Si quelqu’un a pris la peine de vous contacter, il y a de bonnes chances que sa première impression de vous soit déjà mauvaise. Si la réponse se concentre sur « l’éducation du client » ou se préoccupe trop de l’équité du modèle économique lui-même, il sera difficile de produire une bonne impression.
Un excellent support client devrait être du genre à donner envie au client de partager l’interaction avec des amis ou sur les réseaux sociaux. Le support décrit dans cet article semble difficilement pouvoir produire cet effet.
Quand quelqu’un se plaint du modèle d’abonnement auprès d’Uncommon Apps, si vous ne pouvez pas le faire changer d’avis — ce qui sera généralement le cas — vous pouvez lui envoyer une liste d’alternatives.
Ainsi, le ticket de support Castro peut se terminer sur quelque chose d’utile. Uncommon Apps perdra de toute façon cette vente, mais gagnera au moins en réputation.
Le fait que le CEO ou le fondateur assure le support de premier niveau n’est peut-être pas aussi valorisant que ça en a l’air.
Du point de vue utilisateur, si le CEO ou le fondateur répond à ma question, je me demande franchement si ce n’est pas une opération provisoire en solo qui aura disparu la semaine prochaine.
De plus, une expérience de support satisfaisante n’est pas forcément la plus rapide. Si je demande quelque chose, que le support de premier niveau me dit « non » et remonte au service commercial, que le service commercial dit aussi « non » puis remonte au fondateur, et que le fondateur dit « oui », l’utilisateur peut se sentir davantage « entendu » et éprouver un plus grand sentiment d’accomplissement.
Le résultat est le même, mais dans un cas, il a l’impression de l’avoir obtenu par lui-même.