Transfert d’appel par IA

Dans le cas le plus simple, l’appel est redirigé vers une destination : collaborateur, standard, portable ou file d’attente. L’IA arrête généralement son rôle dès que la destination prend le contrôle.

Le risque principal est de transférer trop tôt. Si la qualification est insuffisante, la personne appelée récupère exactement le bruit que l’IA était censée filtrer.

Le transfert accompagné crée une seconde branche d’appel. Le système appelle d’abord le destinataire, lui annonce le motif ou un résumé, puis relie les deux parties si le destinataire accepte.

Cela implique plusieurs états supplémentaires : appelant en attente, destination en sonnerie, acceptation/refus, timeout, reprise de l’appel initial, voire DTMF pour accepter ou décliner.

Dans certaines architectures, un transfert peut s’appuyer sur SIP REFER. Dans d’autres, la plateforme garde le contrôle des deux jambes d’appel et fait elle-même le bridge.

Le choix change la visibilité sur l’appel, la facturation, le contrôle du fallback et la capacité à jouer une annonce au destinataire.

Un scénario de transfert doit préciser ce qui se passe si la destination ne répond pas : reprendre l’appel, proposer un rendez-vous, essayer une autre destination, envoyer une alerte ou enregistrer une demande de rappel.

Sans fallback, le transfert devient un point de panne. C’est particulièrement critique pour les appels urgents ou fortement qualifiés.

Suivre séparément les tentatives de transfert, les transferts aboutis, les refus, les timeouts et les reprises par l’IA permet de voir si le système aide réellement l’équipe.

Un taux de transfert très élevé peut signaler une mauvaise qualification. Le bon indicateur est plutôt le taux de transfert pertinent et abouti.