Rappel file d'attente Microsoft Teams : ce qu'il fait, ce qui manque

Microsoft a ajouté une option de rappel native aux files d’attente Teams fin 2024. Elle se configure dans le centre d’administration Teams ou en PowerShell, elle est incluse dans votre licence Teams Phone, et pour beaucoup d’organisations c’est suffisant. Mais elle n’a pas de minuteur propre. Elle emprunte le queue timeout, et le temps d’attente qu’elle annonce à votre appelant n’a aucun rapport avec le temps qu’il a réellement attendu. Cet article couvre ce que la fonction fait, où elle casse quand de vrais appelants sont impliqués, et ce qu’un rappel doit garantir pour valoir la peine d’être proposé.

Pourquoi les appelants demandent un rappel

Les appelants n’attendent pas. En France, l’AFRC publie chaque année son Baromètre de la Relation Client qui montre à quel point la voix reste un canal décisif quand la satisfaction se joue à la seconde près. Au Royaume-Uni, l’étude ContactBabel 2024 sur 225 centres de contact chiffre le taux moyen d’abandon d’appel à 8,4 % et le temps moyen de décrochage à 116 secondes. SQM Group place le benchmark international plutôt autour de 5 %, considère 5 à 10 % comme acceptable, et situe les meilleurs centres autour de 3 % ou moins.

Ces deux chiffres décrivent le même problème sous deux angles. Un temps moyen de décrochage proche de deux minutes signifie qu’une part significative de vos appelants décide de rester ou pas exactement au moment où leur patience s’épuise.

Ce que le chiffre d’abandon cache est pire. Un appel abandonné est rarement un appelant perdu. C’est un appelant qui va rappeler, souvent dans l’heure, souvent deux fois. Votre volume ne baisse pas quand les gens raccrochent. Il se déplace, et il se concentre sur votre pic.

Un rappel fait ce qu’aucune musique d’attente ne fait : il sort l’appelant de la file sans le sortir du processus. Bien fait, l’appelant arrête d’attendre, la file arrête de gonfler, et l’organisation garde le contact. Mal fait, c’est pire que rien. Un appelant qui raccroche sur une promesse et qui n’est jamais rappelé a été trahi deux fois.

Ce que Microsoft a construit

Rendons à César : le rappel natif dans les files Teams est une vraie fonction, correctement intégrée, incluse dans la licence que vous avez déjà.

L’administrateur peut définir trois paramètres comme seuils dans une file : le temps d’attente dans la file, le nombre d’appels en attente, ou le nombre d’agents disponibles. Si un seuil est atteint, l’appelant devient éligible au rappel. Le troisième est le plus intéressant : il fonctionne sur le ratio entre appelants en attente et agents connectés. Avec trois agents connectés et un ratio de un, le quatrième appelant qui entre dans la file devient éligible. C’est une façon propre de dire “on est submergés” sans hardcoder un nombre de minutes.

L’appelant devient éligible après 60 secondes d’attente minimum, et le queue timeout doit être supérieur à ce délai.

La configuration se fait soit dans le centre d’administration Teams, sous Voice puis Files d’attente, sur un onglet Rappel dédié. Tout ce que l’admin règle, l’appelant l’entendra.

Les réglages qui comptent, en un tableau :

Réglage	Ce qu’il fait
Time in queue	Attente minimum avant que l’offre de rappel ne soit jouée. Minimum 60 secondes, doit rester inférieur à la valeur Call timeout.
Calls in queue	Rappel devient éligible quand plus de N appelants attendent. Doit rester inférieur à la valeur Call overflow.
Agents ratio	Éligible quand le ratio appelants en attente / agents connectés dépasse une valeur. Une façon propre de dire “on est submergés” sans hardcoder de minutes.
Message d’accueil : fichier audio ou TTS	Le prompt joué aux appelants éligibles, leur indiquant quelle touche presser.
Touche DTMF	Le chiffre que l’appelant presse pour accepter l’offre. N’importe quelle touche d’un clavier téléphonique classique.
Groupe de notification (Microsoft 365)	Reçoit un email si le rappel échoue ou ne peut pas être complété.
Conference mode	Doit être activé sur la file. Le flux rappel ne fonctionne pas sans.

Tout ce qui précède est aussi scriptable via New-CsCallQueue et Set-CsCallQueue pour les équipes qui gèrent les files en masse.

L’appelant entend l’offre, presse la touche, puis passe par une étape qui surprend la plupart des administrateurs lors du premier test. Teams joue une annonce système prédéfinie qui demande à l’appelant d’enregistrer son nom. Puis elle lui indique que le prochain agent disponible le rappellera, que le rappel peut prendre jusqu’à X minutes, et que si le rappel est manqué, il devra rappeler la ligne plus tard.

