Document interne
Discovery Questions
03_GTM_Sales/Discovery_questions.md
Discovery Questions
Reference methodologique : SPIN, MEDDPICC, Challenger
Logique d'utilisation
Objectif : structurer la discovery avec SPIN, tout en capturant MEDDPICC.
- SPIN sert a faire parler le prospect : Situation, Problem, Implication, Need-payoff.
- MEDDPICC sert a qualifier le deal : Metrics, Economic buyer, Decision criteria, Decision process, Paper process, Identify pain, Champion, Competition.
- Challenger sert a apporter un insight quand il est credible : recadrer le probleme sans etre arrogant.
Regle simple :
- commencer par peu de questions Situation ;
- passer vite au Problem ;
- passer du temps sur Implication ;
- laisser le prospect verbaliser le Need-payoff ;
- noter les champs MEDDPICC pendant le call.
Question pivot pyannote : "Si une phrase est attribuee au mauvais locuteur, qu'est-ce que ca casse concretement chez vous : produit, confiance utilisateur, conformite, analytics, cout de correction ou time-to-market ?"
Questions transverses
Situation
- Quel produit ou workflow construisez-vous avec l'audio ?
- Quel est votre pipeline actuel : ingestion, STT, diarization, post-processing, LLM, stockage ?
- Quel STT utilisez-vous aujourd'hui ?
- Utilisez-vous deja pyannote open source ou une autre brique diarization ?
- Quels volumes audio traitez-vous par mois ?
- Batch, realtime ou les deux ?
- Combien de speakers en moyenne par fichier ou conversation ?
- Les pistes audio sont-elles separees ou melangees ?
Problem
- Ou votre pipeline est-il le moins fiable aujourd'hui ?
- Est-ce un probleme de transcription, de speaker attribution, d'overlap, de latence, de cout ou de deploiement ?
- Quels cas audio posent probleme : salle de reunion, bruit, interruptions, accents, 4+ speakers, call transfer ?
- Comment detectez-vous aujourd'hui une erreur de speaker attribution ?
- Qui corrige ces erreurs et a quelle frequence ?
Implication
- Que se passe-t-il quand une phrase est attribuee au mauvais speaker ?
- Quel impact sur vos utilisateurs, vos dashboards, votre compliance ou votre support ?
- Combien de temps humain est perdu en correction ?
- Est-ce que ces erreurs bloquent des deals, des features ou des deploiements enterprise ?
- Si le probleme reste identique dans 6 mois, qu'est-ce que ca vous coute ?
Need-payoff
- Si vous pouviez reduire ces erreurs speaker de facon mesurable, qu'est-ce que ca changerait ?
- Quel niveau de qualite rendrait le sujet "production-ready" ?
- Qu'est-ce qu'un bon POC devrait prouver pour vous ?
- Si le POC reussit, quelle serait la prochaine etape concrete ?
Scenario 1 - STT provider / voice AI platform
Challenger insight
"Beaucoup de plateformes STT traitent la diarization comme une feature additionnelle. Mais pour certains clients enterprise, l'erreur critique n'est plus seulement un mot mal transcrit ; c'est une phrase exacte attribuee a la mauvaise personne. C'est la que la couche speaker devient une brique produit, pas une checkbox."
SPIN
Situation :
- Votre diarization actuelle est-elle interne, open source, fournisseur externe ou combinee ?
- Quelle part de vos clients active la diarization ?
- Batch, realtime ou les deux ?
- Sur quels segments clients la diarization devient-elle critique ?
Problem :
- Quels cas font baisser la qualite : overlap, audio de salle, speaker count inconnu, plusieurs langues ?
- Est-ce que vos clients comparent votre diarization a celle d'autres STT providers ?
- Est-ce que la diarization est un sujet de churn, support ou enterprise sales ?
Implication :
- Que vous coute le fait de maintenir cette brique en interne ?
- Quelles ressources roadmap STT sont detournees vers la couche speaker ?
- Si votre diarization reste good enough mais pas best-in-class, quels deals vous echappent ?
Need-payoff :
- Si vous pouviez integrer une couche speaker plus forte sans changer votre STT ni votre relation client, qu'est-ce que ca debloquerait ?
- Qu'est-ce qui rendrait un partenariat OEM acceptable : qualite, cout, latence, white-label, SLA ?
MEDDPICC a capter
- Metrics : volume diarized/mois, taux d'activation, cout infra, support tickets, deals perdus.
- Economic buyer : CTO, VP Product, Head of AI/Speech.
- Decision criteria : qualite, latence, cout, integration, white-label, SLA.
- Decision process : evaluation ML, integration sandbox, security/legal, business approval.
- Paper process : DPA, MSA, data processing, usage terms, OEM terms.
- Pain : diarization insuffisante ou trop couteuse a maintenir.
- Champion : Head of Speech ou Product owner qui veut differencier la plateforme.
- Competition : build interne, NeMo, SpeechBrain, STT good enough, autres providers.
Scenario 2 - Meeting bot / note-taker
Challenger insight
"Dans les meeting bots, la confiance utilisateur se casse souvent moins sur une virgule que sur le mauvais speaker. Si le compte rendu attribue une decision a la mauvaise personne, l'utilisateur ne corrige pas seulement le transcript : il doute du produit."
SPIN
Situation :
- Quels types de meetings traitez-vous : sales, hiring, interne, customer success ?
- Combien de participants en moyenne ?
- Un seul flux audio ou pistes separees ?
- Quel STT utilisez-vous ?
- Avez-vous deja une correction manuelle des speakers dans l'UX ?
Problem :
- Quelles plaintes utilisateurs reviennent sur les speakers ?
- Les erreurs viennent-elles plutot de l'overlap, du speaker count, des changements rapides, de l'audio de salle ?
- Est-ce que les resumes LLM heritent des erreurs de speaker attribution ?
Implication :
- Combien de support tickets ou corrections manuelles cela genere ?
- Quel impact sur activation, retention ou confiance dans les notes ?
- Est-ce que cela bloque certains comptes enterprise ?
Need-payoff :
- Si les corrections speaker baissaient fortement, quel impact sur votre produit ?
- Quel benchmark client permettrait de prouver la valeur ?
- A partir de quel niveau de qualite passeriez-vous en production ?
MEDDPICC a capter
- Metrics : meetings/mois, participants moyens, corrections speaker, support tickets, churn ou expansion bloquees.
- Economic buyer : CTO, Head of Product, CEO si early stage.
- Decision criteria : precision speaker, overlap, UX impact, cout par heure, latency.
- Decision process : test dataset, comparaison baseline, integration, pricing approval.
- Paper process : DPA, security review, procurement enterprise si revente B2B.
- Pain : mauvaise attribution qui degrade la confiance produit.
- Champion : Product/ML lead responsable transcript quality.
- Competition : Gladia, Deepgram, AssemblyAI, Whisper + diarization OSS, status quo.
Scenario 3 - Medical / clinical audio
Challenger insight
"Dans le medical, le STT specialise traite le vocabulaire. Mais le risque operationnel est souvent different : savoir si une information vient du patient, du medecin, d'un proche ou d'un soignant. La couche speaker doit donc s'integrer au STT medical, pas le remplacer. Le premier travail commercial est d'identifier qui controle cette pipeline : STT provider, produit vertical, hopital ou integrateur."
SPIN
Situation :
- Qui controle la pipeline audio aujourd'hui : vous, un STT provider, un produit vertical, un hopital/client final ou un integrateur ?
- Quel type d'audio traitez-vous : consultation, dictation, teleconsultation, staff medical ?
- Combien de locuteurs sont presents en moyenne ?
- Votre STT est-il generaliste, medical, custom ou maison ?
- L'audio peut-il sortir de votre infrastructure ?
Problem :
- Les erreurs critiques viennent-elles du vocabulaire medical ou de l'attribution speaker ?
- Avez-vous des cas medecin/patient/proche mal distingues ?
- Quelles contraintes HDS/HIPAA/RGPD bloquent les fournisseurs cloud ?
Implication :
- Quel est l'impact d'une mauvaise attribution dans une note medicale ?
- Qui doit relire ou corriger ?
- Est-ce que cela ralentit le deploiement dans certains etablissements ?
Need-payoff :
- Si vous gardez votre STT medical mais ajoutez une meilleure couche speaker, qu'est-ce que ca debloque ?
- Quel niveau d'auditabilite ou deploiement rendrait le projet acceptable ?
- Quel POC securise pourriez-vous lancer ?
MEDDPICC a capter
- Metrics : consultations/mois, temps de correction, taux d'erreur speaker, sites pilotes.
- Economic buyer : selon route. CTO/CPO/Head of AI chez un produit vertical ; Head of Speech/Product chez un STT provider ; DSI/DPO/programme/achat chez un hopital ; partner/integrateur si projet SI.
- Decision criteria : on-prem, qualite, integration STT medical, audit, privacy.
- Decision process : clinical validation, security, legal, pilot, rollout.
- Paper process : DPA, HDS/HIPAA, hospital procurement, security questionnaire.
- Pain : attribution medecin/patient/proche, data sensitive.
- Champion : product/ML lead, clinical ops, DSI project owner ou owner integrateur selon route.
- Competition : STT medical avec diarization integree, build interne, no deployment.
Scenario 4 - Call center / conversation intelligence
Challenger insight
"Dans un call center, beaucoup d'analytics supposent que l'on sait toujours qui parle. Mais des que les canaux se melangent, qu'il y a transferts ou interruptions, les KPIs agent/client peuvent devenir faux. Le probleme n'est pas seulement transcript quality, c'est decision quality."
SPIN
Situation :
- Vos appels sont-ils mono-canal, stereo agent/client ou melanges ?
- Quels volumes mensuels ?
- Quels analytics dependent du bon speaker : temps de parole, interruptions, script, QA, compliance ?
- Utilisez-vous deja une solution CCaaS ou conversation intelligence ?
Problem :
- Ou l'attribution agent/client se degrade-t-elle ?
- Avez-vous des transferts, superviseurs, conference calls, bruit de fond ?
- Les erreurs speaker faussent-elles vos scores QA ou compliance ?
Implication :
- Quel impact sur coaching, reporting, alertes compliance ou evaluation agent ?
- Combien de controles humains sont necessaires ?
- Est-ce que cela limite la fiabilite de vos dashboards ?
Need-payoff :
- Si agent/client et interruptions etaient mieux detectes, quel KPI serait le plus impacte ?
- Quel dataset d'appels representatifs peut servir de benchmark ?
- Quelle reduction d'erreurs justifierait un pilote ?
MEDDPICC a capter
- Metrics : appels/mois, duree moyenne, QA cost, taux d'erreur, nombre d'agents.
- Economic buyer : selon route. Product/CTO chez CCaaS ou conversation intelligence ; COO/VP Customer Ops chez BPO ; Head of Contact Center/DSI chez enterprise qui build en interne.
- Decision criteria : qualite agent/client, cout, integration, compliance, realtime.
- Decision process : pilote sur appels, validation metier, IT/security, rollout.
- Paper process : DPA, data retention, vendor risk, MSA.
- Pain : analytics faux, compliance risk, cout de correction.
- Champion : Head of QA, Product AI, Contact center ops.
- Competition : CCaaS diarization, Gladia/Deepgram/AssemblyAI, channels separes, status quo.
Scenario 5 - Legal / justice / audiences
Challenger insight
"Dans le legal, le transcript brut n'est pas le livrable final. La valeur est une trace verifiable : qui a dit quoi, quand, avec quelle possibilite de correction et d'audit. C'est un workflow de preuve, pas seulement un STT."
SPIN
Situation :
- Quel contexte ciblez-vous : arbitrage, mediation, cabinet, audience officielle, audition ?
- Qui produit aujourd'hui la trace ou le compte rendu ?
- L'audio est-il autorise, stocke, partageable ?
- Quels interlocuteurs doivent valider : legal, greffe, DSI, DPO ?
Problem :
- Le probleme actuel est-il vitesse, cout, fiabilite, attribution speaker, audit trail ?
- Les participants se coupent-ils souvent la parole ?
- Quels cas rendent une transcription automatique inutilisable ?
Implication :
- Quel risque si une phrase est attribuee au mauvais intervenant ?
- Quel cout de relecture/correction ?
- Est-ce que l'absence d'auditabilite bloque l'adoption ?
Need-payoff :
- Si l'outil produisait une trace speaker-attributed, horodatee et corrigeable, qui y gagnerait le plus ?
- Quel niveau de validation humaine resterait necessaire ?
- Quel pilote non officiel ou prive serait acceptable ?
MEDDPICC a capter
- Metrics : heures d'audience/audio, cout transcription, delai de PV/compte rendu.
- Economic buyer : Ministere/DNUM pour officiel ; legal ops/partner pour prive.
- Decision criteria : auditabilite, confidentialite, correction humaine, on-prem.
- Decision process : pilote prive, juridique, DPO, IT, procurement public si officiel.
- Paper process : marche public, DPA, archivage, retention, autorisations.
- Pain : lenteur, cout, attribution, audit.
- Champion : greffe/ops/legaltech/product owner.
- Competition : transcription humaine, STT generaliste, status quo, contraintes legales.
Scenario 6 - Defense / on-prem / donnees sensibles
Challenger insight
"Dans les environnements sensibles, le choix n'est pas seulement meilleur modele vs moins bon modele. Le vrai critere est : pouvez-vous exploiter l'audio sans perdre le controle de la donnee, tout en gardant une qualite speaker suffisante pour des decisions critiques ?"
SPIN
Situation :
- Quels types d'audio traitez-vous : reunion, radio, archives, operationnel, formation ?
- L'environnement est-il cloud autorise, private cloud, on-prem ou air-gapped ?
- Avez-vous deja une pipeline STT ou audio analytics interne ?
- Quels volumes et quelles langues ?
Problem :
- Qu'est-ce qui bloque aujourd'hui : qualite speaker, securite, latence, integration, absence de support ?
- Les fournisseurs cloud sont-ils exclus ?
- Avez-vous besoin de speaker ID ou seulement diarization ?
Implication :
- Quel impact d'un mauvais speaker label sur analyse, audit ou decision ?
- Combien coute le maintien d'une stack open source non supportee ?
- Quel risque si le systeme n'est pas auditable ou deployable chez vous ?
Need-payoff :
- Si vous aviez une couche speaker deployable dans votre environnement, quel cas d'usage serait prioritaire ?
- Quel niveau de support/SLA rendrait le deploiement credible ?
- Quel perimetre de POC pourrait etre lance sans exposer de donnees sensibles ?
MEDDPICC a capter
- Metrics : heures audio, cout annotation, delai analyse, nombre d'analystes, criticite.
- Economic buyer : DSI, direction programme, innovation defense, metier operationnel.
- Decision criteria : on-prem/air-gapped, qualite, audit, support, souverainete.
- Decision process : sponsor metier, validation securite, pilote, achat public/defense.
- Paper process : habilitations, clauses securite, procurement, documentation.
- Pain : donnees sensibles, OSS non supporte, qualite insuffisante.
- Champion : responsable innovation/AI ou metier audio.
- Competition : open source interne, integrateur defense, hyperscaler souverain, status quo.
Questions de controle MEDDPICC a placer sans lourdeur
- Metrics : "Comment mesurez-vous aujourd'hui l'impact de ce probleme ?"
- Economic buyer : "Qui porte le budget si le POC est concluant ?"
- Decision criteria : "Quels criteres feront qu'une solution est retenue ou rejetee ?"
- Decision process : "Quelles sont les etapes entre un POC reussi et un deploiement ?"
- Paper process : "Quels sujets legal/security ralentissent habituellement vos achats ?"
- Identify pain : "Qui ressent le plus directement cette douleur en interne ?"
- Champion : "Qui aurait interet a porter ce sujet meme quand je ne suis pas dans la piece ?"
- Competition : "Si vous ne faites pas pyannote, quelle est l'alternative la plus probable : build, fournisseur actuel, open source ou ne rien faire ?"