Script de Jeu de Rôle sur la Vente d'un Produit : Un Exemple Complet avec Dialogue et Rubrique

Un script de jeu de rôle sur la vente d'un produit est un dialogue écrit entre deux rôles, généralement un vendeur et un acheteur, qui parcourt une conversation commerciale réaliste de la ligne d'ouverture à la conclusion. Contrairement à un modèle de pitch commercial générique, un script complet comprend les deux côtés de l'échange : ce que dit le vendeur, comment l'acheteur se défend et comment le vendeur répond à cette objection.

Les enseignants utilisent ces scripts dans les cours de communication commerciale ou de marketing pour enseigner la persuasion et la négociation. Les directeurs des ventes les utilisent lors de l'intégration pour que les nouveaux représentants entendent à quoi ressemble une bonne conversation de découverte à conclusion avant de l'essayer en direct. Le format fonctionne parce qu'il élimine les incertitudes : au lieu de dire à quelqu'un « gérez bien les objections », vous lui montrez exactement à quoi cela ressemble ligne par ligne.

Un bon script de jeu de rôle de vente de produit a généralement trois parties : la configuration des personnages (qui sont l'acheteur et le vendeur, et quelle est la situation de l'acheteur), le dialogue lui-même et des notes de débriefing qui expliquent pourquoi certaines lignes ont fonctionné.

Avant de distribuer le script ci-dessous, consacrez cinq minutes à la mise en place. C'est plus important que le dialogue lui-même, car un jeu de rôle n'enseigne quelque chose que si les personnes qui le jouent comprennent pourquoi chaque personnage agit de la manière qu'il le fait.

Voici un script de jeu de rôle acheteur-vendeur complet et utilisable. Le produit est une application de gestion de projets appelée TaskFlow, mais la structure fonctionne pour presque n'importe quel produit B2B ou B2C, il suffit de changer les détails.

**Configuration :** Maya (vendeur) travaille pour TaskFlow. Devon (acheteur) gère une équipe marketing de 12 personnes qui utilise actuellement des feuilles de calcul et des e-mails pour suivre les projets. Devon a déjà essayé un autre outil et pensait qu'il était trop compliqué pour que l'équipe l'adopte.

**Maya :** Bonjour Devon, merci de prendre du temps. Avant de vous montrer quoi que ce soit, pouvez-vous me montrer comment votre équipe suit les projets en ce moment ?

**Devon :** Bien sûr. Nous utilisons une feuille de calcul partagée et beaucoup de messages Slack. Ça fonctionne, surtout, mais des choses tombent à travers les mailles du filet quand nous sommes occupés.

**Maya :** À quelle fréquence diriez-vous que quelque chose tombe à travers les mailles, à peu près ?

**Devon :** Honnêtement, au moins une fois par semaine. Habituellement, une date limite que quelqu'un a oubliée parce qu'elle était enterrée dans un fil.

**Maya :** Je comprends. Donc la feuille de calcul suit le travail, mais elle ne rappelle pas réellement à quelqu'un ou n'indique quand quelque chose est à risque.

**Devon :** C'est exact.

**Maya :** C'est le problème que TaskFlow a été construit pour résoudre. Chaque tâche a un propriétaire et une date d'échéance, et l'application envoie un avertissement deux jours avant que quelque chose soit en retard, afin qu'elle remonte surface avant qu'elle ne devienne une date limite manquée au lieu d'après. Compte tenu de ce que vous venez de décrire, aurait-ce attrapé le problème de la semaine dernière ?

**Devon :** Probablement, oui. Mais je serai honnête, nous avons essayé un outil comme celui-ci l'année dernière et l'équipe l'a détesté. Trop de clics, trop de configuration.

**Maya :** C'est une préoccupation valable, et c'est la raison numéro un pour laquelle les équipes abandonnent ces outils. Puis-je vous demander ce qui a précisément rendu cela trop clic ?

**Devon :** Juste créer une tâche prenait comme cinq champs. Les gens ont arrêté de s'en soucier.

**Maya :** C'est logique. La création de tâches de TaskFlow n'a qu'un seul champ : tapez la tâche et appuyez sur Entrée, tout le reste est facultatif. Je préfère vous le montrer plutôt que de le décrire, serait-ce une visite de 15 minutes avec deux ou trois de vos membres d'équipe, afin que vous ne soyez pas le seul à juger si c'est vraiment simple ?

**Devon :** C'est raisonnable. Quel est le coût pour une équipe de notre taille ?

**Maya :** Pour 12 personnes, c'est 8 dollars par personne par mois, donc 96 dollars au total, et les deux premières semaines sont gratuites pour que votre équipe puisse le tester sur un vrai projet avant que quelqu'un ne le paie.