Côté agent, dès qu’un agent termine un appel et devient disponible, la plateforme Teams l’appelle, démarre une conférence quand l’agent décroche, informe l’agent de la demande de rappel, puis compose le numéro de l’appelant. Le compte de ressource de l’auto attendant ou de la file est utilisé comme identité sortante.

Rien de tout ça ne coûte plus. Auto attendant et call queue viennent avec le premier add-on Teams Phone. Si vos besoins sont modestes, arrêtez de lire ici et allez l’activer.

Où le rappel file d’attente Teams casse

La fonction marche. Les problèmes apparaissent dès qu’il y a de vrais appelants, de vrais queue timeouts, et une équipe qui ne peut pas prédire quand un agent sera libre.

Le récit public le plus complet de ces problèmes vient de Thorsten Pickhan, Microsoft MVP pour Microsoft 365, qui a testé la fonction en conditions de production et a documenté ce qu’il a trouvé sur Practical365. Il est globalement positif, ce qui donne d’autant plus de poids à ses critiques.

La promesse, c’est le queue timeout, pas l’attente de l’appelant

Quand votre appelant accepte un rappel, Teams lui indique combien de temps ça va prendre. Ce nombre n’est pas calculé à partir de sa position, de vos effectifs ou de votre temps moyen de traitement. Interrogé dans les commentaires de son article pour savoir si le message pouvait être modifié, Pickhan a confirmé que le prompt système utilise toujours la valeur du queue timeout définie dans la configuration de la file : si le timeout est réglé à cinq minutes, le prompt annonce un rappel dans cinq minutes, indépendamment du temps que l’appelant a déjà attendu. Une option de message personnalisé n’existe pas aujourd’hui.

Deux appelants acceptent un rappel, l’un après 90 secondes, l’autre après 11 minutes. Les deux entendent la même chose. Le nombre qu’ils entendent est une valeur de configuration qui existe pour un tout autre usage.

L’administrateur qui posait la question a résumé la conséquence opérationnelle : dirigeant une petite équipe MSP, il a expliqué qu’ils ne peuvent pas garantir quand un agent sera libre, puisque les agents peuvent rester en communication trente minutes ou plus, et a conclu qu’il avait de grands espoirs pour la fonction mais qu’elle semblait manquer d’éléments.

Il n’y a pas de minuteur dédié

La fonction rappel repose entièrement sur la valeur du queue timeout, parce que Microsoft n’a pas implémenté de minuteur dédié pour elle. Tout le processus, qui inclut l’attente de l’appelant dans la file, la demande de rappel, la recherche d’un agent disponible et l’initiation du rappel, ne peut pas dépasser le queue timeout.

Votre timeout n’est pas un budget rappel. C’est la valeur qui décide de ce qui arrive à un appel non répondu. Maintenant elle gouverne silencieusement un processus qui commence par quelqu’un qui attend en ligne et qui se termine par un appel sortant vers un téléphone mobile.

Un rappel raté peut être enregistré comme un succès

Dans les tests de Pickhan, avec un délai d’attente d’une minute et un queue timeout de deux minutes, l’appelant activait le rappel et l’agent test recevait l’appel. Mais quand l’agent décrochait, il n’entendait que le message de rappel, parfois complet, parfois quelques mots, puis le système coupait l’appel. Aucun message d’erreur, aucune indication de pourquoi l’appel s’était terminé abruptement.

Comme Teams avait réussi à connecter un agent et à commencer à jouer le message, le rappel était traité comme réussi et personne n’était informé de l’échec. L’appelant n’était pas rappelé. Le groupe de notification ne recevait rien. Le reporting disait que ça avait marché. Monter le timeout à cinq minutes a résolu le problème, mais seulement après des tests étendus et une relecture attentive de la documentation.

L’offre est rejouée uniquement au redémarrage de la musique d’attente

L’option rappel est proposée à chaque fois que la musique d’attente se termine et redémarre. La musique d’attente par défaut dure deux minutes. Donc même si un appelant devient éligible après une minute, avec la musique par défaut il n’entendra l’offre qu’après deux minutes. Si vous avez chargé votre propre musique, la cadence d’offre devient une propriété de votre fichier audio.

Pas de retry

Il n’y a pas de deuxième tentative. L’annonce informe l’appelant que s’il manque le rappel, il doit rappeler la ligne plus tard. Les appelants manquent des callbacks tout le temps. Un système de rappel sans retry transforme une grande partie des promesses acceptées en un appelant qui a attendu, raccroché, manqué un appel, et doit tout recommencer.

