Cahier des charges callbot relation client

Ce qu'un cahier des charges callbot doit trancher

La voix ne pardonne pas les zones floues.

Un chatbot texte peut parfois laisser le client relire ou reformuler. Un callbot doit comprendre vite, répondre court et transférer proprement. Le cahier des charges doit donc décrire les conditions de conversation, pas seulement les intentions.

Les décisions minimales :

• quels motifs vocaux traiter ;
• comment identifier l'appelant ;
• quelles données consulter ;
• quand transférer ;
• que transmettre au conseiller ;
• comment mesurer l'expérience vocale.

La voix impose une contrainte supplémentaire : l'appelant ne voit pas le raisonnement du système. Sur un chatbot texte, il peut relire, corriger, cliquer, revenir en arrière. Au téléphone, il attend une réponse immédiate et claire. Si le callbot hésite, parle trop longtemps ou transfère mal, la frustration arrive vite. Le cahier des charges doit donc cadrer la durée, les formulations, les sorties et les reprises avec beaucoup plus de précision qu'un projet texte.

Il doit aussi distinguer les motifs vocaux réellement adaptés. Certains appels sont répétitifs, courts et bien bornés : horaires, orientation, statut, confirmation, collecte initiale, rappel d'une étape. D'autres sont émotionnels, ambigus ou fortement réglementés. Le callbot peut les reconnaître et les transférer, mais il ne doit pas essayer de les résoudre intégralement.

Enfin, le document doit parler téléphonie dès le départ. Numéros, files, SVI existant, ACD, CCaaS, horaires, débordement, transfert, enregistrement, consentement, reporting : ces éléments influencent le coût, la qualité et le calendrier. Un cahier des charges qui décrit uniquement les intentions conversationnelles oublie la moitié du projet.

Tableau de cadrage vocal

Les critères à imposer au fournisseur

Demandez une démonstration sur vos vrais motifs, avec bruit, hésitation, accents et coupures.

Le fournisseur doit expliquer :

• comment il détecte la fin de parole ;
• comment il évite les réponses trop longues ;
• comment il gère l'incompréhension ;
• comment il transfère à une file ou un conseiller ;
• comment il journalise l'appel ;
• comment il mesure attente, résolution et transfert.

Les notes produit Webotit cadrent le callbot relation client autour de six piliers opérationnels : décroché immédiat, résolution des demandes simples, transfert contextuel avec historique d'appel, scripts normés, intégrations CRM/CCaaS et qualité vocale multi-accent. Les retours de production internes ajoutent deux exigences concrètes : reporting mensuel par service et capacité à absorber de fortes volumétries sur des périmètres SAV.

Les standards de centre de contacts utilisent déjà des métriques comme temps moyen de traitement et résolution au premier contact.³ Le callbot doit se brancher sur ces métriques, pas inventer un tableau isolé.

Signaux de maturité avant achat

Le premier signal est l'existence de données téléphoniques. L'entreprise doit connaître le volume d'appels, les horaires de pic, les files saturées, les durées moyennes, les motifs déclarés, les transferts et les rappels. Sans ces données, le cahier des charges risque de choisir les mauvais motifs.

Le deuxième signal est la capacité à écrire des sorties courtes. Un callbot n'est pas un conseiller qui peut expliquer pendant cinq minutes. Il doit conclure vite : réponse donnée, rappel proposé, dossier qualifié, transfert effectué, information indisponible, demande hors périmètre. Ces sorties doivent être formulées en langage naturel, mais elles doivent rester bornées.

Le troisième signal est la disponibilité des règles de transfert. Vers quelle file orienter ? À quel moment ? Avec quel motif ? Quel résumé ? Quelle donnée collectée ? Quelle priorité ? Si ces règles ne sont pas claires, le callbot ne réduira pas le travail du plateau.

Le quatrième signal est l'acceptation d'une phase pilote. La voix doit être testée avec de vrais accents, du bruit, des silences, des interruptions, des phrases longues et des appelants pressés. Un pilote supervisé évite de généraliser trop vite un parcours qui marche seulement en démonstration.

Exemple de scénario métier

Prenons un service qui reçoit de nombreux appels sur le statut d'un dossier. Le mauvais cahier des charges demande : "Le callbot doit répondre aux appels de suivi." Cette phrase ne précise ni l'identification, ni les données consultées, ni la sortie, ni le transfert. Elle produira des devis incomparables.

