E-commerce
1 juillet 2026
« Le bot met une minute à répondre, c'est normal ? » « J'ai écrit, le chatbot ne répond plus. » « Combien de temps avant qu'un humain reprenne après le bot ? » Trois tickets où les attentes délai chatbot manquent de réponse claire.
Le support délai réponse chatbot e-commerce couvre latence IA, indisponibilité, timeout conversation, délai handoff humain et heures de service bot. Distinct de délai réponse support humain (#401) : ici, le client interroge la vitesse et disponibilité du chatbot, pas le SLA agents email ou chat humain.
Ce guide #877 déploie policy CHATRT-SUP, flow CRT-1 à CRT-8 et matrice CHATRT-MAP. Paire du futur bot communication latence (#878).
Sommaire
Pourquoi les délais chatbot génèrent-ils des tickets ?
Latence LLM, file d'attente API, maintenance ou handoff lent : le client perçoit un bot lent ou muet. L'agent confond plainte chatbot avec délai support humain #401 ou promet une vitesse que l'infra ne garantit pas.
Cinq frictions typiques délai chatbot
Réponse lente : plusieurs secondes ou minutes avant message bot
Aucune réponse : message client sans retour bot
Bot indisponible : widget offline ou message erreur
Handoff lent : attente longue après demande agent humain
Attente délai annoncé : veut savoir combien de temps le bot met
Exemple retail DTC
Mode DTC, 10 tickets chatrt_/mois. Après CHATRT-MAP : chatrt_expectation_resolution_rate 87 %, répétitions latence sous 7 jours -42 %.
CHATRT #877 vs RESP #401, HANDOFF #12, FALLBACK #279 et bot #878
Cinq contenus attentes délai, cinq angles distincts côté client.
Matrice rapide
#877 CHATRT : gérer tickets latence indisponibilité timeout handoff bot
RESP #401 : délai réponse support humain email chat agent
HANDOFF #12 : règles quand transférer bot vers humain
CONTEXT #155 : transmission contexte handoff distinct vitesse
FALLBACK #279 : mode dégradé données Shopify indisponibles
Bot #878 : messages bot latence panne côté widget
#877 = pourquoi le bot est lent ? #401 = pourquoi l'agent humain met du temps.
Promesse #877
Policy CHATRT-SUP, arbre CHATRT-GATE, 8 macros, matrice latence bot versus SLA humain versus communication widget #878, KPI chatrt_expectation_resolution_rate.
Quelles typologies chatrt_* classifier ?
Classifier oriente action : slow_response ≠ no_response ≠ handoff_delay ≠ expected_time.
Huit typologies CHATRT-MAP
chatrt_slow_response : bot répond mais trop lentement
chatrt_no_response : aucune réponse bot après message
chatrt_unavailable : widget offline ou bot désactivé
chatrt_expected_time : demande délai normal de réponse bot
chatrt_handoff_delay : attente longue après escalade humain
chatrt_timeout : conversation expirée ou fermée auto
chatrt_peak_hours : lenteur perçue heure de pointe
chatrt_compare_human : attend vitesse humaine immédiate du bot
Policy CHATRT-SUP : règles agents et escalade
La policy CHATRT-SUP fixe attentes réalistes sans promettre réponse instantanée ni blâmer le client.
Six règles CHATRT-SUP
ACKNOWLEDGE-FIRST : macro CHATRT-ACKNOWLEDGE valider frustration latence
ETA documentée : CHATRT-ETA délai bot et handoff selon registre
Expliquer latence : CHATRT-EXPLAIN-LATENCY facteurs sans jargon infra
Alternative si down : CHATRT-ALTERNATIVE email formulaire si indisponible
Handoff distinct : chatrt_handoff_delay renvoi SLA humain #401 si applicable
Incident → ops : chatrt_no_response récurrent escalate technique
Matrice situation (agent)
Latence normale : EXPLAIN-LATENCY + ETA
Bot down : UNAVAILABLE + ALTERNATIVE
Handoff lent : HANDOFF-ETA + handoff #401 si agent lent
Timeout : EXPLAIN timeout + rouvrir chat
Flow CRT-1 à CRT-8 : résolution standard
Huit étapes séquentielles, SLA P3 chatrt < 24 h réponse attente, escalate ops si no_response récurrent.
Flow CRT-1 à CRT-8
CRT-1 Triage : lire plainte, tag chatrt_*, bot ou humain #401 ?
CRT-2 Lookup : logs conversation, latence mesurée, statut bot incident
CRT-3 Educate : ETA si expected_time, distinguer bot versus agent
CRT-4 Classify : chatrt_* via CHATRT-MAP
CRT-5 Execute : ACKNOWLEDGE, ETA, EXPLAIN, ALTERNATIVE, ESCALATE ops
CRT-6 Confirm : macro CHATRT-DONE attente et prochaine étape
CRT-7 Test : client comprend délai normal ou alternative
CRT-8 Close : KPI chatrt_expectation_resolution_rate
Huit macros CHATRT-* prêtes à coller
Macros alignées registre délais chatbot et handoff interne.
Bibliothèque CHATRT-*
CHATRT-ACKNOWLEDGE : « Nous comprenons que l'attente du chatbot soit frustrante. Merci de nous l'avoir signalé. »
CHATRT-ETA : « Délai habituel réponse bot : {{délai}}. Handoff humain : {{délai_handoff}} si demandé. »
CHATRT-EXPLAIN-LATENCY : « Un délai de quelques secondes est normal. Pic de trafic ou question complexe peut allonger l'attente. »
CHATRT-UNAVAILABLE : « Le chatbot est temporairement indisponible. Raison : {{statut}}. »
CHATRT-ALTERNATIVE : « Contactez-nous par {{canal}} en attendant : {{lien}}. »
CHATRT-HANDOFF-ETA : « Après demande agent, délai habituel : {{délai}}. Référence conversation : {{id}}. »
CHATRT-ESCALATE : « Signalement transmis à l'équipe technique. Mise à jour sous {{SLA}}. »
CHATRT-DONE : « Récap : {{situation}}. Attente normale : {{délai}}. Alternative : {{canal}}. »
Arbre CHATRT-GATE et registre délais agent-ready
Arbre décision avant promesse réponse instantanée ou confusion SLA humain.
CHATRT-GATE
Bot lent seulement ? → EXPLAIN-LATENCY + ETA
Bot muet ou down ? → UNAVAILABLE + ALTERNATIVE + ESCALATE si incident
Handoff humain lent ? → HANDOFF-ETA + handoff RESP #401 si agent
Demande délai normal ? → ETA registre
Problème métier SAV ? → résoudre SAV pas CHATRT seul
Registre interne minimum
Documenter helpdesk : ETA bot P50 P95, délai handoff, heures service bot, canal alternative, procédure incident. Former agents : latence bot ≠ délai agent #401.
KPI, QA et handoff vers bot #878
Mesurer CHATRT détecte sur-promesse vitesse et mauvais silo SLA humain.
Quatre KPI CHATRT
chatrt_expectation_resolution_rate : client comprend délai / total
chatrt_wrong_silo_rate : % routés #401 à tort seul pour latence bot
chatrt_eta_given_rate : % tickets avec ETA ou EXPLAIN tracé
chatrt_repeat_7d : même plainte latence sous 7 jours
Handoff bot #878
Exporter CHATRT-MAP vers messages widget latence panne. Guardrail CHATRT-WIDGET-ETA : afficher attente proactive avant frustration ticket.
Cas limites : mobile lent, LLM timeout, heures fermées
Trois cas hors flow standard.
Connexion mobile lente
EXPLAIN-LATENCY réseau client possible. Pas blâmer infra seule.
Timeout LLM ou API
UNAVAILABLE + ESCALATE ops. ALTERNATIVE immédiate.
Hors heures bot actif
ETA heures service + ALTERNATIVE email. Distinction bot off versus lent.
Formation agents : 20 minutes CHATRT
Module : latence bot ≠ SLA humain, ACKNOWLEDGE systématique, ETA registre, ALTERNATIVE si down, HANDOFF-ETA distinct.
Exercices
Ticket A : bot lent 30 s → EXPLAIN-LATENCY + ETA pas excuse vide
Ticket B : bot ne répond plus → UNAVAILABLE + ALTERNATIVE + ESCALATE
Ticket C : agent humain lent après bot → handoff RESP #401 pas CHATRT seul
Comment Qstomy structure CHATRT dans votre stack
Qstomy route chatrt_*, affiche métriques latence P95 agent et brief #878 pour messages widget proactive.
Trois briques
Routing : intent chatbot_latency vs human_response_time vs sav_issue
Latency dashboard : sync macros CHATRT-* ETA incident statut
Bot #878 : communiquer latence panne côté widget
Scénario : retail DTC, pic Black Friday. Bot #878 message attente proactive, agents CHATRT ETA. chatrt_expectation_resolution_rate passe de 58 % à 85 % en 3 semaines.
FAQ et checklist déploiement CHATRT
FAQ
Le bot doit répondre instantanément ?
Non. EXPLAIN-LATENCY quelques secondes normal. ETA honnête.
Différence #401 ?
#877 = vitesse chatbot. #401 = délai réponse support humain.
Différence #878 ?
#877 = agents gérer tickets attente. #878 = messages bot widget latence panne.
Checklist 7 jours
J1 : CHATRT-SUP + CHATRT-MAP + registre ETA bot handoff
J2 : 8 macros helpdesk
J3 : matrice routage #401 #12 #279
J4 : formation 20 min agents
J5 : tags chatrt_* + KPI
J6 : test UNAVAILABLE vs EXPLAIN-LATENCY
J7 : brief bot #878 WIDGET-ETA-GATE
Maillage
Enzo
1 juillet 2026
