Agent vocal, CRM et Outlook : confirmer sans perdre le suivi

Écrivez les états que l’équipe utilisera : demande reçue, créneau proposé, réservation en cours, événement créé, suivi CRM enregistré et annulation traitée. Cette liste est une proposition de conception à adapter. Le vocabulaire doit être assez précis pour qu’un employé sache si une action reste à faire sans réécouter l’appel.

Choisissez ensuite le système qui fait autorité pour chaque information. Le calendrier peut porter l’heure et l’occupation d’une ressource, tandis que le CRM porte le contact et le suivi commercial. Documentez qui tranche lorsque les deux divergent. Un champ « synchronisé » sans identifiant ni date de vérification explique mal ce qui s’est passé.

Le cahier des charges de l’agent vocal téléphonique doit relier les phrases prononcées à ces états. Une proposition de créneau utilise une formulation différente d’une création réussie. Si la réponse technique reste incertaine, l’agent annonce le statut autorisé par l’entreprise et la prochaine étape; il ne fabrique pas une confirmation pour terminer la conversation.

L’API Create event de Microsoft Graph crée un événement dans un calendrier. La documentation décrit les heures de début et de fin avec leur fuseau et indique qu’un événement comportant des participants entraîne l’envoi d’invitations. Choisissez donc les champs et les destinataires avant de lancer un essai.

Le champ transactionId de la ressource event aide le serveur à éviter les créations redondantes lorsque le client reprend la même demande après une réponse perdue. Il se fixe à la création et ne peut pas être modifié ensuite. Il ne réserve pas un créneau pour votre processus métier.

Votre intégration doit donc conserver son propre identifiant d’opération et définir le traitement des appels concurrents. Une disponibilité consultée quelques instants avant une création peut avoir changé entre-temps. La protection contre deux réservations incompatibles dépend des règles retenues pour les calendriers, les ressources et les autres canaux qui prennent des rendez-vous.

Prenons une entreprise de services fictive. Le calendrier accepte une réservation, puis le CRM devient indisponible avant l’écriture de la tâche. Cet exemple explique un mode de défaillance possible; il ne décrit aucun incident client ni test exécuté par Daillac. Annuler systématiquement l’événement pourrait provoquer une seconde erreur si l’invitation a déjà été reçue.

Une stratégie proposée consiste à conserver l’identifiant de l’événement et une tâche de rattrapage durable. La reprise tente d’abord de retrouver la même opération dans le CRM. Elle crée le suivi seulement si celui-ci manque réellement. Après plusieurs échecs selon la politique convenue, elle transmet l’exception à une personne avec assez d’information pour décider.

L’automatisation du CRM doit rendre cette file visible. Une personne désignée vérifie les dossiers en attente et dispose d’une consigne de communication avec le client. Une réussite technique tardive ne doit pas effacer l’historique du problème. Conservez les états utiles pour comprendre si un employé a déjà rappelé ou corrigé le dossier.

Le plan de recette commence par deux appels qui choisissent le même créneau. Ajoutez une réservation faite directement par un employé pendant l’appel automatisé. Le résultat attendu découle de la règle de l’entreprise : une seule réservation autorisée, une ressource distincte ou une exception explicitement assumée. N’inférez pas cette règle de l’apparence du calendrier.

Testez aussi un appel interrompu après l’acceptation orale, un délai d’attente après l’écriture serveur et une notification reçue deux fois. Pour chaque reprise, l’évaluateur doit retrouver la même demande et vérifier le nombre réel d’événements et de suivis. Un message d’erreur affiché au bon endroit ne prouve pas que les écritures ont été annulées.

Pour les dates, distinguez l’heure annoncée à l’appelant, le fuseau du rendez-vous et la valeur enregistrée. Utilisez des cas fictifs de changement d’heure et de déplacement entre régions. Vérifiez aussi une annulation pendant qu’un autre appel consulte le créneau, puis une modification faite manuellement dans Outlook. L’équipe approuve les règles de priorité.

La réconciliation rapproche les événements du calendrier et les dossiers CRM à partir d’identifiants stables. Elle cherche les éléments manquants, les heures divergentes et les annulations non propagées. Définissez une période de vérification adaptée au fonctionnement réel et une règle pour les données plus anciennes. L’article ne propose aucune fréquence universelle.

Chaque écart reçoit un statut et un propriétaire. Une correction automatisée doit rester dans les actions approuvées; une ambiguïté sur le client ou le rendez-vous exige une décision humaine. Une intégration CRM sur mesure permet d’exposer ces états dans l’outil de travail lorsque les connecteurs disponibles ne montrent pas les exceptions nécessaires.

Avant la mise en service, demandez une preuve complète pour quelques scénarios : identifiant d’appel, identifiant d’opération, événement calendrier, dossier CRM et formulation entendue. Limitez l’accès à ces traces et évitez les transcriptions complètes si elles ne sont pas nécessaires. Les données fictives permettent de répéter les essais sans utiliser un dossier client.

La décision de démarrer revient au responsable métier avec l’équipe technique. Ils doivent pouvoir expliquer le comportement pendant une panne et la méthode de rattrapage après celle-ci. Après une modification des règles ou d’un connecteur, reprenez les cas qui touchent les écritures et les confirmations. Un parcours de démonstration réussi ne remplace pas ces preuves de reprise.