IOSOR Guide
SMS in entrata e messaggistica bidirezionale: inbox che prodotto e supporto possono gestire
Come i team B2B gestiscono risposte ed eventi chiamata su numeri noleggiati — proprietà inbox, keyword, invio+ricezione collegati, webhook MO, privacy e prepaid onesto.
L'SMS in uscita è solo metà di un prodotto di messaggistica serio. Nel momento in cui un cliente può rispondere — o un DID noleggiato inizia a ricevere eventi di chiamata — serve un percorso inbound che prodotto, supporto e compliance possano difendere. La messaggistica bidirezionale non è «attivare MO e sperare». È un sistema operativo: chi possiede l'inbox, quali numeri ricevono e inviano, dove atterrano i webhook e cosa potete archiviare legalmente.
Questa guida è per team B2B che noleggiano numeri business per supporto, fallback OTP, callback e traffico conversazionale — e rifiutano di operare il quotidiano dentro il portale di marca di terzi.
Cosa include davvero «inbound»
Per la maggior parte degli acquirenti CPaaS prepaid, inbound significa più di un interruttore verde:
| Segnale | Per
Progettate il percorso inbox prima di comprare numeri
Prodotto e supporto devono concordare un unico modello operativo di inbox prima del primo noleggio DID:
Collegate numeri per ricevere + inviare (stessa identità commerciale)
Il two-way si rompe quando ricezione e invio sono trattati come SKU scollegati.
Keyword che il supporto spiega in una frase
Le keyword sono policy, non simpatici autoresponder.
Set minimo per la maggior parte dei team:
- STOP / disiscrizione — onorare opt-out prontamente; registrarlo per audit.
- HELP / info — rispondere con percorso di aiuto pulito orientato al brand (orari, canale, escalation).
- Comandi campagna o locale — solo se prodotto e legal hanno approvato il testo.
Red flag che devono fermare un rollout inbound
- Le risposte quotidiane richiedono login nel portale di marca di terzi
- I numeri possono inviare ma i webhook inbound sono «fase due»
- Testo STOP / HELP indefinito o modificabile da chiunque
- «Activated» mentre la capacità di ricezione resta non provata
- Archiviazione corpi inbound senza policy di retention o accesso
- Catalogo dichiara «2-way global» mentre i paesi target restano in setup
Iniziare con IOSOR
Letture: loop di auto-reply inbound Buffer dei webhook inbound contro i picchi di latenza degli operatori riserva prepagata prima del primo addebito.
Sintesi IOSOR
Il bidirezionale è un inbox che si può presidiare. Ricevere e inviare condividono un’identità di numero.
Fate: provate che una risposta atterra in un inbox presidiato. Non fate: vendere il bidirezionale come un interruttore su un From a senso unico.
Questa guida ti è stata utile?
Guide correlate
- Configurazione del fallback per chiamate vocali in entrata verso SMS
Scopri come configurare trigger SMS automatici per chiamate vocali in entrata perse e segnali di occupato all'interno della console CPaaS white-label di IOSOR.
- Buffer dei webhook inbound contro i picchi di latenza degli operatori
Scopri come configurare le regole di buffering inbound di IOSOR per proteggere i tuoi webhook dai ritardi di consegna, dai picchi di concorrenza e dagli errori di timeout upstream.
- Sincronizzazione delle parole chiave di opt-in e opt-out tra account multi-tenant
Padroneggia la sincronizzazione dell'opt-out multi-tenant in IOSOR. Scopri come le parole chiave STOP gestiscono la soppressione globale isolando i sub-account.