Restrictions sur les identifiants d’appelant

La fonction rappel exige que le numéro entrant de l’appelant soit publiquement composable, non premium, et au format E.164, avec des exclusions spécifiques pour l’Amérique du Nord. Les appelants depuis un standard sans ligne directe, depuis certaines plages non géographiques, ou avec présentation du numéro masquée n’auront pas l’option.

Le message n’est pas personnalisable

Au-delà du prompt d’offre, le flux est figé. L’étape d’enregistrement du nom est une annonce système prédéfinie. Vous ne pouvez pas la sauter, la reformuler, ou l’adapter au ton de votre marque.

À noter : Microsoft a un meilleur rappel, et il n’est pas dans Teams

Dynamics 365 Contact Center a une approche différente. Le direct rappel se configure comme action d’overflow au niveau de la file, déclenché quand la file dépasse un nombre défini d’appels en attente ou dépasse le temps d’attente estimé. Le work item reste dans la file après que l’appelant a raccroché, et dès qu’il atteint la position un, un rappel vocal est initié automatiquement. Ce design préserve correctement la place de l’appelant. Il a ses propres limites : l’option n’est pas personnalisable, direct rappel n’est pas supporté avec les agents Copilot Studio, et le système ferme automatiquement les demandes après sept jours. Le point pour un administrateur Teams : Microsoft a construit le rappel deux fois, et l’implémentation la plus complète est dans un autre produit avec une autre licence.

Ce qu’un rappel doit garantir pour avoir de la valeur

Mettons les produits de côté un instant. Un rappel en file fait une promesse à un être humain : raccroche, et on te rappelle. Quatre choses doivent être vraies pour que cette promesse ait du sens.

L’appelant garde sa place, sinon ce n’est pas un rappel. Si un appelant qui a attendu onze minutes est rappelé après quelqu’un qui a attendu deux minutes, vous ne lui avez pas offert un rappel. Vous lui avez offert un répondeur avec un meilleur marketing. L’heure d’arrivée de l’appelant doit le suivre.

L’offre doit sous-vendre, la promesse doit sur-vendre. Ça sonne contradictoire, et c’est l’idée la plus utile ici. L’offre doit motiver : si vous dites à quelqu’un que son attente sera de moins de vingt minutes, il va rester en ligne. Donc l’offre borne l’estimation par le bas, plus de quinze minutes. La promesse doit être tenue, elle est mesurée, et être en retard est un échec. Donc la promesse borne la même estimation par le haut, avec une marge, moins de vingt minutes. Deux annonces, une estimation sous-jacente, directions opposées. Un système qui utilise un seul nombre pour les deux échoue soit à convertir les appelants, soit à tenir ses promesses, et souvent les deux.

Si vous ne pouvez pas mesurer la promesse, vous ne l’avez pas faite. Posez à votre vendeur, ou à votre propre plateforme, une question : quel pourcentage de callbacks ont été connectés avant le temps que vous avez promis ? Si la réponse demande un projet, la promesse est décorative. La deadline annoncée à l’appelant et la deadline stockée pour la mesure doivent être la même valeur, écrite une seule fois. Deux calculs séparés vont dériver.

Mieux vaut ne rien dire que promettre ce qu’on ne peut pas tenir. Un centre ferme à 18h. Un appelant arrive à 17h50 avec une attente estimée de quarante minutes. “On vous rappelle dans quarante-cinq minutes” est un mensonge. À 18h30, il n’y a personne dans le bâtiment. Le bon comportement est de changer de registre complètement : pas une durée mais une fenêtre, dès la réouverture, avec un rappel programmé pour l’ouverture suivante. Et quand le système ne sait pas quand il rouvre, parce que les horaires n’ont jamais été configurés, il devrait ne rien dire du tout. Une promesse sans date n’est pas une promesse.

Comment on a implémenté le rappel chez Heedify

Chaque réglage est par file sur Heedify Contact Center, et chaque seuil ci-dessous est défini par l’admin. Les valeurs entre parenthèses sont typiques, pas figées :

