Handoff callbot : transfert humain et agent assist

Le handoff n’est pas un échec. C’est là que vous gagnez du temps.

On entend encore :

“Notre callbot doit éviter les transferts.”

Non.

Votre callbot doit éviter les mauvais transferts :

• transferts sans contexte,
• transferts trop tard,
• transferts qui obligent l’utilisateur à tout répéter,
• transferts vers le mauvais service.

Un transfert bien fait, c’est une victoire :

• l’utilisateur arrive chez le bon agent,
• l’agent sait déjà pourquoi il est là,
• et l’appel se résout plus vite.

Pour cadrer la prod (KPI, monitoring, “POC vs scale”), voyez : Callbot en production.

Handoff : définition simple (et vocabulaire utile)

On mélange souvent trois choses :

1. transfert d’appel (la téléphonie : qui parle à qui),
2. handoff de contexte (l’information : ce qu’on sait déjà),
3. agent assist (l’aide proactive à l’agent pendant l’appel).

Votre callbot peut transférer un appel sans handoff de contexte.

Et c’est généralement là que naît la souffrance :

• “Bonjour, expliquez-moi votre problème.”
• “Je viens de l’expliquer au robot.”
• “Oui, mais moi je ne l’ai pas.”

Ce dialogue est un impôt. À l’échelle, c’est une taxe monstrueuse.

Les types de transferts : blind, warm, callback (et le bon usage)

Blind transfer : rapide, mais dangereux

On transfère sans “pré‑brief”.

Ça va vite.

Mais :

• l’agent n’a pas le contexte,
• l’utilisateur répète,
• l’AHT monte.

Warm transfer : plus long… mais souvent plus rentable

Warm transfer, c’est :

1. le callbot collecte et résume,
2. l’agent reçoit le contexte,
3. l’appel est transféré avec une continuité.

C’est plus “cher” en design.

Mais c’est souvent là que se joue le ROI.

Callback : quand la file d’attente est la réalité

Le callback est une forme d’escalade intelligente :

• vous évitez de laisser un humain “en attente”,
• vous collectez l’essentiel,
• vous rappelez avec un agent disponible.

Et vous gagnez en perception (“on me rappelle”) tout en gardant de la discipline (pas de conversation qui tourne dans la file).

Transfert téléphonie : SIP REFER (quand on parle “standard”)

Si votre stack est SIP‑centrée, le transfert d’appel s’appuie souvent sur des mécanismes standardisés.

Par exemple, la méthode REFER est spécifiée dans l’IETF RFC 3515 (SIP Refer Method).¹

Vous n’avez pas besoin de connaître l’RFC par cœur pour réussir un handoff.

Mais c’est utile pour comprendre un point : le transfert n’est pas “magique”. C’est une série d’événements, de signalisations, et parfois de médias à recâbler.

Si la téléphonie vous donne des sueurs froides, l’article de base est ici : SIP/RTP/WebRTC pour callbot.

Le handoff de contexte : ce que vous devez passer (et ce que vous ne devez pas passer)

Un handoff utile, c’est une petite fiche.

Pas un roman.

Le minimum viable (qui marche dans 80% des cas)

• intention (motif),
• statut du parcours (“où on en est”),
• champs collectés (numéro client, date, montant…),
• décisions déjà prises (“éligible / non éligible / incertain”),
• et la prochaine action recommandée.

Le bonus (quand vous êtes mature)

• résumé en 3 lignes,
• extraits de phrases clés (verbatim),
• sources consultées (RAG),
• et raisons d’escalade (pourquoi le bot passe la main).

Le danger, c’est de tout passer :

• PII non nécessaire,
• détails inutiles,
• données sensibles dans des champs non sécurisés.

Pour les bonnes pratiques RGPD et logs, vous avez : RGPD & enregistrement/transcription.

Mauvais handoff vs bon handoff : la différence en 30 secondes

Le “mauvais” handoff, ce n’est pas une malédiction.

C’est juste un transfert où le contexte est absent, flou, ou inutilisable.

Exemple (mauvais)

Agent :

“Bonjour, je peux vous aider ?”

Client :

“Je viens d’expliquer au bot. Je veux déplacer mon rendez-vous.”

Agent :

“Ok. Vous aviez rendez-vous quand ?”

Client :

“Mardi à 14h.”

Agent :

“Chez quel praticien ?”

Vous connaissez la suite : 2 minutes de re-collecte, puis 30 secondes d’action.