Un cahier des charges utile écrit plutôt : "Le callbot décroche, identifie le motif de suivi, demande l'information minimale autorisée, consulte la source métier si elle est disponible, annonce le statut avec une phrase courte, indique la prochaine étape, puis transfère si le statut est absent, bloqué ou sensible." Cette formulation donne un service testable.

Le scénario doit prévoir les cas limites : appelant sans identifiant, dossier introuvable, demande d'information sensible, colère, silence, bruit de fond, interruption, demande de parler à un humain. Il faut aussi décider ce qui est transmis au conseiller : motif reconnu, informations données, identifiant collecté, statut de vérification, raison du transfert.

Ce type de scénario montre pourquoi le callbot ne doit pas être seulement évalué sur son taux de décroché. Le taux de décroché est nécessaire, mais insuffisant. La valeur vient de l'appel utilement traité ou transféré.

Le déroulé de préparation

Ce qu'il faut éviter

Évitez de demander au callbot de remplacer tout le standard.

Commencez par :

• suivi simple ;
• orientation ;
• collecte avant transfert ;
• statut de dossier ;
• demande récurrente à faible risque.

Les motifs émotionnels, juridiques ou à forte incertitude doivent sortir vite. Le callbot crée de la valeur quand il baisse l'attente sans dégrader la confiance.

Erreurs à éviter dans un appel d'offres callbot

La première erreur consiste à vouloir remplacer tout le standard. Un callbot relation client doit commencer par quelques motifs fréquents, courts et bien documentés. S'il démarre sur tous les motifs, la recette devient lourde, les réponses s'allongent et la qualité baisse.

La deuxième erreur consiste à sous-estimer la téléphonie. Le canal vocal n'est pas seulement une interface. Il faut gérer le routage, les files, les transferts, la latence, les numéros, les horaires, le débordement, les enregistrements éventuels et le reporting. Ces sujets doivent être cadrés avec l'IT et le centre de contacts.

La troisième erreur consiste à écrire des réponses trop longues. Une réponse correcte à l'écrit peut être pénible à écouter. Le callbot doit parler court, confirmer les éléments essentiels et proposer une sortie claire. Les scripts doivent donc être écrits pour l'oral, pas copiés depuis une FAQ.

La quatrième erreur consiste à oublier la supervision. Les appels doivent être écoutés, classés et corrigés. Les incompréhensions doivent nourrir les ajustements. Un callbot qui n'est pas supervisé devient fragile, surtout quand les motifs, les offres ou les conditions changent.

Ce que Webotit met concrètement dans le périmètre

Sur un callbot relation client, Webotit cadre le projet comme un service vocal en production. Le périmètre couvre le décroché, la compréhension de l'intention, les scripts vocaux, la connexion aux outils utiles, le transfert contextuel et le reporting. Le but n'est pas de faire parler une IA. Le but est de réduire l'attente et de transmettre un contexte exploitable.

La qualité vocale est traitée comme un critère de production. Le callbot doit comprendre des formulations naturelles, gérer les silences, éviter les réponses trop longues et transférer proprement. Les intégrations CRM ou CCaaS permettent de relier la conversation aux files et aux équipes. Les scripts normés et la journalisation soutiennent la conformité et l'audit.

Le transfert contextuel est central. Le conseiller doit savoir pourquoi l'appel arrive, ce que le callbot a compris, ce qui a été demandé et ce qui reste à faire. Sans cette reprise, le callbot ajoute une couche de frustration. Avec elle, il retire une partie du travail répétitif et améliore la fluidité du plateau.

Checklist avant consultation fournisseur :

• cartographier numéros, files, horaires, SVI et CCaaS existants ;
• choisir des motifs courts, fréquents et peu risqués ;
• exiger des scripts vocaux testés à l'oral ;
• demander comment les appels seront écoutés, classés et corrigés.

Signaux à vérifier en démo :

• le décroché reste rapide malgré une demande naturelle ;
• le script vocal tient en phrases courtes ;
• le transfert transmet motif, statut et prochaine action ;
• le reporting distingue les motifs par service.

Ces signaux doivent être testés avec de vrais exemples d'appels, pas seulement avec une démonstration préparée.

Le cahier des charges doit préciser comment le callbot s'intègre à l'IT client. La téléphonie, le SVI existant, le CCaaS, le CRM, l'outil de ticketing ou l'API de suivi ne sont pas des détails techniques : ce sont eux qui permettent au callbot de personnaliser l'échange et de transférer un contexte utile.