• Seuil d’offre (ex. 3 minutes) : en dessous de cette attente, aucun rappel n’est proposé, parce que proposer un rappel pour deux minutes d’attente irrite plus que ça n’aide.
• Seuil de report (ex. 30 minutes) : au-dessus, on arrête d’annoncer une durée et on bascule sur une fenêtre (“dès la réouverture”, “demain matin”).
• Délai avant l’offre : typiquement 15 secondes après l’entrée en file.
• Callbacks en attente maximum (ex. 200) : un plafond dur sur les promesses en cours. Au-dessus, on arrête d’en faire de nouvelles. Les appels sont toujours pris, mis en file, servis.
• Marge de sécurité : l’estimation brute est multipliée par un facteur (ex. 1,3) avant d’être annoncée comme promesse.
• Arrondi de la promesse : arrondi à la minute entière, toujours par le haut (pas de 5 minutes par défaut).
• Temps de traitement par défaut : une valeur de départ (ex. 5 minutes) utilisée tant que l’historique de la file ne fournit pas de vraie moyenne.
• Marge “promesse à risque” : à quelle proximité de la deadline le système commence à flagger le rappel comme à risque de dépassement.

Le plafond compte. Un système de rappel sans plafond est un système qui finit par mentir à grande échelle.

Centre chargé : quatre agents, cinq minutes de temps moyen de traitement, appelant vingtième dans la file.

Attente estimée = 20 × 5 / 4 = 25 minutes Promesse = 25 × 1,3 → 35 minutes (arrondi supérieur)

L’appelant entend “plus de 25 minutes” dans l’offre et “moins de 35 minutes” dans la promesse. Une annonce fixe unique de quinze minutes serait un mensonge pour quatre appelants sur cinq.

Centre calme : mêmes effectifs, appelant troisième dans la file, attente estimée 2,25 minutes. En dessous du seuil d’offre, donc rien n’est annoncé.

L’appel de 17h50 : attente estimée de quarante minutes contre une fermeture à 18h. Au-dessus du seuil de report et non absorbable avant fermeture, donc le système bascule sur une fenêtre. L’appelant est rappelé le lendemain matin, avant les arrivées de 9h, parce qu’il attend depuis la veille au soir. Ça a une conséquence à assumer : la première chose que fait votre équipe le matin est de vider les callbacks de la veille.

Si le client manque le rappel, on retente :

• Trois tentatives par défaut, espacées de 5 minutes, 15 minutes, puis 1 heure.
• Les promesses expirent après 24 heures, même s’il reste des tentatives.
• Un appelant qui manque une tentative garde sa priorité mais reçoit une nouvelle promesse.
• Si l’agent ne décroche pas, le rappel retourne dans la file sans consommer de tentative.

Quand l’agent décroche, il y a un gap de dix à vingt secondes pendant que la plateforme compose le numéro du client. Le silence dans ce gap se lit comme une ligne morte et les agents raccrochent. Donc l’agent entend :

• une annonce whisper unique qui lui dit que c’est un rappel,
• et une tonalité de composition en boucle jusqu’à ce que le client rejoigne.

Six langues pré-enregistrées : français, anglais, néerlandais de Belgique, allemand, espagnol et italien. Chaque annonce est une phrase pré-enregistrée complète plutôt que des fragments assemblés à la volée, parce que l’assemblage s’entend.

La métrique centrale est le taux de promesse tenue : callbacks connectés avant l’heure promise, divisés par callbacks connectés. Elle est vérifiable par construction, parce que la deadline annoncée à l’appelant et la deadline stockée dans le record sont la même valeur, écrite une seule fois.

Une conséquence est contre-intuitive. Un appelant qui accepte un rappel raccroche, et un système naïf classe ça comme un appel abandonné. Donc le jour où vous activez la fonction, votre taux d’abandon empire pendant que votre service s’améliore. On gère ça explicitement : un appelant qui a accepté un rappel n’est pas un abandon. La branche sortante est aussi exclue des volumes d’appels, donc un appelant ne devient pas deux appels.

Avec Heedify AIR, notre agent IA vocal pour Microsoft Teams, le clavier disparaît entièrement. Heedify AIR propose le rappel en langage naturel, comprend la réponse de l’appelant sans touche DTMF, et capture pourquoi il appelait. Pas de “tapez 1”, pas d’annonce système qui demande à l’appelant d’enregistrer son nom. La demande est écrite directement dans la file, et l’agent qui prend le rappel sait déjà de quoi il retourne. Un rappel où l’agent connaît la raison est un appel plus court et un meilleur appel.

Ce qu’on ne fait pas, franchement, parce que c’est ce qui rend crédible tout ce qui précède. L’appelant ne choisit pas le numéro sur lequel on le rappelle : on appelle le numéro qu’il a composé, ce qui veut dire qu’un appelant depuis un standard sans ligne directe ne peut pas utiliser la fonction. L’appelant ne choisit pas un créneau. Ce n’est pas un dialer de campagne sortante. Et c’est voix seulement.

FAQ