IOSOR

IOSOR Guides

Boucles d’auto-réponse inbound : comment l’écho vide le portefeuille prépayé

Comment les équipes B2B gardent le SMS bidirectionnel honnête — STOP/HELP comme politique, plafonds d’auto-réponse, discipline du webhook inbound, et pourquoi l’écho sans limite brûle le prépayé.

Une auto-réponse inbound qui répond toujours n’est pas « une super CX ». Sur un DID loué c’est une fuite prépayée : deux bots, ou un HELP qui cite l’original, peuvent rebondir jusqu’à vider le portefeuille. Le produit voit de l’engagement. La finance voit un trou. Ops hérite d’un incident à 02h00 sans owner.

IOSOR garde l’inbound sur la même surface prépayée white-label que l’outbound : événements MO, réponses mots-clés et lignes de débit vivent dans votre compte.

Les boucles d’auto-réponse vident le prépayé

Motif À quoi ça ressemble Effet portefeuille
Écho bot ↔ bot Deux auto-ack rebondissent Débit outbound sans plafond
HELP qui cite l’inbound La charge part en nouvel envoi Segments doublons
Ping-pong hors horaires « Nous avons reçu le SMS » à chaque retry Brûlure nocturne sans humain
Tempête de retry webhook Le même MO deux fois Double réponse, double débit

Les retries inbound arrivent. Sans idempotence, chaque retry webhook devient une autre auto-réponse. Voir retries du webhook inbound. Couplez la détection de boucle à arrêts sur solde bas pour que le portefeuille arrête les échos restants. Un ID de corrélation doit aller de l’inbound au débit.

STOP/HELP contre l’écho sans limite

STOP et HELP sont une politique, pas des bots mignons. STOP doit honorer l’opt-out et arrêter le fil — y compris les auto-réponses. HELP doit être un chemin court, brand-safe, avec de vrais horaires, pas un écho de la dernière phrase. Un « nous avons reçu le SMS » sans limite sur chaque MO n’est pas HELP. Rédigez la page mots-clés avant le premier envoi conversationnel ; voir politique STOP et HELP. Si STOP « marche souvent », vous avez de la chance, pas une politique.

Plafonds que produit et finance peuvent défendre

  1. Plafond outbound par fil — max d’auto-réponses par DID + id client et fenêtre.
  2. Traitement MO idempotent — un événement inbound, une réponse, même si le webhook réessaie.
  3. Silence après STOP — ni marketing, ni « êtes-vous sûr », ni second HELP.
  4. Arrêt solde bas — le reste des auto-réponses s’arrête avant le théâtre de découvert.

Exportez un incident : événement inbound → auto-réponse → ligne de ledger. Sans cette chaîne, pas de contrôle bidirectionnel. Nommez un owner du plafond.

Honnêteté de la boîte bidirectionnelle

Le bidirectionnel est un système d’exploitation, pas un interrupteur. Qui lit en premier, quels numéros reçoivent et envoient, ce qui ne tombe jamais dans un canal partagé, comment fonctionnent les heures mortes. Voir guide de la boîte inbound bidirectionnelle et événements inbox sur numéros loués. JIT : chercher → retenir → acheter → assigner. Le catalogue in setup ne se vend pas comme une boîte staffée.

Signaux d’alerte

  • Auto-réponse sans plafond par fil
  • HELP qui répète la charge inbound
  • STOP qui déclenche encore un ack marketing
  • Retries webhook qui double-envoient
  • Catalogue live sans owner de boucle
  • Erreurs qui déversent des marques étrangères
  • Écho hors horaires sans chemin humain

Commencer avec IOSOR

Rédigez les textes STOP et HELP que le support peut lire à voix haute. Posez un plafond d’auto-réponse par fil en staging, forcez un webhook MO en double et confirmez que le portefeuille voit une réponse, pas deux. Simulez un écho de bot jusqu’à l’arrêt de la dépense. Exportez une chaîne inbound → débit pour que la finance voie où la boucle aurait vidé le solde prepaid.

À retenir — IOSOR

Un écho inbound est un incendie de portefeuille.

Ce guide vous a-t-il aidé ?

Guides associés