Cette intégration facilite aussi la continuité entre agents IA Webotit. Une demande commencée au téléphone peut être reliée à un ticket, à un email ou à une conversation digitale, si le contexte est structuré et autorisé. Le client ne répète pas tout, et l'équipe garde une trace exploitable.

Livrables attendus en fin de cadrage

Le premier livrable est une matrice des motifs vocaux. Elle liste le volume, la durée moyenne, le risque, la sortie attendue et la règle de transfert. Le deuxième est un schéma téléphonie : numéros, files, SVI existant, CCaaS, horaires, débordement et règles d'escalade.

Le troisième livrable est un script vocal par motif. Il doit être court, oral, testable et validé métier. Le quatrième est un plan de tests audio : bruit, silence, accents, interruptions, demandes hors périmètre, appelants pressés, identifiants invalides.

Le cinquième livrable est un tableau de pilotage. Il doit suivre le taux de décroché, le temps d'attente, la durée moyenne, les appels résolus, les transferts utiles, les rappels, les abandons et les motifs non compris. C'est ce tableau qui permet de décider si le callbot doit être étendu.

Critères d'acceptation avant lancement

Un callbot doit être accepté avec des appels réalistes. Il faut tester un appelant clair, un appelant pressé, un appelant qui hésite, un appelant avec bruit de fond, un appelant qui interrompt, un appelant qui demande directement un humain et un appelant dont la demande est hors périmètre. Chaque test doit avoir une sortie attendue.

La recette doit aussi mesurer la durée. Une réponse correcte mais trop longue peut échouer en production. Le cahier des charges doit donc prévoir des limites : durée maximale d'une réponse, nombre de relances, moment de transfert, phrase de secours, règle de clôture. Ces éléments protègent l'expérience vocale.

Enfin, il faut tester le transfert. Le conseiller reçoit-il le bon motif ? Le résumé est-il compréhensible ? Le statut d'identification est-il clair ? L'appelant doit-il répéter ? Si le transfert échoue, le callbot ne peut pas être considéré comme prêt, même si la reconnaissance vocale fonctionne.

Questions à poser au fournisseur

Demandez comment le fournisseur gère la latence, les interruptions, le bruit et les accents. Demandez aussi comment les scripts vocaux sont écrits, validés et corrigés. Une bonne technologie ne suffit pas si le parcours oral est trop long ou mal formulé.

Demandez ensuite comment l'intégration téléphonique est réalisée : SIP, CCaaS, SVI existant, files, transfert, horaires, débordement, journalisation et reporting. Le fournisseur doit pouvoir expliquer ce qui relève de son périmètre et ce qui dépend de vos outils.

Demandez enfin comment les appels seront supervisés après lancement. Qui écoute ? À quelle fréquence ? Quels motifs sont corrigés ? Comment les scripts sont mis à jour ? Comment les nouveaux motifs sont priorisés ? Ces réponses déterminent la qualité réelle du service après les premières semaines.

Ce qu'il faut exclure du premier lot

Le premier lot doit éviter les appels qui demandent une négociation, une empathie forte, une interprétation juridique ou une décision sensible. Le callbot peut détecter ces situations et transférer vite, mais il ne doit pas les traiter comme des demandes simples.

Il faut aussi éviter les parcours vocaux trop longs. Si une demande nécessite dix questions, plusieurs vérifications et une explication détaillée, elle n'est probablement pas idéale pour un premier lancement. Le téléphone supporte mal les tunnels complexes. Un bon premier lot privilégie les motifs courts, fréquents et faciles à conclure.

Enfin, il faut exclure les données qui ne sont pas nécessaires. Chaque donnée demandée au téléphone ajoute de la friction et un risque d'erreur. Le cahier des charges doit limiter la collecte au strict nécessaire pour répondre ou transférer utilement.

Le bon premier lot doit donc être défini comme un service court : décrocher, comprendre, répondre ou orienter, puis conclure. Cette simplicité n'est pas une ambition réduite. C'est ce qui permet de tester la qualité vocale, la latence, la compréhension et la reprise humaine sans exposer toute la relation client à un risque de lancement trop large.

Un second lot peut ensuite ajouter des motifs plus riches, une donnée métier ou une file supplémentaire. Cette progression donne des preuves aux équipes terrain et permet d'ajuster la voix, les scripts et les transferts avant d'augmenter le volume.

Elle permet aussi d'impliquer progressivement les superviseurs. Leurs retours sur les appels transférés, les phrases mal comprises et les demandes récurrentes sont souvent plus utiles qu'une hypothèse formulée en atelier initial.

FAQ