IOSOR

IOSOR Guide

Loop di auto-risposta inbound: come l’eco svuota il wallet prepagato

Come i team B2B tengono l’SMS bidirezionale onesto — STOP/HELP come policy, tetti di auto-risposta, disciplina del webhook inbound e perché l’eco senza limite brucia il prepagato.

Un’auto-risposta inbound che risponde sempre non è «grande CX». Su un DID affittato è una perdita prepagata: due bot o un HELP che cita l’originale possono rimbalzare fino a svuotare il wallet. Product vede engagement. Finance vede un buco. Ops eredita un incidente alle 02:00 senza owner.

IOSOR tiene inbound sulla stessa superficie prepagata white-label dell’outbound: eventi MO, risposte keyword e righe di addebito vivono nel tuo account. Vicino a USD 1,000+ di uso mensile, campioni di loop e addebito per thread diventano materia di revisione commerciale. Catalogo live senza tetto di loop è una promessa che finance non difende.

I loop di auto-risposta svuotano il prepagato

Pattern Come appare Effetto wallet
Eco bot ↔ bot Due auto-ack rimbalzano Addebito outbound senza tetto
HELP che cita inbound Il payload esce come nuovo invio Segmenti duplicati
Ping-pong fuori orario «Abbiamo ricevuto l’SMS» a ogni retry Bruciatura notturna senza umano
Tempesta retry webhook Lo stesso MO due volte Doppia risposta, doppio addebito

I retry inbound succedono. Senza idempotenza ogni retry webhook diventa un’altra auto-risposta. Vedi retry dei webhook inbound. Abbina il rilevamento loop a stop per saldo basso perché il wallet fermi gli echi restanti. Un ID di correlazione deve andare dall’inbound all’addebito.

STOP/HELP contro l’eco senza limite

STOP e HELP sono policy, non bot carini. STOP deve onorare l’opt-out e fermare il thread — auto-risposte comprese. HELP deve essere un percorso breve e brand-safe con orari veri, non un eco dell’ultima frase. Un «abbiamo ricevuto l’SMS» senza limite su ogni MO non è HELP. Scrivi la pagina keyword prima del primo invio conversazionale; vedi policy delle parole STOP e HELP. Se STOP «di solito funziona», hai fortuna, non una policy.

Tetti che product e finance possono difendere

  1. Tetto outbound per thread — max auto-risposte per DID + id cliente e finestra.
  2. Gestione MO idempotente — un evento inbound, una risposta, anche se il webhook ritenta.
  3. Silenzio dopo STOP — né marketing, né «sei sicuro», né secondo HELP.
  4. Halt a saldo basso — il resto delle auto-risposte si ferma prima del teatro di scoperto.

Esporta un incidente: evento inbound → auto-risposta → riga ledger. Senza quella catena non hai controllo bidirezionale. Nomina un owner del tetto.

Onestà della inbox bidirezionale

Il bidirezionale è un sistema operativo, non un interruttore. Chi legge per primo, quali numeri ricevono e inviano, cosa non cade mai in un canale condiviso, come funzionano le ore morte. Vedi guida alla casella inbound bidirezionale e eventi inbox su numeri a noleggio. JIT è cerca → trattieni → compra → assegna. Il catalogo in setup non si vende come inbox con personale.

Segnali di allarme

  • Auto-risposta senza tetto per thread
  • HELP che ripete il payload inbound
  • STOP che spara ancora un ack marketing
  • Retry webhook che inviano risposte doppie
  • Catalogo live senza owner del loop
  • Errori che riversano brand esterni
  • Eco fuori orario senza percorso umano

Inizia con IOSOR

Scrivete testi STOP e HELP che il supporto possa leggere ad alta voce. Mettete un tetto di auto-risposta per thread in staging, forzate un webhook MO duplicato e confermate che il wallet vede una risposta, non due. Simulate un’eco di bot finché la spesa si ferma. Esportate una catena inbound → addebito perché finance veda dove il ciclo avrebbe svuotato il saldo prepaid.

Sintesi IOSOR

Un’eco inbound è un incendio di wallet.

Questa guida ti è stata utile?

Guide correlate