Arrêtez d’essayer de planifier un appel avec moi
(matduggan.com)- Dès qu’on essaie rapidement un nouveau produit SaaS, les e-mails commerciaux, listes de diffusion et demandes d’appels répétées s’enchaînent, grignotant sans cesse le temps de l’utilisateur
- Le parcours d’achat est entraîné non pas par la ou les deux fonctionnalités réellement nécessaires, mais par une démo imposée et un discours façon « everything platform », tandis que le commercial et le sales engineer multiplient les appels
- À l’étape de validation du paiement, la pression augmente pour faire venir des décideurs de plus haut niveau dans les appels ; en interne, l’approbation prend généralement au moins un mois, et dans une entreprise du Fortune 500, au moins trois mois même si tout se passe bien
- Après l’achat, le commercial disparaît et ce sont le support client basé sur un LLM, de longs SLA, des limites non documentées et des modes de défaillance qui restent aux utilisateurs réels
- Le responsable de compte se concentre davantage sur la vente de fonctionnalités supplémentaires que sur la résolution des problèmes ; au final, lorsqu’une alternative open source plus rapide et gratuite apparaît, tout se termine par un non-renouvellement du contrat et une rupture par e-mail
Les relances qui suivent l’essai
- L’un des plus grands obstacles lorsqu’on essaie un nouveau service ou produit, ce sont les relances incessantes qui suivent
- Au début, cela commence par un e-mail inoffensif du type « dites-nous si vous avez des questions », puis très vite une personne au titre comme « customer success fun-gineer » vous contacte pour faire le point sur votre expérience d’essai
- L’utilisateur s’inscrit généralement pour vérifier une fonctionnalité précise
- Si cette fonctionnalité n’existe pas, il passe à autre chose et oublie le produit
- S’il n’est pas encore en phase d’évaluation, il est difficile de comprendre pourquoi on le contacte
- Si l’on reste sur la liste de diffusion, on continue de recevoir les nouvelles versions et annonces de lancement
- Même sans intérêt particulier, on hésite à chaque fois à se désabonner, au cas où la fonctionnalité souhaitée aurait été ajoutée
- S’il n’existe pas de notes de version accessibles, les e-mails marketing finissent par sembler être le seul moyen de vérifier si la fonctionnalité a été ajoutée
Le parcours d’achat qui se transforme en « faisons un appel »
- Le pire cas, c’est quand on peut effectivement utiliser le service : à partir de ce moment-là, on se retrouve lié à toute une série d’appels à planifier
- Au lieu de simplement saisir son numéro de carte bancaire sur le site web, il faut nouer une relation avec des inconnus sur Microsoft Teams
- Une équipe commerciale SaaS typique fait intervenir deux rôles
- Le commercial saisit des données dans le CRM et pousse en continu jusqu’à conclure la vente
- La personne au titre de « sales engineer » ou « customer success engineer » fait partie des rares personnes à avoir vraiment lu la documentation, et présente le produit comme une nouvelle « everything platform »
- La démo inclut même des fonctionnalités que l’utilisateur ne veut pas
- L’utilisateur est venu vérifier une ou deux fonctionnalités, mais le modèle de démo prédéfini n’est pas flexible
- Le commercial tente de détendre l’atmosphère avec de légers compliments laissant entendre que l’utilisateur est technique
- La démo du sales engineer plante au mauvais moment, suivie d’une explication du type « normalement, ça marche »
Sécurité, conformité et validations qui s’éternisent
- À un moment donné, lorsqu’on pose des questions sur la conformité et la sécurité, on reçoit un lot de certificats sans grande signification
- Les documents de certification sont traités moins comme une preuve que les éléments ont réellement été réalisés que comme la démonstration qu’ils peuvent avoir l’air d’avoir été réalisés correctement
- Une fois les démos et la construction de la relation terminées, l’équipe commerciale essaie d’impliquer les décideurs supérieurs de l’utilisateur dans un appel
- Comme les décideurs n’ont pas envie d’écouter chaque semaine les pitches commerciaux de plusieurs entreprises, la tâche de synthétiser la proposition retombe sur l’utilisateur
- Si l’utilisateur tient vraiment au produit, il doit contacter lui-même les personnes nécessaires à l’approbation interne
- Ce processus prend au moins un mois
- Dans une entreprise du Fortune 500, même si tout se déroule parfaitement, il faut au moins trois mois
- L’adoption d’un produit censé faire gagner du temps devient un gros projet, au point que l’utilisateur se demande s’il n’aurait pas mieux fait de rétroconcevoir l’outil lui-même
Les limites et le support client qui restent après l’achat
- Une fois l’approbation obtenue et l’argent échangé, le commercial disparaît et l’utilisateur est transféré au Customer Service, c’est-à-dire à un LLM
- La « limitless, cloud-based platform » révèle plusieurs limites en usage réel
- Un jour, tout fonctionne normalement
- Le lendemain, un seuil invisible est franchi et tout le flux s’effondre
- La documentation est organisée pour mettre en avant les avantages, ce qui rend les avertissements et les limites difficiles à trouver
- Le support client par LLM répète les mêmes liens vers la documentation, et ce n’est qu’ensuite qu’il devient possible d’envoyer un e-mail à une vraie personne
- Le SLA de l’e-mail de support est long, par exemple 72 business hours, ce qui est justifié par le fait que l’on n’a pas choisi le Super Enterprise Plan™
- La réponse se conclut en substance par : une limite invisible a été atteinte, il faut donc restructurer le workflow
- Plus on utilise le produit, plus la liste des modes de défaillance non documentés s’allonge
- Exemple : « si l’on appuie trop vite sur deux boutons, l’iFrame renvoie une erreur »
- La stack semble bien journaliser l’erreur, mais personne ne vous contacte pour en expliquer la cause ni vous aider à la corriger
Responsable de compte, vente additionnelle, open source et rupture
- Un jour, un nouveau responsable de compte (account rep) vous contacte pour proposer un appel afin de discuter de votre usage du produit et de l’aide possible
- Cet appel ressemble davantage à un nouveau pitch commercial qu’à une collecte de feedback ou à une résolution de problèmes
- Le responsable écoute la liste des problèmes et dit qu’il « va regarder », mais le véritable objectif se révèle être de convaincre l’utilisateur d’acheter des fonctionnalités supplémentaires
- Ces fonctionnalités supplémentaires, comme le SSO ou l’accès à l’API, ne coûtent presque rien au vendeur, mais font une grande différence pour l’utilisateur
- L’utilisateur doit décider s’il achète davantage de produit pour obtenir des fonctions de base, ou s’il le supprime complètement pour suivre une autre voie
- Finalement, un développeur open source crée un outil gratuit qui fait la même chose
- Son nom peut être aussi ridicule que CodeSquish, Dojo ou GitCharm
- On l’apprend par un collègue et, en regardant, on constate qu’il fait tout ce dont on a besoin, ne coûte rien et est 100 fois plus rapide
- Même s’il est maintenu par une seule personne et que son forum se résume à un serveur Discord, il est bien meilleur que le produit commercial
- La rupture est retardée à cause du contrat, mais on finit par dire à Finance de ne pas renouveler
- Lorsque le non-renouvellement devient visible, l’équipe du fournisseur se met soudain à vous porter beaucoup d’attention et essaie de vous convaincre que l’outil open source est en réalité inférieur
- L’utilisateur dit qu’il va « en discuter en interne », mais ne discute de rien ; à la fin, il annonce la rupture par e-mail et bloque le domaine
1 commentaires
Commentaires de Hacker News
Les investisseurs aussi considèrent souvent ce genre de processus comme un signe de maturité et une pratique de très haut niveau
L’approche inverse consiste à rendre l’information aussi transparente que possible et à ne pas la bloquer, à annoncer honnêtement ses faiblesses d’emblée, à connecter le client directement à la personne capable de traiter le problème dès qu’il veut parler à un humain, à ne pas faire appeler un agent IA sauf si le client le demande, en indiquant immédiatement qu’il s’agit d’une IA, à ne proposer que des options d’abonnement e-mail souples comme mensuel/trimestriel/annuel/notes de version, et à suggérer des alternatives utiles, comme un autre produit plus adapté si le produit ne convient pas
C’est souvent à cause de la tarification fondée sur la valeur que beaucoup d’entreprises tombent dans cette situation. Au lieu d’afficher un prix standard, elles étudient en détail le client, estiment la valeur qu’il tirera du produit et fixent le prix en conséquence ; en théorie, cela maximise le chiffre d’affaires, mais c’est lent et intrusif
Un utilisateur du forfait gratuit peut aussi accaparer tout le temps du support technique en ne sachant même pas faire de programmation très basique
Divulguer l’usage de l’IA, proposer plusieurs options de newsletter, et dire franchement quand ce n’est pas adapté, c’est raisonnable et, dans la pratique, ça a bien marché. En revanche, les trois premiers points peuvent détruire le produit. Cela dit, je suis peut-être cynique ou je m’y suis mal pris jusqu’ici
Si l’objectif implicite est de construire une licorne avec l’argent des investisseurs, alors oui ; mais pour la croissance lente et régulière d’une entreprise solo avec d’autres sources de revenus, cette approche peut convenir
La concurrence non régulée est une course vers le bas, donc ce sont les tactiques les plus contraires à l’éthique, les plus intrusives, à la limite de l’illégalité et les plus manipulatrices qui gagnent
Ce n’est pas le meilleur produit qui gagne, mais le meilleur marketing ; ce n’est pas l’orientation client qui l’emporte, mais le taux de conversion obtenu par la coercition ; et le prix n’est pas fondé sur la valeur du produit et du service, mais sur le montant maximal que les gens peuvent payer
Ils exigent une démo alors qu’il existe déjà un forfait gratuit ou une version d’essai avec une documentation correcte. Ils préfèrent me faire perdre mon temps plutôt que de faire examiner ça par quelqu’un chez eux
En réalité, ils n’ont souvent aucune intention de changer ; ils s’en servent juste comme point de comparaison prix/fonctionnalités pour renégocier moins cher le renouvellement avec leur concurrent enterprise
Il faut remplir des questionnaires de sécurité sans fin alors qu’on ne sait même pas encore si on va conclure une vente. Comme si j’adorais répondre à plus de 100 questions un vendredi soir à 23 h
Le processus d’achat prend 3 à 6 mois, et il y a souvent un ou deux revendeurs logiciels tiers qui s’intercalent et ne pensent qu’à leur marge. Il faut expliquer à CDW qu’on ne va pas baisser le prix de 15 % pour les laisser gagner de l’argent
Même une fois le contrat terminé, l’argent n’arrive que 60 à 90 jours plus tard, alors que le service doit déjà être fourni, et la trésorerie en souffre. Le banquier appelle même pour demander pourquoi les marges et la limite de carte bancaire sont à bloc
Donc oui, je vais forcément facturer cher les grandes entreprises
Le fait d’être clair à l’avance sur ce qu’on fait et ce qu’on ne fait pas aide vraiment. On nous demande encore des formulaires d’approvisionnement et ce genre de choses, mais au moins on peut refuser et cadrer les attentes
https://help.timetastic.co.uk/hc/en-us/articles/115003288769...
Dès qu’il faut un peu de sur-mesure, ou qu’une startup en phase de démarrage affine et prouve son adéquation produit-marché en collaborant avec des clients pilotes, ça devient bien plus difficile. Si le client est une vraie entreprise et pas une autre startup du portefeuille des investisseurs, si cela affecte plus qu’une toute petite équipe interne, et même si vous avez déjà l’oreille du CEO, il faut se préparer à des mois de réunions sans fin avec les parties prenantes de plusieurs départements
Vu depuis une startup agile en phase initiale, on ressent alors qu’elle est censée avoir, en théorie, un avantage d’innovation gigantesque face à une grande entreprise lourde et lente. Parce que celles-ci donnent l’impression de ne rien pouvoir faire
Mais si vous avez commis l’erreur d’avoir besoin de l’accord de cette grande entreprise lourde et lente qui ne peut rien faire, alors la plupart de ses frictions de déplacement deviennent désormais les vôtres
J’ai vu une variante encore pire de la même histoire. Un ingénieur faisait déjà tourner avec succès, au sein de son équipe, une bonne solution open source, puis il a essayé de tirer la sonnette d’alarme en apprenant qu’un autre ingénieur était visé par une offensive de vente enterprise pour un produit lamentable, mais il était déjà trop tard
En haut de l’organigramme, quelqu’un avait déjà engagé son capital politique en signant, et dans certains cas, dépenser l’argent de l’entreprise pour ce produit précis était même devenu un indicateur de performance personnel. Donc toutes les alternatives ont été bloquées, tout le monde a attendu des mois la finalisation de la vente, puis encore un mois que l’IT configure le SSO et la base de données, avant d’être forcé de migrer d’une solution qui marchait bien vers un déchet
Au final, le contrat n’a pas été renouvelé et ceux qui l’avaient imposé ont sauvé la face, mais la moitié des gens qui ont dû subir ça sont partis dans une meilleure entreprise, un quart a reçu un PIP ou a vu sa carrière stagner parce que ce produit pourri les empêchait de travailler correctement, et le quart restant sera probablement licencié l’année suivante
Il faut simplement dire NON à la vente enterprise. La seule chose pire que devoir faire de la vente enterprise pour vendre son propre produit, c’est d’être forcé, en tant que salarié, d’utiliser une mauvaise décision d’achat créée par la vente enterprise d’un autre
Pourtant, si on cherche une solution open source, elle est généralement meilleure et peut faire tout ce qu’on veut. Avec juste
docker compose up, on peut déjà la tester facilementMais au moment du déploiement, la conformité bloque fermement en ne vérifiant que la certification SOC2 et en exigeant un audit approfondi du code au motif que, en théorie, n’importe qui dans le monde peut modifier le code
Le manager demande comment quelque chose de gratuit et open source peut être aussi bon, et une équipe déjà en surcharge n'aime généralement pas devoir prendre en charge un logiciel imprévisible de plus
Au final, il faut donc choisir entre brûler du temps, de l'argent et de l'énergie dans un SaaS médiocre, des cycles commerciaux interminables et inutiles, et une dépendance fournisseur horrible et coûteuse, ou bien brûler un peu de temps, d'argent et d'énergie pour utiliser et faire tourner l'open source en interne
En général, on choisit l’open source. Surtout si le SaaS ne propose pas un self-onboarding rapide et simple, une période d’évaluation utile, et une tarification prévisible et transparente
Et si l’outil est largement adopté, on soutient son auteur, ou, pour un logiciel open source plus complexe, on prévoit un budget pour un plan de support. En pratique, on n’en aura probablement presque jamais besoin, mais on le fait quand même
« [...] J’ai cherché CodeSquish chez Google et il faisait exactement tout ce qu’il me fallait, pour 0 €, avec des performances 100 fois supérieures. Et pourtant, il est maintenu par un reclus qui sort de temps en temps de sa ferme du Vermont pour pousser du code sur son dépôt git auto-hébergé. »
Le pauvre mainteneur reclus découvre alors, un mardi après-midi, que votre entreprise gagne 100 millions de dollars par an grâce à “CodeSquish” sans jamais rien lui apporter. Depuis sa ferme du Vermont, en nourrissant ses poules, il se met silencieusement à remettre en question ses choix de vie — ou plutôt ses choix de licence
La plupart des logiciels open source ou SaaS sont certes utiles dans une entreprise du Fortune 500, mais relèvent davantage du confort, donc il est difficile de leur attribuer une valeur précise. Le texte montre aussi que les éditeurs SaaS enjolivent leur valeur supposée pour les grandes entreprises, appellent les gens pour leur débiter des absurdités, et pratiquent une tarification fondée sur la valeur
Ce n’est pas si fréquent qu’une entreprise qui exploite un système open source le revende ensuite. En général, elle veut posséder toute la propriété intellectuelle et refait donc sa propre version bancale, comme dans l’article
Ce qu’Amazon a fait à Elastic n’a été possible que parce qu’Elastic avait construit une marque. On ne peut pas faire ça avec un projet quelconque. On peut utiliser un projet pour faire tourner son infrastructure, mais il est très difficile d’attribuer une valeur à une bibliothèque ou à un projet en particulier
Si Amazon gagne de l’argent, c’est parce qu’Amazon est Amazon, pas parce qu’il utilise le noyau Linux. Bref, c’est un sujet difficile à démêler mentalement
Premièrement, une grande partie de tout cela peut être nécessaire si l’on veut faire de la vente B2B et faire tourner la moitié de l’industrie du logiciel. L’entreprise vendeuse doit parfois relancer plusieurs fois, mobiliser des ingénieurs commerciaux et aider à aligner tous les décideurs. Sinon, rien n’avance. Les acheteurs sont trop occupés et vendre à de grandes entreprises est trop complexe, donc une partie de ce cirque est un mal nécessaire pour faire avancer les transactions B2B
Deuxièmement, j’aimerais imaginer que les entreprises sachètent réellement mieux. Les grands groupes dépensent des millions dans des logiciels enterprise obèses alors qu’une startup pourrait produire quelque chose de dix fois meilleur pour un dixième du coût. Si on pouvait leur vendre plus facilement, tout le monde pourrait utiliser de meilleurs produits sans cette folie
Je suis d’accord sur le fait que l’expérience décrite dans le texte est démoralisante, mais les clients aussi gagneraient à s’aider un peu eux-mêmes : ils garderaient plus d’argent et obtiendraient de meilleures technologies
Les produits enterprise appartiennent simplement à une autre catégorie, et c’est distinct du produit lui-même
« J’ai vu sur LinkedIn que vous parliez espagnol. On m’a dit que la manière dont “¡Qué chévere!” apporte énergie et lumière aux conversations est particulièrement séduisante. Avez-vous eu récemment l’occasion de vous entraîner ? »
« Nous développons des outils d’automatisation de la conformité qui adapitates aux réglementations changeantes, afin de garantir des programmes d’investissement sûrs et efficaces tout en réduisant les frais généraux. »
Personne ne verrait la mention “compétence professionnelle limitée” pour mon espagnol sur LinkedIn et ne parlerait comme dans la première phrase. Et dans la seconde, “Adapitates” n’est pas un vrai mot, c’est une hallucination. https://old.reddit.com/r/ChatGPT/comments/1d8gc6x/did_chatgp...
Le problème n’est pas la vente en soi, et la plupart des gens acceptent un certain niveau de démarchage. J’ai déjà reçu un cold email non personnalisé d’une société de réplication de données ; il était court, allait droit au but, et paraissait sincère pour un spam, au point de m’intéresser réellement au produit
Toutes les entreprises de la planète expérimentent cette technologie, et si nous ne leur envoyons pas un signal fort quand elles se plantent, nous condamnons notre futur nous-mêmes à vivre avec cette ordure
Les clients qui veulent ces fonctions ont besoin du support ou d’un rapport SOC-2 quel qu’en soit le coût, et ce sont eux qui subventionnent les clients qui n’en ont pas besoin. Si cela peut aider, on peut considérer que le forfait avancé avec SSO et SLA représente le vrai prix du produit
Au départ, il y a de toute façon très peu de vraie tarification fondée sur les coûts dans la tech
En pratique, cela signifie presque forcément que l’entreprise doit absorber le coût complet d’au moins un employé supplémentaire. On estime généralement ce coût complet à environ deux fois le salaire ; ensuite, si on le divise par le nombre de clients qui exigent ce SLA, on commence à voir combien il faut facturer
Sachant que je n’aurai une réponse qu’au bout de 3 jours, je cherche moi-même ce qui est évident, et je ne contacte le support que si je ne trouve pas de réponse autrement. Mais des SLA plus courts, et surtout le support téléphonique, poussent certains types de clients à copier-coller chaque message d’erreur qu’ils rencontrent, puis à attendre du support qu’il le résolve, même si l’erreur ne vient peut-être pas du produit. Je l’ai vécu
La subvention croisée peut apparaître à cause de la régulation, ou quand une entreprise tente de monopoliser un marché
Le prix d’un produit est fixé moins par son coût de développement que par ce qu’on peut faire payer et par le coût variable. Comme vous l’avez souligné, cela mène à la discrimination tarifaire, et même si, en apparence, un groupe semble en subventionner un autre, ce n’est pas forcément le cas en réalité
J’aimerais voir un modèle basé sur le coût marginal et sur une prise de décision idéale. Décider de créer une fonctionnalité réservée aux gros clients n’est rentable que si ces clients sont prêts à la payer. D’autres clients peuvent ensuite en bénéficier, mais ce n’est pas une « subvention ». Je ne sais simplement pas quel serait un meilleur terme
Si vous proposez une approche directe sans baratin, une démo immédiate, une période d’essai utile, un onboarding facile, etc., vous perdez les clients qui s’attendent au jeu commercial habituel
Source : c’est moi qui pratique l’approche directe
Alors pourquoi parler au téléphone avec un ingénieur commercial ? Il suffit de supprimer l’e-mail
Si, comme dans la situation décrite, le profil technique fait barrage au décideur final, c’est davantage un pari, et ça échoue souvent
Les seuls produits pour lesquels j’ai envie d’entrer ma carte bancaire et de commencer tout de suite sont des logiciels génériques comme AWS EC2 ou des services d’enregistrement de domaines
Il y a parfois un mélange des genres dans le modèle tarifaire/commercial : par exemple quand on vend un produit enterprise comme s’il s’agissait d’un logiciel générique. En général, c’est le signe d’une entreprise immature
Un logiciel vendu à deux ou trois chiffres ne devrait pas avoir d’équipe commerciale. Un logiciel vendu à cinq ou six chiffres, ou plus, nécessite absolument de l’humain dans le processus commercial et d’onboarding. Une grande part de ce que je paie, c’est justement le support
Le problème, c’est que ce qu’on cherche à savoir n’est généralement pas « est-ce que ça couvre ce cas d’usage ? », mais « à quel point est-ce que ça le couvre bien ? ». C’est difficile à évaluer sans manipuler le logiciel soi-même
Je ne reçois pas souvent de pitchs commerciaux, mais pour d’autres raisons j’ai adopté une attitude similaire. Je veux que tout soit écrit, pour éviter le coup du oui d’entrée pour mettre le pied dans la porte, suivi d’un non quand on passe aux détails