E-commerce
1 juillet 2026
« J'ai écrit il y a 48 h, toujours pas de réponse. » « Vous promettez réponse sous 2 h sur le chat, personne ne répond. » « C'est normal d'attendre 5 jours un remboursement ? » Trois messages où le client ne demande pas une résolution métier, mais une explication sur le délai de réponse du support.
Le support questions délai réponse e-commerce aligne promesses publiques, SLA internes et réponses agents quand le client attend une réaction humaine. Sans policy, chaque ticket « pourquoi pas de nouvelles » devient excuse vague ou sur-promesse.
Ce guide #401 couvre policy RESP-COMM, flow RESP-FLOW et KPI resp_wait. Il se distingue du SLA interne (#101) (définition opérationnelle FRT) et du futur bot horaires (#402) : ici, communication client et gestion SAV des attentes délai réponse.
Sommaire
Pourquoi les questions délai réponse surchargent-elles le SAV ?
Un ticket délai réponse support arrive quand le client n'a pas reçu de nouvelles depuis sa demande initiale, ou compare votre délai à une promesse affichée.
Cinq frustrations client typiques
Silence perçu : email J+2 sans auto-reply ni update
Promesse widget : « réponse 2 min » mais queue humaine pleine
Confusion résolution : délai remboursement ≠ délai réponse
Week-end oublié : message vendredi soir, attente lundi
Double canal : relance Instagram + email, aucune sync
Eightx place le FRT email leaders e-commerce à 1-2 h, moyenne industrie 8-12 h (Eightx, résolution canal 2026). HubSpot rappelle que 90 % des clients attendent une réponse immédiate au chat (HubSpot, service client 2026).
Angle #401 vs contenus voisins
SLA interne #101 : grille FRT ops, config Gorgias. Le #401 = communication client et tickets « pourquoi pas de réponse ».
Bot horaires #402 : futur automation disponibilité. Le #401 = process agents et touchpoints promesse.
Week-end #403 : couverture hors heures. Le #401 = expliquer délai quand équipe absente.
Remboursement #370 : statut refund processor. Le #401 = délai première réponse support, pas délai banque.
Handoff bot : attente agent post-bot. Le #401 = promesse et suivi pendant attente humaine.
Exemple DTC
Marque mode, widget « réponse sous 4 h », 78 tickets resp_wait/mois. Après RESP-COMM + RESP-FLOW : resp_wait_fcr 84 %, resp_expectation_miss -43 %, resp_followup_ticket_rate -38 %.
Volume typique resp_wait
3 à 12 % tickets inbound sont des relances délai réponse ou confusion FRT. Auto-reply + bot tier 0 réduit de moitié.
En quoi délai réponse diffère-t-il de délai résolution ?
Le client mélange souvent first response et resolution time. Deux promesses, deux réponses support.
Matrice délai → message client
FRT (#401 focus) : délai première réponse substantielle
Résolution : délai clôture ticket (retour, refund, investigation)
Processor delay : délai banque post-refund approuvé
Carrier delay : transit colis, pas support
Formule attente client
« Nous avons bien reçu votre message. Première réponse sous {{frt_promise}}. Résolution estimée : {{resolution_promise}} selon nature demande. » Deux lignes distinctes en macro RESP-ACK.
Canal et FRT
Chat bot : < 30 s tier 0. Chat humain : pickup < 2 min. Email : 4-24 h ouvrées selon #101. DM Instagram : < 60 min si promis.
Promesse #401
Policy RESP-COMM, typologies resp_wait_*, flow RESP-FLOW, touchpoints widget/auto-reply, macros RESP-*, KPI resp_wait.
Quelles typologies resp_wait_* cartographier ?
Douze typologies tickets délai réponse pour routing cohérent.
Douze scénarios resp_wait
resp_wait_email_early : J+0/J+1 email dans SLA normal
resp_wait_email_sla_exceeded : email hors délai promis
resp_wait_chat_queue : chat humain, attente > 2 min
resp_wait_chat_offline : message hors heures ouvrées
resp_wait_bot_handoff_pending : bot a escaladé, agent pas encore pris
resp_wait_followup_same_ticket : relance « toujours pas de nouvelles »
resp_wait_cross_channel : écrit email + Instagram, confusion
resp_wait_weekend_gap : message ven-sam, attente lundi
resp_wait_peak_backlog : BFCM, délai allongé annoncé
resp_wait_resolution_confusion : confond FRT et délai refund
resp_wait_vip_expectation : client VIP, attente prioritaire
resp_wait_threat_chargeback : menace si pas réponse rapide
Tags helpdesk
resp_wait, resp_sla_ok, resp_sla_miss, resp_followup, resp_off_hours. Distinct wismo, refund_status, complaint.
Données intake RW-1
ticket_id original, channel, created_at, last_agent_reply_at, hours_since_last_reply, sla_status Gorgias, business_hours flag, customer_verbatim.
Comment rédiger la policy RESP-COMM en huit règles ?
La policy communication délai réponse RESP-COMM documente promesses publiques et réponses agents alignées SLA #101.
Huit règles RESP-COMM
Promesse publique = SLA tenu 90 %+ : marge sécurité widget/page contact
Auto-reply immédiat : email/DM accuse réception + FRT estimé + ticket #
Distinction FRT / résolution : toujours deux délais en macro
Hors heures : message bot + retour équipe {{next_open}} explicite
Update proactive : si résolution > 48 h, message intermédiaire client
Peak communication : banner + widget si FRT email x2 (BFCM)
Pas sur-promesse chat : « 2 min » seulement si median pickup < 2 min 80 %+
Escalade resp_sla_miss : supervisor répond sous 2 h si breach confirmé
Publication touchpoints
Widget chat : « Réponse habituelle sous X min/h · Bot 24/7 ». Page /contact : tableau canal → délai FRT. Footer email : lien statut ticket.
Alignement #101
Promesse publique email « sous 24 h ouvrées » si SLA interne 8 h. Jamais afficher SLA interne brut au client.
Interdit RESP-COMM
« Réponse instantanée » email. « 24/7 humain » si bot seul la nuit. Blâmer client pour relance.
Page contact template
Tableau : Chat bot 24/7 instant · Chat humain lun-ven 9-18h réponse ~5 min · Email réponse sous 24 h ouvrées · Instagram DM sous 4 h ouvrées.
Comment appliquer le flow RESP-FLOW en huit étapes ?
Le framework RESP-FLOW structure réponse tickets délai réponse.
Huit étapes RW-1 à RW-8
RW-1 Intake : ticket_id, verbatim, typologie resp_wait_*
RW-2 Lire ticket original : created_at, channel, tags, dernière réponse
RW-3 Vérifier SLA Gorgias : dans SLA | breach | off_hours | pending agent
RW-4 Classifier : early OK | sla_miss | confusion resolution | cross_channel
RW-5 Répondre substance : traiter demande initiale SI pas encore fait
RW-6 Expliquer délai : macro RESP-* grounded RW-3 data
RW-7 Escalader : sla_miss confirmé, VIP, chargeback threat
RW-8 Documenter : note ticket, tag resp_*, update proactive planifiée
RW-5 règle critique
Ticket resp_wait souvent symptôme : demande initiale non traitée. RW-5 résout le fond (retour, WISMO) AVANT ou AVEC explication délai RW-6.
RW-4 arbre décision
dans SLA + early → RESP-OK-01 rassurance
sla_miss → RESP-MISS-01 excuse + traitement prioritaire
off_hours → RESP-OFF-01 prochain créneau
resolution confusion → RESP-RES-01 FRT vs refund
handoff pending → RESP-HAND-01 statut queue
SLA réponse resp_wait
Ticket resp_wait : première réponse agent 2 h. sla_miss confirmé : supervisor 1 h.
RW-3 Gorgias SLA check
Sidebar agent : SLA clock vert/rouge. RESP-FLOW cite statut grounded, pas impression agent sur délai.
Quelles macros RESP-* pour les agents ?
Dix macros agents délai réponse couvrent 90 % des tickets resp_wait.
RESP-ACK-01 (accusé réception email)
« Merci {{first_name}}. Message #[ticket_id] reçu le [date]. Première réponse sous [frt_promise]. Résolution selon demande : [resolution_hint]. Suivi : [lien ticket status]. »
RESP-OK-01 (dans SLA, early)
« Votre demande #[X] est en cours de traitement. Délai habituel première réponse : [frt]. Un agent vous répond sous [ETA]. Merci de votre patience. »
RESP-MISS-01 (SLA dépassé)
« Nous sommes désolés du délai supérieur à notre engagement. Votre demande est priorisée. Réponse complète sous 4 h ouvrées. Ticket #[X] assigné. »
RESP-OFF-01 (hors heures)
« Équipe disponible lun-ven 9 h-18 h (Paris). Bot actif 24/7 pour suivi commande. Prochaine réponse agent : lundi 9 h. Numéro ticket #[X] enregistré. »
RESP-RES-01 (confusion résolution)
« Remboursement approuvé le [date]. Délai banque 5-10 j ouvrés. Distinct du délai réponse support : nous avons répondu le [agent_reply_date]. »
Autres macros
RESP-HAND-01 : handoff bot, agent sous 15 min ou ETA queue
RESP-PEAK-01 : BFCM délai allongé, update proactive
RESP-CROSS-01 : fusionner canaux, un seul ticket
RESP-VIP-01 : priorité queue, FRT 1 h
RESP-UPDATE-01 : message intermédiaire investigation longue
Règles macros
Toujours citer ticket # et FRT grounded #101. Jamais blâmer client relance. RW-5 fond traité avant RESP-OK seul.
Quels touchpoints configurer pour les attentes client ?
Les touchpoints promesse délai réponse préviennent tickets resp_wait en amont.
Sept touchpoints RESP-COMM
Widget chat : FRT median + « bot disponible maintenant »
Page /contact : tableau canal, délai, horaires
Auto-reply email : RESP-ACK-01 template Gorgias
Offline chat message : RESP-OFF-01 hors heures
Handoff bot message : ETA agent + ticket #
Peak banner site : FRT email x2 période forte affluence
Ticket status page : client voit dernière réponse, pas besoin relancer
Widget chat calibration
Mesurer median pickup 30 j. Afficher P80 arrondi + marge. Si queue > 5 min : message dynamique « attente actuelle ~X min ».
Auto-reply obligatoire
100 % emails entrants reçoivent RESP-ACK sous 5 min bot/rule. Réduit resp_wait_email_early de 40-60 %.
Self-service lien
Auto-reply inclut lien WISMO bot #184, portail retour, FAQ. Aligner self-service (#28).
Instagram DM
Meta auto-reply + numéro ticket si routé Gorgias. Évite resp_wait_cross_channel.
Ticket status portal
Gorgias Help Center ou page branded : client voit statut sans email relance. Réduit resp_followup_ticket_rate 25-35 %.
Comment gérer peak, VIP et menaces chargeback ?
Trois edge cases délai réponse exigent playbooks RESP-COMM dédiés.
Peak BFCM
Doubler FRT email affiché widget. RESP-PEAK-01 macro. Update proactive J+2 si investigation longue. Aligner plan BFCM.
VIP queue
Tag Shopify VIP → queue Gorgias prioritaire. RESP-VIP-01. FRT interne 1 h, communication client « priorité traitement ». Voir escalade VIP.
Menace chargeback resp_wait
resp_wait_threat_chargeback : supervisor sous 1 h, traiter fond + RESP-MISS. Pas promesse refund pour accélérer réponse seule.
Bot handoff attente
RESP-HAND-01 : « Agent assigné, réponse sous [ETA]. Résumé transmis : [intent]. » Aligner handoff bot.
Investigation > 72 h
RESP-UPDATE-01 automatique J+2 et J+4 : « Enquête en cours, update [date]. » Réduit resp_followup_same_ticket.
Quels KPI resp_wait mesurer ?
Les KPI délai réponse communication lient promesse publique et satisfaction.
Huit métriques clés
resp_wait_ticket_rate : tickets resp_wait / total inbound
resp_wait_fcr : résolu sans réouverture 72 h
resp_expectation_miss_rate : client cite promesse non tenue
resp_followup_ticket_rate : relances « toujours pas de nouvelles »
auto_reply_coverage : % emails avec ACK < 5 min
public_promise_accuracy : widget FRT vs median réel 90 j
resp_sla_miss_recovery_time : délai post RESP-MISS
resp_wait_csat : satisfaction post RESP-FLOW
Benchmark DTC
resp_wait_ticket_rate 3-8 % inbound, resp_wait_fcr 80-88 %, resp_expectation_miss < 2 %, auto_reply_coverage 98 %+, public_promise_accuracy écart < 15 % widget vs réel.
Dashboard hebdo
Top typologies resp_wait_*, corrélation sla_miss Gorgias, resp_wait vs CSAT global, widget promise vs median pickup.
Alerte ops
resp_expectation_miss > 5 % : revue widget/page contact sous 48 h.
Corrélation CSAT
Tickets resp_wait ont CSAT 0,6 pt sous moyenne si RW-5 fond non traité. RW-5 + RESP-OK combo restore CSAT.
Quels anti-patterns éviter sur les délais réponse ?
Dix anti-patterns communication délai réponse à bannir.
1. Widget « réponse instantanée » email
Promesse impossible. Client cite en ticket resp_wait.
2. Répondre délai sans traiter fond RW-5
Client relance J+1. Double ticket.
3. Blâmer client « vous avez déjà écrit »
Ton CSAT killer. RESP-MISS empathie obligatoire.
4. Confondre FRT et délai refund
RESP-RES-01 systématique si tag refund pending.
5. Pas auto-reply email
Silence 24 h = resp_wait évitable.
6. SLA #101 public brut
« FRT 4 h » interne ≠ promesse client 24 h marge.
7. Chat offline sans message bot
Client pense ignoré. RESP-OFF-01 widget obligatoire.
8. Ignorer cross_channel
Fusionner tickets, une réponse cohérente.
9. Peak sans banner widget
resp_expectation_miss spike BFCM.
10. Handoff bot sans ETA
Client attend infini. RESP-HAND-01 avec queue position si possible.
Comment Qstomy réduit les tickets délai réponse ?
Qstomy sur Shopify : bot 24/7 tier 0, handoff ETA agent, auto-ACK chat, corpus RESP-COMM, routing VIP/chargeback prioritaire.
Capacités resp_wait Qstomy
resp_bot_tier0 : FRT < 30 s WISMO, retour, pré-achat
resp_handoff_eta : message RESP-HAND grounded queue
resp_off_hours : RESP-OFF template + bot actif
resp_ticket_status_link : client self-check sans relancer
resp_vip_route : queue prioritaire Shopify tag
Complément #101 et futur #402
SLA #101 = ops interne. Qstomy compresse FRT tier 0. Futur bot #402 horaires automatise RESP-OFF. #401 = macros agents resp_wait.
Scénario DTC chiffré
Marque mode, 420 tickets/mois, resp_wait 12 % inbound.
Après RESP-COMM + Qstomy : resp_wait_ticket_rate 4,2 %, resp_wait_fcr 86 %, auto_reply_coverage 99 %, median FRT email 2,1 h, resp_wait_csat 4,3/5.
Explorez support client et demander une démo.
Quelle checklist pour déployer RESP-COMM ?
Checklist RESP-COMM (12 étapes)
Auditer SLA interne #101 vs promesses publiques actuelles
Rédiger policy 8 règles RESP-COMM
Documenter 12 typologies resp_wait_* section 3
Créer 10 macros RESP-* Gorgias
Configurer auto-reply RESP-ACK-01 100 % emails
Calibrer widget chat FRT grounded median 30 j
Publier page /contact tableau délais canal
Former agents RESP-FLOW RW-1 à RW-8 (30 min)
Activer RESP-UPDATE proactive investigation > 72 h
Peak playbook RESP-PEAK + banner
Dashboard KPI resp_wait hebdo
Aligner futur bot horaires #402 roadmap
En bref
#401 = communication délai réponse client, pas SLA ops (#101)
RESP-FLOW : vérifier SLA → traiter fond → expliquer délai
Distinction FRT / résolution : deux promesses macros
Touchpoints : widget, auto-reply, offline, peak banner
KPI resp_wait_fcr : cible 80-88 %
FAQ
Différence avec #101 ?
#101 définit SLA interne FRT par catégorie. #401 gère tickets client « pourquoi pas de réponse » et promesses publiques.
Que promettre sur le widget chat ?
Median pickup P80 + marge. Bot 24/7 distinct humain. Jamais « instantané » si queue > 2 min fréquent.
Relation refund délai ?
#401 = délai réponse support. Délai banque = RESP-RES-01 ou #370 refund statut.
Relation #402 bot horaires ?
#402 automatise offline/holidays. #401 = policy et macros agents resp_wait.
Client relance 3 fois ?
RW-5 traiter fond, RW-7 escalade supervisor, RESP-MISS si sla_miss confirmé.
Aller plus loin
Cette semaine : comparez promesses widget et page contact au median FRT 30 j Gorgias. Écart > 20 % : recalibrer RESP-COMM règle 1 avant prochain pic volume.
Partagez ce guide #401 avec support et marketing : une promesse délai tenue vaut mieux qu'une réponse rapide promise et ratée.
Enzo
1 juillet 2026
