Document interne

Roleplay Sales

03_GTM_Sales/Roleplay.md

Source Markdown Bibliotheque

Roleplay Sales

Version courte jouable en entretien : Roleplay script 10min Reference methodologique : SPIN, MEDDPICC, Challenger

Objectif

Montrer une capacite de discovery, de qualification technique et de positionnement, pas seulement pitcher pyannote.

Structure

  • Clarifier le contexte client.
  • Comprendre le pipeline audio existant.
  • Identifier le cout business d'une mauvaise speaker attribution.
  • Qualifier contraintes : volume, realtime, on-prem, STT existant, equipe technique.
  • Reformuler le probleme.
  • Positionner pyannote comme couche speaker.
  • Proposer un POC avec criteres de succes.

Pitch court

"Pyannote est la couche speaker intelligence qui s'integre a votre pipeline voice existant. Vous gardez votre STT si vous en avez un ; nous ameliorons la diarization, l'overlap, l'attribution speaker, le speaker ID et l'integration enterprise."

A eviter

  • Pitcher trop vite.
  • Dire que pyannote remplace Gladia.
  • Confondre STT et diarization.
  • Survendre le STT orchestration comme un STT custom complet.
  • Ignorer les contraintes de securite, data et integration.

Posture

Le bon roleplay n'est pas une demo produit. C'est une qualification :

  • comprendre la pipeline actuelle ;
  • identifier le cout de l'erreur speaker ;
  • tester si pyannote est vraiment necessaire ;
  • proposer un POC mesurable.

Phrase d'ouverture : "Avant de vous parler de pyannote, j'aimerais comprendre votre pipeline audio actuel et surtout la ou la speaker attribution cree de la friction aujourd'hui."

Question pivot : "Si une phrase est attribuee au mauvais locuteur, qu'est-ce que ca casse chez vous : l'experience utilisateur, la conformite, le reporting, le produit final ou le cout de correction humaine ?"

Trame de discovery

  • Contexte produit : que construisez-vous avec l'audio ?
  • Pipeline : STT, diarization, post-processing, LLM, stockage, monitoring.
  • Volumes : heures/mois, batch vs realtime, pics, langues.
  • Qualite : erreurs frequentes, datasets de test, metriques suivies.
  • Speaker : nombre moyen de speakers, overlap, audio de salle, speaker count inconnu.
  • Contraintes : cloud, on-prem, data residency, SLA, securite.
  • Organisation : qui valide techniquement, qui paie, qui subit le probleme.
  • POC : dataset, baseline actuelle, seuil de succes, timing.

Reformulation type

"Si je reformule, votre STT donne deja un transcript acceptable, mais la limite est l'attribution des propos aux bons speakers, notamment sur [overlap / audio bruite / plusieurs participants / contraintes on-prem]. Donc le sujet n'est pas de remplacer votre STT, c'est de rendre votre pipeline speaker-aware avec une qualite mesurable."

Proposition de POC type

  • 10 a 30 fichiers representatifs.
  • Baseline actuelle : OSS, STT provider existant ou pipeline maison.
  • Evaluation : DER, erreurs d'attribution, zones d'overlap, temps de correction humaine, latence si realtime.
  • Comparaison : pipeline actuel vs pyannote Precision-2 / orchestration selon besoin.
  • Sortie : rapport court + recommandation integration/pricing.
  • Decision : go/no-go sur deploiement pilote ou contrat enterprise.

Scenario 1 - Meeting bot / note-taker

Contexte client :

  • Produit type meeting assistant.
  • Utilise deja un STT provider ou Whisper.
  • Les utilisateurs se plaignent que les propos sont attribues aux mauvais speakers.

Questions :

  • Combien de participants en moyenne par meeting ?
  • Un seul flux audio ou pistes separees ?
  • Quelle part des meetings a de l'overlap ou des interruptions ?
  • Votre probleme est-il la qualite du texte ou l'attribution speaker ?
  • Est-ce que les utilisateurs corrigent manuellement les speakers ?
  • Quel impact sur retention, support tickets ou confiance utilisateur ?

Angle pyannote :

  • meilleure attribution speaker ;
  • meilleur traitement overlap ;
  • reconciliation mots/speakers ;
  • Garder le STT ou le transcript existant si leur transcription fonctionne deja, puis qualifier le mode d'integration.

POC :

  • 20 meetings anonymises ;
  • comparer nombre de corrections speaker avant/apres ;
  • mesurer DER + temps de correction ;
  • montrer quelques extraits visuels speaker-attributed.

Objection probable : "Notre STT fait deja speaker diarization."

Reponse : "C'est possible, et s'il est suffisant il ne faut pas le remplacer. La question est de tester sur vos audios difficiles : interruptions, 4+ speakers, speaker count inconnu, audio de salle. C'est la que pyannote doit prouver une difference."

Scenario 2 - Medical / clinical audio