Exemple (bon)

Agent (avec contexte affiché) :

“Bonjour, je reprends votre demande : vous souhaitez déplacer votre rendez-vous de mardi 14h. J’ai votre numéro client et votre date de naissance. Je vous propose jeudi 10h ou vendredi 16h, qu’est-ce qui vous arrange ?”

Même résultat final, mais :

• moins d’effort côté client,
• moins d’erreurs,
• plus de vitesse.

Table “utile” (copiable)

Le but n’est pas d’avoir un tableau parfait.

Le but est d’aligner l’équipe sur ce que “bon” veut dire — sinon on débat au feeling.

Agent Assist : quand l’IA aide l’agent, pas seulement l’appelant

Le callbot répond à l’appelant.

L’agent assist répond à l’agent (en coulisse).

Et c’est souvent un endroit très rentable pour mettre de l’IA, parce que :

• l’agent est formé,
• l’agent comprend les limites,
• et l’agent peut rattraper une erreur.

Google (CCAI / Agent Assist)

Google documente des fonctionnalités d’Agent Assist dans son offre de contact center AI, incluant des éléments comme des suggestions et de l’assistance pendant l’interaction.²³

Genesys (Agent Copilot / Agent Assist)

Genesys décrit des capacités d’agent assist / copilot (assistants pour agents) dans son écosystème, orientées vers l’amélioration de la productivité et la qualité de service.⁴

Amazon Connect (Wisdom / assistance agent)

Amazon a annoncé des évolutions autour de Connect Wisdom (connaissance/assistance) pour aider les agents, avec une logique de suggestions liées à une base de connaissance.⁵

Handoff bidirectionnel : quand l’agent rend la main au bot

On parle beaucoup de “bot → agent”.

Mais à l’échelle, vous voulez aussi “agent → bot”.

Pourquoi ?

• après une conversation humaine, certaines actions sont mécaniques (envoyer un SMS de confirmation, ouvrir un ticket, planifier un rappel),
• et certaines informations doivent être “réinjectées” (statut, prochaine étape).

Deux patterns utiles :

1. After‑call automation : l’agent clique “résolu”, le système déclenche des tâches (email, SMS, ticket).
2. Return to bot : l’agent clôture la partie sensible, puis le bot reprend pour la partie administrative (“je vous envoie le récap, au revoir”).

Le bénéfice : on réduit le travail répétitif et on stabilise l’expérience, sans essayer de faire “un bot qui fait tout”.

Sécurité : le transfert est une surface d’attaque (social engineering compris)

Le transfert, c’est un moment vulnérable :

• l’utilisateur est déjà engagé,
• il fait plus confiance,
• et il est prêt à donner des infos.

Un callbot doit donc :

• éviter de “répéter” des données sensibles à voix haute,
• éviter d’envoyer un résumé complet dans un canal non sécurisé,
• et escalader dès qu’une demande sort de la zone de confiance.

Pour les menaces LLM (prompt injection, exfiltration, spoofing), l’article à lire est : Sécurité callbot.

Ce que l’agent assist doit produire (sinon ce n’est qu’un widget)

Les features utiles d’agent assist ressemblent à :

• résumé live (“ce que le client a dit”),
• prochaines étapes (“quoi faire ensuite”),
• liens vers la procédure (RAG + sources),
• remplissage CRM (champ pré‑rempli, à confirmer),
• alertes (“ce cas doit escalader”, “vérifier identité”).

Le piège : “ça affiche un paragraphe”.

Un agent n’a pas besoin d’un paragraphe. Il a besoin :

• d’un signal,
• d’une action,
• et d’une justification.

Cas d’usage (très) typiques : où le handoff paye immédiatement

1) Assurance : déclaration + collecte, puis décision humaine

Le callbot peut :

• collecter les faits (date, lieu, type, dommages),
• récupérer un statut dossier,
• et préparer le terrain.

Puis il escalade :

• si le cas est sensible,
• si l’appelant est en stress,
• ou si des preuves sont nécessaires.

Le bon handoff, ici, c’est : un résumé factuel + champs collectés + “ce qui manque”.

2) Banque : intention claire, authentification, puis action

Le callbot peut faire du routage et de la qualification (“opposition”, “RDV”, “plafond”).

Mais dès qu’on touche à :

• authentification forte,
• fraude,
• ou opérations sensibles,

vous voulez un handoff solide vers un humain (ou un parcours très contrôlé).