**Devon :** D'accord. Mettons en place cette visite. Pouvez-vous le faire jeudi ?

**Maya :** Jeudi convient. Je vais envoyer une invitation à un calendrier avec les deux personnes que vous avez mentionnées incluses.

Relisez le script ci-dessus et notez que Maya ne conteste jamais l'objection de Devon selon laquelle l'équipe a détesté le dernier outil. Contester une objection fait que l'acheteur la défend plus fortement. Au lieu de cela, le script suit un modèle en quatre parties qui vaut la peine d'être enseigné explicitement.

Premièrement, reconnaître l'objection comme raisonnable ("C'est une préoccupation valable"). Deuxièmement, poser une question de suivi spécifique au lieu de supposer ce qui s'est mal passé ("ce qui a précisément rendu cela trop clic ?"). Troisièmement, répondez à la réponse réelle avec une différence concrète, pas une assurance générique. Quatrièmement, passez à une petite étape suivante à faible risque, une courte visite, plutôt que de demander une décision d'achat sur le spot.

Ce modèle fonctionne pour les objections de prix, les objections de calendrier ("nous ne sommes pas prêts à changer de système ce trimestre") et les objections d'autorité ("je devrais faire examiner cela par mon directeur") de la même manière qu'il fonctionne pour l'objection d'adoption dans l'exemple. Reconnaître, demander, répondre avec des détails spécifiques, proposer une petite étape suivante. Lorsque vous écrivez votre propre script de jeu de rôle sur la vente d'un produit, construisez chaque objection autour de cette séquence au lieu d'écrire un discours de réfutation.

Si vous l'utilisez dans une classe ou une session de formation formelle, notez la performance du vendeur sur des comportements spécifiques plutôt qu'une note vague « communication ». Une rubrique avec des critères concrets rend également le débriefing plus rapide car tout le monde pointe les mêmes moments de la conversation.

L'exemple TaskFlow ci-dessus est écrit pour un représentant de niveau intermédiaire ou un étudiant de niveau intermédiaire, mais la même structure s'adapte facilement. Pour les débutants, supprimez l'objection de prix et conservez uniquement l'objection d'adoption, afin que les apprenants puissent se concentrer sur une compétence à la fois. Pour la pratique avancée, empilez deux objections dos à dos, par exemple le prix et une comparaison concurrente, afin que le vendeur doive prioriser celle à traiter en premier.

Pour l'adapter à un produit différent, conservez la forme en quatre parties : une question de découverte, une réponse d'acheteur qui révèle un point douloureux spécifique, un pitch qui connecte la fonctionnalité du produit à ce point douloureux exact, et une objection réaliste liée à la situation de l'acheteur plutôt qu'une "c'est trop cher" générique. Un script de jeu de rôle de vente pour un bien physique, comme du mobilier de bureau ou une boîte d'abonnement, suit la même forme, seulement les questions de découverte et les objections changent pour correspondre à ce qu'cet acheteur se soucie réellement, comme le délai de livraison ou la politique de retour au lieu de l'adoption de logiciels.

L'erreur la plus courante est de sauter la fiche de rôle de l'acheteur et de laisser la personne qui joue l'acheteur inventer des objections sur le moment. Sans une situation définie, les acheteurs ont tendance soit à céder immédiatement, soit à se bloquer sans vraie raison, et ni l'un ni l'autre n'enseigne quelque chose d'utile.

La deuxième erreur est d'exécuter le jeu de rôle une seule fois. Un seul passage vous dit si quelqu'un peut suivre un script, pas s'il peut l'adapter. Exécuter le même scénario avec une nouvelle objection, ou échanger qui joue l'acheteur, montre si la compétence sous-jacente s'est transférée.

La troisième erreur est de déboguer sur le sentiment ("cela semblait bon") au lieu de sur la rubrique. Liez chaque commentaire dans le débriefing à une ligne spécifique de la conversation, et le groupe retiendra beaucoup plus qu'un simple "bon travail" ou "travaillez sur votre fermeture."

Pas chaque classe ou équipe n'a un partenaire de pratique disponible sur demande, et un script ne renforce la confiance que si vous avez dit les lignes à haute voix, pas juste les lire. C'est là que SayNow AI est utile en tant que complément du script ci-dessus : vous pouvez parler les lignes du vendeur en réponse à un acheteur simulé, obtenir des retours sur le rythme, les mots de remplissage et la clarté, et répéter l'échange de gestion des objections autant de fois que vous le besoin jusqu'à ce que le modèle reconnaître-demander-répondre-proposer se sente automatique. Il ne remplacera pas l'exécution de l'exercice avec un vrai partenaire en classe, mais c'est un excellent moyen de répéter avant d'être noté ou avant un vrai appel commercial.