Contexte client :

  • Le prospect peut etre un STT provider, un assistant medical, une plateforme de teleconsultation, un hopital qui build sa stack ou un integrateur.
  • Donnees sensibles.
  • Plusieurs locuteurs : medecin, patient, proche, infirmier.

Questions :

  • Qui possede la pipeline audio et la decision produit aujourd'hui : vous, un fournisseur STT, le client final ou un integrateur ?
  • Est-ce que l'audio peut sortir de votre infrastructure ?
  • Quel STT utilisez-vous pour vocabulaire medical ?
  • Qui valide la note finale ?
  • Quelles erreurs speaker sont les plus critiques ?
  • Avez-vous besoin de distinguer medecin vs patient ou d'identifier des personnes recurrentes ?
  • Quelles contraintes HDS/HIPAA/RGPD structurent l'achat ?

Angle pyannote :

  • on-prem ;
  • speaker attribution fiable ;
  • integration avec STT medical existant ;
  • human-in-the-loop ;
  • auditabilite.

POC :

  • corpus de consultations avec consentement/anonymisation ;
  • baseline sur pipeline actuel ;
  • mesure erreurs medecin/patient ;
  • test deploiement dans environnement controle.
  • route de decision claire : produit vertical, STT provider, hopital ou integrateur.

Objection probable : "Le vrai probleme est le vocabulaire medical."

Reponse : "Oui, ce point releve plutot du STT medical ou du custom vocabulary. Pyannote ne remplace pas cette brique. La valeur ici est de savoir qui dit quoi et d'aligner proprement le transcript medical avec les bons locuteurs."

Scenario 3 - STT provider / voice AI platform

Contexte client :

  • Plateforme STT ou voice AI qui vend deja transcription + enrichissements.
  • Diarization incluse mais pas differenciante.
  • Risque politique : ne pas les concurrencer.

Questions :

  • Votre diarization est-elle une feature de base ou un differenciateur produit ?
  • Avez-vous une equipe dediee speaker/diarization ?
  • Quels segments clients vous demandent meilleure attribution ?
  • Quelle part de vos clients utilise diarization ?
  • Avez-vous besoin d'un mode white-label/OEM ?
  • Batch, realtime ou les deux ?

Angle pyannote :

  • brique OEM ;
  • ameliorer leur couche speaker sans changer leur relation client ;
  • integration agnostique ;
  • ne pas remplacer leur STT, resume, traduction, redaction ou UX.

POC :

  • benchmark sur leurs datasets clients difficiles ;
  • integration sandbox ;
  • mesure qualite et cout infra ;
  • discussion packaging OEM.

Objection probable : "On pourrait construire ca nous-memes."

Reponse : "Oui, surtout si vous avez l'equipe ML et le volume. La question est le cout d'opportunite : combien de temps pour atteindre un niveau equivalent sur overlap, audio difficile, realtime, support enterprise, et combien de roadmap STT vous sacrifiez pour ca ?"

Scenario 4 - Call center / conversation intelligence

Contexte client :

  • Analyse de conversations agent/client.
  • Volumes eleves.
  • Besoin coaching, compliance, QA.

Questions :

  • Agent et client sont-ils sur canaux separes ou melanges ?
  • Quel est le volume mensuel d'appels ?
  • Quels KPIs dependent du bon speaker : temps de parole, interruption, script adherence, compliance ?
  • Avez-vous des transferts, conferenciers, superviseurs, bruits de fond ?
  • Quel est le cout d'une mauvaise attribution dans vos rapports ?

Angle pyannote :

  • agent vs client plus fiable ;
  • overlap/interruption ;
  • analytics speaker-aware ;
  • integration dans pipeline existant ;
  • deploiement enterprise si donnees sensibles.

POC :

  • 100 appels representatifs ;
  • comparer attribution agent/client ;
  • mesurer erreurs sur interruptions ;
  • quantifier impact sur dashboards QA.

Objection probable : "Nos appels ont deux canaux, donc pas besoin de diarization."

Reponse : "Si les canaux sont toujours propres et separes, le besoin est plus faible. Pyannote devient pertinent quand les canaux se melangent, qu'il y a transferts, conference, superviseur, ou que vous voulez une couche speaker robuste sur tous les cas limites."

Scoring pendant le roleplay

Un prospect est prioritaire si :

  • il a un volume audio significatif ;
  • la mauvaise attribution speaker a un impact produit ou business clair ;
  • il a deja un STT ou une pipeline voice ;
  • il peut fournir un dataset de test ;
  • il a un owner technique et un owner budget ;
  • il a une contrainte qualite, securite ou on-prem.

Un prospect est moins prioritaire si :

  • mono-speaker ;
  • transcription simple ;
  • pas de volume ;
  • pas de douleur speaker ;
  • "curiosite IA" sans projet ;
  • aucun dataset de test.