Une agence SDR termine un appel. La transcription est disponible, mais trois questions restent ouvertes : le budget est-il confirmé ou seulement évoqué ? La prochaine étape a-t-elle un responsable ? L’appel est-il rattaché à la bonne opportunité ?
Un assistant IA peut préparer ces réponses. Il ne doit pas les transformer directement en vérité CRM pendant le premier pilote.
L’objectif des dix appels n’est pas de prouver que le système sera fiable dans toutes les situations. Ce petit échantillon sert à observer le travail réel, repérer les erreurs coûteuses et décider si le pilote mérite d’être élargi.
1. Fixer un périmètre qui protège le CRM
Le premier jalon peut rester volontairement étroit :
- dix appels maximum, choisis pour leur diversité ;
- un seul CRM et un vocabulaire commercial défini ;
- une à trois personnes côté SDR ;
- aucune modification de contact, société, opportunité ou étape commerciale ;
- aucun email, aucune relance et aucune tâche envoyés automatiquement ;
- une proposition visible que le SDR peut accepter, corriger ou rejeter.
Ce fonctionnement en parallèle permet de comparer la sortie de l’assistant au travail habituel sans toucher aux données de référence. La CNIL recommande que la supervision humaine soit effective, que l’opérateur puisse modifier une décision ou arrêter le système et que les cas nécessitant une intervention soient identifiés.[1]
2. Composer dix appels qui révèlent les limites
Dix appels faciles donneraient une fausse impression de réussite. Le jeu doit contenir des situations ordinaires et des cas qui obligent l’assistant à signaler un doute.
Incluez, selon votre activité :
- un appel complet avec une prochaine étape claire ;
- un prospect absent du CRM ;
- plusieurs opportunités possibles pour la même entreprise ;
- un budget évoqué, mais non confirmé ;
- une date différente de celle déjà présente dans le CRM ;
- un décideur non identifié ;
- une objection formulée de manière ambiguë ;
- un appel interrompu ou une transcription incomplète ;
- une promesse commerciale qui exige une validation ;
- un appel dont la bonne conclusion consiste à ne rien proposer.
Avant le test, notez le comportement attendu pour chaque cas. Une information absente doit rester absente. Une contradiction doit devenir visible. Une action hors périmètre doit être bloquée.
3. Exiger un paquet de sortie vérifiable
Après chaque appel, l’assistant prépare un paquet de travail, pas une mise à jour silencieuse :
- les participants et le dossier CRM envisagé ;
- les faits commerciaux détectés ;
- les champs CRM proposés ;
- les informations manquantes ou contradictoires ;
- la prochaine action suggérée ;
- un brief destiné au closer ;
- les passages de transcription qui justifient les propositions sensibles.
Le SDR doit pouvoir revenir à la source sans relire tout l’appel. HubSpot documente désormais un fonctionnement où l’outil analyse les transcriptions et les informations d’une transaction, puis laisse le commercial examiner et appliquer les recommandations.[2] Ce principe est utile, mais le pilote doit encore vérifier la qualité des recommandations dans le contexte précis de l’équipe.
4. Mesurer cinq dimensions séparément
Ne résumez pas le pilote à « la synthèse est bonne ». Évaluez chaque appel avec la même grille.
| Dimension | Question de contrôle | Trace à conserver |
|---|---|---|
| Exactitude | La proposition correspond-elle réellement aux propos ? | Passage source et correction éventuelle |
| Complétude | Les éléments indispensables au suivi sont-ils présents ? | Information manquante signalée |
| Traçabilité | Peut-on comprendre l’origine de chaque donnée sensible ? | Citation, horodatage ou champ source |
| Temps de revue | Valider est-il plus rapide que reconstruire le dossier ? | Temps de lecture et de correction |
| Utilité commerciale | Le résultat aide-t-il le SDR ou le closer à agir ? | Accepté, corrigé, rejeté, avec motif |
Le NIST présente son profil consacré à l’IA générative comme un cadre destiné à intégrer la fiabilité dans la conception, l’usage et l’évaluation des systèmes.[3] Pour ce pilote, cela implique de conserver la version du modèle, les instructions, les règles et les corrections humaines : sinon, deux séries d’appels ne sont pas réellement comparables.
5. Consigner les corrections, pas seulement les validations
Une proposition acceptée indique qu’un cas a été utile. Une correction explique comment l’améliorer.
Pour chaque appel, consignez :
- le résultat initial de l’assistant ;
- la décision du SDR : accepté, corrigé ou rejeté ;
- le motif de la correction ;
- la gravité de l’erreur ;
- la version du workflow testée.
Séparez une erreur de forme d’une erreur de rattachement, d’une invention ou d’une action interdite. Elles n’ont ni le même risque ni la même réponse.
6. Décider : élargir, corriger ou arrêter
À la fin des dix appels, trois décisions sont possibles.
Élargir prudemment
Les propositions sont traçables, les erreurs restent faciles à détecter et la revue fait gagner du temps. Le prochain jalon peut ajouter des appels ou une autre personne, tout en conservant la validation humaine.
Corriger puis rejouer
La valeur est visible, mais certaines règles, certains champs ou certains cas d’arrêt sont mal définis. Corrigez le workflow, puis rejouez les cas concernés avant d’élargir.
Arrêter le pilote
Le SDR passe plus de temps à vérifier qu’à travailler, les erreurs importantes sont difficiles à repérer ou l’assistant franchit les limites fixées. Un arrêt documenté est un résultat utile : il évite de connecter trop tôt le CRM.
Il n’existe pas de seuil universel applicable à toutes les équipes. Une date mal formatée et une mauvaise opportunité n’ont pas la même conséquence. Les critères de passage doivent être écrits avec les responsables métier avant de consulter les résultats.
Ce que le pilote ne doit pas automatiser
Pendant ce premier jalon, l’assistant ne doit pas :
- envoyer une relance ;
- modifier une étape du pipeline ;
- fusionner des contacts ou des sociétés ;
- qualifier définitivement une opportunité ;
- confirmer un prix, une promesse ou une échéance au prospect ;
- effacer la valeur précédente du CRM.
Pour approfondir ces limites, consultez les cinq contrôles avant toute proposition CRM et le protocole général de test d’un employé IA.
Le résultat attendu
Un bon pilote ne cherche pas à démontrer que l’IA sait tout faire. Il vérifie qu’elle peut préparer un travail utile, contrôlable et suffisamment clair pour réduire la ressaisie sans retirer la décision à l’équipe.
Pulse SDR applique ce principe à la chaîne appel → contexte → champs proposés → informations manquantes → brief closer → validation humaine. Si vos SDR reconstruisent encore ce contexte après chaque échange, évaluez un pilote sur votre parcours avec le Diagnostic Pulse.