E-commerce
28 juin 2026
« Je viens de tout expliquer au robot. Pourquoi me redemandez-vous mon numéro de commande ? » Ce reproche arrive quand le handoff fonctionne en surface (le client voit « transfert en cours ») mais l'agent reçoit une conversation vide. Le transfert de contexte est ce qui sépare un passage fluide d'une rupture d'expérience.
eesel AI rappelle en 2026 que l'erreur la plus fréquente est de transférer sans le paquet complet : historique, tentatives bot, données commande et raison d'escalade (eesel AI, handoff 2026).
Ce guide #155 couvre la transmission de contexte bot → humain. Plus précis que quand transférer (#12) : ici, payload, slots, résumé agent et continuité client.
Summary
Qu'est-ce que le transfert de contexte bot → humain ?
Le transfert contexte chatbot e-commerce est l'envoi structuré de tout ce que le bot a appris vers l'agent humain, avant la première réponse humaine.
Handoff vs contexte
Handoff : décision de passer la main (trigger, file, délai). Contexte : contenu transmis pour que l'humain reprende sans redemander. Un handoff sans contexte = transfert froid. Un contexte sans handoff clair = client perdu en attente.
Transfert chaud vs froid
CallSphere distingue le transfert chaud (agent lit le résumé 10-15 s, ouvre avec une phrase contextualisée) du transfert froid (agent : « Bonjour, quel est votre problème ? ») (CallSphere, context transfer 2026).
Coût de la répétition
Alhena estime que chaque « recommencez depuis le début » fait chuter satisfaction au moment où le client est déjà tendu (Alhena, escalation chatbot).
En quoi diffère-t-il du guide handoff (#12) ?
L'article handoff (#12) répond à quand transférer. Ce guide #155 répond à quoi transmettre et comment.
#12 : triggers et règles
Demande humaine, produit abîmé, VIP, boucle bot. Matrice live vs ticket. Messages client au transfert.
#155 : architecture contexte
Payload 7 éléments, slots obligatoires, format résumé agent, intégration Gorgias/Zendesk, KPI « repeat info rate ».
Compléments utiles
Authentification (#122) pour les données déjà vérifiées à transmettre. Confidentialité (#154) pour informer le client que l'humain verra l'historique.
Quels éléments composer dans le payload de contexte ?
Le payload contexte handoff standard regroupe sept blocs reproductibles.
Les 7 éléments
Transcript complet : fil bot + client horodaté
Résumé IA : 2-3 phrases, problème + statut actuel
Intent détecté : WISMO, retour, litige, pré-achat
Sentiment : neutre, frustré, urgent (score si dispo)
Données commande : #, statut, tracking, montant, SKU
Contexte produit : fiche consultée, questions posées
Tentatives bot + raison escalade : liens envoyés, échec, trigger
Bonus agent
Prochaine action suggérée, tag VIP/B2B, auth niveau déjà validé (e-mail match). eGrow recommande d'ajouter le score sentiment pour calibrer l'ouverture humaine (eGrow, handoff e-commerce 2026).
Quels slots collecter avant le transfert ?
Les slots pré-handoff chatbot évitent que l'agent collecte ce que le bot aurait dû demander.
Slots universels e-commerce
order_id + e-mail match Shopify
intent : classifié avant escalade
issue_summary : une phrase client ou bot
Slots par intent
Retour : raison, produit concerné, délai réception
Produit abîmé : photo uploadée oui/non
WISMO : statut lu bot, tracking déjà communiqué
Pré-achat : SKU consulté, contrainte (taille, budget)
Règle
Si un slot manque pour résoudre en bot, demandez-le avant d'annoncer le transfert. Annoncer « je vous transfère » puis poser 4 questions = rupture.
Priorisation slots
En litige produit abîmé, la photo prime sur le numéro de téléphone. En WISMO, order_id + e-mail suffisent. Ne bloquez pas le transfert 3 minutes pour un slot nice-to-have quand le client demande déjà un humain.
Comment rédiger ou générer le résumé agent ?
Le résumé handoff IA doit être factuel, pas marketing.
Template 5 lignes
Client : [nom], [e-mail], [VIP si oui]. Commande : [#], [statut], [montant]. Problème : [1 phrase]. Bot a : [actions]. Escalade car : [trigger]. Suggéré : [prochaine action].
Exemple DTC
« Client Léa M., #8841 livrée hier, robe M reçue déchirée sous l'aisselle. Bot a vérifié statut livré, demandé photo (reçue), proposé portail retour (refusée, veut échange). Escalade : produit abîmé + frustration. Suggéré : échange express ou remboursement si stock M épuisé. »
Garde-fous génération
Pas de promesse bot non validée dans le résumé (« remboursement approuvé » si non fait). BlueTweak : le résumé inclut tentatives et sentiment, pas seulement le dernier message (BlueTweak, handoff 2026).
Que voit et entend le client pendant le transfert ?
La continuité client handoff se joue en trois messages.
Message 1 : annonce
« Je vous mets en relation avec [Prénom/équipe]. Je lui transmets déjà votre commande et notre échange. »
Message 2 : attente
Si file : délai estimé, position ou « sous 3 min ». Silence > 60 s sans update = abandon. CallSphere cible < 30 s avant prise en charge humaine.
Message 3 : ouverture humaine
L'agent reprend le fil, ne rouvre pas un nouveau ticket visible. Première phrase contextualisée : « Bonjour Léa, je vois votre souci sur la robe commande #8841. J'ai la photo, je regarde la solution la plus rapide. »
Hors horaires
« Dossier créé avec tout le contexte. Réponse sous [X] h ouvrées. Vous n'aurez pas à répéter. »
Piège multicanal
Si le client a commencé en chat puis reçoit un e-mail « merci de nous décrire votre problème », le contexte est perdu. L'e-mail de suivi doit reprendre le résumé bot et le numéro de dossier, pas un formulaire vierge.
Comment présenter le contexte côté agent dans le helpdesk ?
L'UX agent contexte handoff doit tenir en un coup d'œil dans Gorgias, Zendesk ou Intercom.
Sidebar recommandée
Bloc résumé en haut (5 lignes max)
Commande Shopify embed : statut, items, tracking
Tags auto : intent, sentiment, escalade_reason
Transcript repliable : détail si besoin
Champs custom ticket
`bot_intent`, `bot_escalation_reason`, `order_id`, `auth_level`, `bot_summary`. Alimentés par webhook à l'escalade. Voir données client Shopify.
Formation agent
Interdire « pouvez-vous me redonner votre numéro de commande ? » si le champ est rempli. Autoriser clarification : « Je vois la #8841, c'est bien celle-ci ? »
Comment brancher techniquement le transfert de contexte ?
Le flux technique context transfer typique en stack Shopify + helpdesk.
Séquence
Bot détecte trigger escalade
Collecte slots manquants
Génère résumé + payload JSON
Webhook → helpdesk (create/update ticket + custom fields)
Route queue (intent, langue, VIP)
Assign agent ou mise en file live
Client informé ; agent reçoit sidebar avant réponse
Latence cible
Trigger → payload packagé : < 500 ms. Payload → ticket visible agent : < 2 s. Données Shopify lues une fois, pas re-fetch manuel agent.
Échec graceful
Si webhook fail : ticket créé avec transcript minimum, alerte ops, jamais client sans réponse. eesel AI : handoff vers le vide = pire scénario.
Test de charge
Avant BFCM, simulez 50 escalades simultanées : les payloads arrivent-ils tous dans le helpdesk avec les bons custom fields ? Un goulot webhook en pic saisonnier reproduit exactement le scénario « robot puis humain perdu ».
Comment router avec le contexte vers la bonne file ?
Le routage contextuel handoff utilise intent et tags, pas seulement « support général ».
Règles routing
Logistique : WISMO, colis perdu, adresse
Retours : échange, remboursement, abîmé
Vente : pré-achat complexe, panier > seuil
Finance : chargeback, facture B2B
VIP : tag CRM + priorité file
Langue et fuseau
Route FR → équipe FR même si widget EN par erreur. Voir prioriser demandes.
Boucle retour bot
Notes agent post-résolution réinjectées en corpus pour réduire escalades répétitives sur même intent. Voir audit bot (#143).
Quels KPI mesurer la qualité du transfert de contexte ?
Mesurez le context transfer KPI en plus des KPI handoff classiques (#12).
KPI primaires
Repeat info rate : % conversations où client redonne order # ou reproche répétition
Time to first useful human reply : cible < 90 s après escalade
Payload completeness : % handoffs avec 7/7 éléments
CSAT post-handoff : corréler avec repeat info rate
Agent handle time : baisse si contexte complet
Audit hebdo
10 handoffs aléatoires : l'agent aurait-il pu répondre sans redemander ? Taguer « repeat_info » en note interne si le client reformule order # ou problème. Voir analytics conversations.
Objectif repeat info
Viser < 15 % repeat info rate en DTC mature. Au-delà de 25 %, le problème est presque toujours payload incomplet ou agent non formé à lire la sidebar, pas le bot lui-même.
Comment Qstomy transmet le contexte à l'agent humain ?
Qstomy package automatiquement transcript, résumé, commande Shopify et raison d'escalade à chaque transfert.
Fonctionnalités context transfer
Payload 7 éléments auto à l'escalade
Slots pré-handoff : collecte avant annonce transfert
Résumé agent : template 5 lignes généré
Sync helpdesk : custom fields + sidebar
Routing intent : file logistique, retour, vente
Messages client : annonce + délai + continuité fil
Scénario DTC chiffré
Marque mode 900 conv/mois, refonte payload Qstomy + Gorgias. Avant : repeat info rate 38 %, CSAT post-handoff 3,6. Après 8 semaines : repeat info 11 %, payload completeness 94 %, CSAT post-handoff 4,3, handle time agent -22 %.
Explorez support IA, Shopify, demander une démo.
Quels playbooks opérationnels pour un contexte transféré sans faille ?
Playbook 1 : définir payload (2 h)
Valider les 7 éléments section 3. Lister champs custom helpdesk. Mapper slots par intent section 4.
Playbook 2 : template résumé (1 h)
Adapter section 5. Tester sur 10 transcripts réels. Corriger hallucinations résumé.
Playbook 3 : scripts client (45 min)
Annonce, attente, hors horaires section 6. Aligner agents sur phrase d'ouverture contextualisée.
Playbook 4 : webhook + test bout en bout (2 h)
Simuler escalade produit abîmé. Vérifier ticket Gorgias : résumé, order, tags, transcript.
Playbook 5 : revue repeat info S4 (30 min)
Mesurer repeat info rate. Relire 5 pires cas. Ajouter 1 slot ou corriger 1 routing.
Maillage utile
Le client ne devrait jamais sentir deux entreprises : un bot puis un humain. Une seule conversation, un seul dossier, zéro répétition inutile.
Enzo
28 juin 2026