3) E‑commerce : suivi et exceptions

Sur du “où est mon colis”, un bot peut résoudre vite.

Mais dès qu’il y a :

• litige,
• remboursement,
• ou exception logistique,

un handoff propre évite la boucle “je répète” et permet à l’agent de trancher rapidement.

Dans ces trois cas, la morale est la même : ce n’est pas la plus jolie voix qui gagne. C’est la continuité entre bot et humain.

KPI : mesurer la “transfer quality” (et arrêter de compter juste le taux de transfert)

Le taux de transfert est un KPI facile.

Mais il ne dit pas si vous transférez bien.

Quelques KPI utiles :

• repeat rate : combien de fois le client répète la même info,
• time-to-context : combien de temps avant que l’agent comprenne vraiment,
• transfer abandonment : combien raccrochent pendant le transfert,
• resolution after transfer : est-ce que ça se résout ensuite,
• handoff completeness : champs critiques présents (oui/non).

Un autre KPI sous-estimé : le temps de transfert.

Si votre callbot met 25 secondes à “passer un conseiller”, vous fabriquez de l’abandon — même si tout le reste est bon.

Mesurez donc :

• temps “demande de transfert” → “agent en ligne”,
• et où ça bloque (file, routage, CRM, temps de résumé, etc.).

C’est aussi ça, un callbot “qui tient la prod” : il ne se contente pas d’être intelligent, il sait être rapide quand il faut.

Ces métriques se construisent. Elles ne tombent pas du ciel.

Pour une méthode d’évals plus large (offline + prod), voir : Benchmark callbot.

Open source vs cloud : construire soi-même l’agent assist, ou s’appuyer sur un vendor ?

Comme pour le reste du callbot, vous avez un arbitrage :

• cloud : plus rapide, intégré, SLA,
• self‑host/open source : plus de contrôle, plus d’ops.

Dans tous les cas, les modèles (LLM/STT/TTS/S2S) ne sont qu’une partie de l’histoire.

Le panorama 2026 (et les options open-weight comme Voxtral pour STT, ou des LLM open-weight) est dans : Stack callbot 2026.

Implémenter un handoff propre : méthode en 7 étapes

1

Définir les conditions d’escalade

Quand passe-t-on la main ? Sur quels intents ? Sur quels risques ? Le “handoff” commence par une politique.

2

Définir le paquet de contexte (schema)

Intention, champs collectés, étape du parcours, résumé court, sources. Un schema stable = intégrations stables.

3

Brancher l’événementiel

Loggez les événements : début appel, champs, actions, échecs, escalade. Sans timeline, pas de debug.

4

Générer un résumé orienté action

Trois lignes max, puis “prochaine action”. Le but est d’aider, pas de raconter.

5

Afficher côté agent (et tester l’usage)

Un résumé invisible n’aide personne. Mettez-le dans l’outil agent (CRM, console).

6

Tester warm transfer / callback

Mesurez : abandons, temps de compréhension agent, répétitions.

7

Évaluer et itérer

Si vous n’avez pas de métriques de transfer quality, vous ne saurez pas si vous gagnez du temps… ou si vous déplacez le problème.

FAQ

Questions frequentes

Faut-il viser zéro transfert ?+

Non. Visez zéro transfert inutile. Un callbot qui refuse d’escalader finit par créer des appels plus longs, plus frustrants, et plus coûteux.

Le résumé automatique peut-il remplacer un agent ?+

Non. Il sert à accélérer la compréhension et à réduire les répétitions. Le but est d’augmenter la performance humaine, pas de la supprimer.

Qu’est-ce qu’un bon handoff de contexte ?+

Un schema court, stable, orienté action : intention, champs, étape, résumé 3 lignes, sources. Et pas de données sensibles inutiles.

Agent assist ou callbot : je commence par quoi ?+

Si vous avez un plateau agents et des procédures, l’agent assist est souvent un quick win. Le callbot autonome demande plus de gouvernance et d’obs.

Sources et references

1. [1]IETF, “RFC 3515 — The SIP Refer Method”.
2. [2]Google Cloud, “Agent Assist overview (Conversation AI / CCAI)”.
3. [3]Google Cloud, “Conversational AI for Contact Center”.
4. [4]Genesys, “Agent Copilot / Agent Assist overview”.
5. [5]AWS, “Amazon Connect Wisdom — What’s New (agent assistance/knowledge)”.