« En cours de test chez eux » : le deal qui ne meurt jamais

Trois boards, la même ligne

Troisième board, et le même compte en haut du pipeline. Le montant n'a pas bougé d'un euro. La date de closing a glissé d'un trimestre, puis d'un autre.

On ouvre le détail. Le rendez-vous a eu lieu, la démo a plu, l'accès a été ouvert. Depuis, ni signature ni refus. Le deal n'avance pas, ne meurt pas. Il vieillit.

Et la même ligne se retrouve ailleurs dans le portefeuille, avec un autre produit, une autre équipe, un autre segment.

L'explication arrive avant la question

Le fondateur a sa réponse : le segment est lent, les acheteurs prennent leur temps, l'équipe doit relancer. Parfois il propose de passer à un PoC payant, « pour que le client s'engage ».

Tout cela peut être vrai. Mais proposer un test payant à quelqu'un qui n'a pas ouvert le test gratuit, c'est lui demander de financer une décision qu'il n'a pas prise.

Quant à la relance, « Alors, vous avez pu regarder ? », elle a la forme d'une question. C'est surtout un commercial qui cherche une raison d'appeler.

Le deal sans juge

Le jour où l'accès a été ouvert, personne n'a écrit ce que le test devait prouver. Ni le problème à résoudre, ni qui testerait, ni qui trancherait, ni quand. Le client a reçu une permission. L'équipe commerciale a cru recevoir un projet.

Un deal où rien n'a été promis ne peut pas être perdu : il n'y a ni échéance à manquer, ni arbitrage à subir. Alors il reste. Le taux de perte paraît flatteur, la couverture du quota confortable, et le forecast se remplit, lentement, de deals qui n'ont jamais commencé.

SAP, Stripe : deux façons de tester

Chez SAP, un PoC n'était pas un cadeau, c'était un projet. Il mobilisait les données, les équipes et les semaines du client. On le cadrait donc avant d'ouvrir quoi que ce soit : quel problème, quel critère, qui participe, qui tranche.

Chez Stripe, l'inverse. Un développeur pouvait intégrer et tester seul ^[1], sans qu'aucun commercial organise quoi que ce soit, et la preuve venait de l'usage, puis des premières vraies transactions. Ce modèle tenait parce que quelqu'un regardait cet usage : les fondateurs avaient eux-mêmes installé Stripe chez leurs premiers utilisateurs, un par un ^[2].

J'ai aussi vu l'envers des deux : des PoC payés pour des raisons politiques, jamais déployés, et des comptes ouverts en libre-service qui n'ont jamais vu la production. Le prix du test ne décide de rien. Ce qui décide, c'est qu'un nom, chez le client, soit écrit à côté du mot « verdict ».

Ce que le reporting dit déjà

Pas besoin d'interroger le fondateur pour le voir. L'export de pipeline porte trois dates par deal : l'ouverture de l'accès, le dernier signe de vie du client, le closing annoncé. Mises côte à côte, elles se contredisent souvent.

Hypothèse de travail, à remplacer par vos chiffres : quinze deals en test au forecast du trimestre, accès ouverts depuis cinq mois en moyenne, cycle annoncé de quatre. Le test dure déjà plus longtemps que le cycle entier.

Viennent ensuite les colonnes. Le signal n'est jamais un deal isolé, qui a toujours une bonne excuse. C'est la même case vide, ligne après ligne : personne de nommé côté client, aucun critère écrit, aucune date de verdict. Les montants, eux, sont remplis au centime.

Cela ne prouve pas que ces deals soient perdus. Cela prouve qu'on ne peut pas le savoir, et que les traiter comme des deals en retard coûte des relances, du temps d'avant-vente et un forecast auquel le board finit par ne plus croire.

Quatre questions pour le prochain board

Ni audit, ni nouveau tableau de bord. Quatre questions, posées sur chaque deal en test du forecast :

Quel problème le test doit-il résoudre, dit avec les mots du client ? Sur quel critère dira-t-on oui ou non ? Qui, nommément, rendra le verdict ? À quelle date ?

Le fondateur qui a les réponses a un pipeline lent. Celui qui ne les a pas a un pipeline qui ne perd jamais. Dans les deux cas, vous avez appris quelque chose, sans que personne ait eu à se justifier.

Sur les deals en test de ce trimestre : qui, chez le client, a accepté de rendre un verdict, et à quelle date ?

Ce que je ne sais pas faire : Je ne sais pas prédire, à partir d'un test gratuit, que le client achètera, ni à partir d'un PoC payé, qu'il déploiera. Sans voir l'usage réel, les personnes mobilisées et la décision que le test doit éclairer, je ne distingue pas un deal en retard d'un deal qui n'a jamais commencé. Il n'existe pas de règle « gratuit ou payant » valable pour tous les produits : le test se conçoit autour de la preuve dont l'acheteur a besoin pour décider.

Jérôme Devosse a vendu chez SAP, Stripe et Botify, dans des entreprises de 4 à plusieurs milliers de personnes. Il intervient aujourd'hui en direction commerciale de transition, 1 à 4 jours par semaine. Missions GTM.

Sources

1. Documentation du mode test — Stripe
   Un développeur peut tester l'intégration seul, sans passer par un commercial.
2. Do Things That Don't Scale — Y Combinator, 2013
   Paul Graham raconte comment les fondateurs de Stripe installaient eux-mêmes leurs premiers utilisateurs, un par un.

Un PoC payant réglerait-il la question ?

Pas à lui seul. Un client peut payer un PoC pour des raisons politiques et ne jamais déployer, comme il peut tester gratuitement, mobiliser ses développeurs et passer en production. Le paiement rend parfois l'engagement visible. Il ne le remplace pas.

Le forecast est-il faux ?

Non : il est invérifiable sur ces lignes-là. Un deal sans juge ni date de verdict côté client n'est ni probable ni improbable, il échappe à toute mesure. Le reste du pipeline peut être parfaitement sain.

Problème commercial ou problème produit ?

Les deux. Quand l'usage parle de lui-même, le test libre fonctionne, à condition que quelqu'un regarde cet usage. Quand il faut mobiliser des équipes et des données côté client, un accès ouvert sans cadrage transforme la vente en attente.