lla domanda "come inviare SMS su larga scala?", esistono due risposte concrete, che coinvolgono team diversi. La prima prevede l'utilizzo di una console web per la gestione delle campagne, mentre la seconda si basa su API integrata nel proprio software. Entrambe inviano lo stesso messaggio tramite le stesse connessioni dell'operatore; la differenza sta in chi si occupa dell'invio e nel momento in cui il messaggio viene inviato. La scelta migliore dipende principalmente da chi gestisce l'invio: una persona con una lista di contatti o un'applicazione che reagisce a un evento.
La console: invio eseguito da persone
Una piattaforma per l'invio massivo SMS è un'applicazione web. Accedi, carica o seleziona un elenco di contatti, scegli un ID mittente, scrivi il messaggio (spesso utilizzando un modello salvato), quindi invialo immediatamente o programmane l'invio. I report vengono visualizzati nella stessa schermata: consegnati, non riusciti, in sospeso, disiscrizioni. Non c'è nulla da sviluppare.
Questa soluzione è ideale per i team di marketing e operations che inviano messaggi in blocco e ragionano per campagne: una promozione, un promemoria di un evento, una comunicazione a un segmento specifico. Il vantaggio principale è la possibilità di raggiungere un vasto pubblico senza dover ricorrere a tecniche di programmazione. Chi conosce il pubblico può comporre, targettizzare e misurare un messaggio in pochi minuti, e ripeterlo la settimana successiva senza dover aprire un ticket.
L' API: invio eseguito dal software
API invio massivo SMS è un'interfaccia di programmazione, in genere REST su HTTPS o SMPP per connessioni ad alta velocità, che la tua applicazione utilizza per inviare un messaggio. Invece di un utente che clicca su "invia", è il tuo codice a farlo in risposta a un evento: un ordine spedito, un codice monouso necessario per l'accesso, un appuntamento per il giorno successivo, un pagamento non andato a buon fine.
Questa soluzione è ideale per sviluppatori e team di prodotto. Il messaggio diventa parte di un flusso anziché una semplice voce in un calendario. Si invia un messaggio a una persona specifica, esattamente al momento giusto, migliaia di volte al giorno, senza che nessuno controlli lo schermo. I messaggi transazionali e quelli attivati da eventi, come codici, conferme e avvisi, trovano qui la loro collocazione ideale, poiché sono definiti da tempistiche e contesto, non da un elenco predefinito.
L'impianto idraulico è condiviso da entrambi
In sostanza, la console e l' API si basano sullo stesso meccanismo, ed è utile sapere cosa aspettarsi da entrambe:
- I contatti e gli elenchi vengono gestiti e caricati nella console; tramite API vengono solitamente inviati o referenziati tramite ID.
- I modelli sono corpi di messaggio riutilizzabili con variabili, quindi "Ciao {nome}, il tuo codice è {codice}" viene visualizzato per ogni destinatario attraverso entrambe le porte.
- Le conferme di consegna (DLR) sono la conferma da parte dell'operatore che un messaggio ha raggiunto il dispositivo. La console le visualizza come stato; l' API le restituisce tramite callback o polling, in modo che il sistema possa reagire.
- A ogni percorso si applicano limiti di velocità e di throughput. Una console gestisce le prestazioni della campagna; tramite API, puoi gestire la concorrenza e rimanere entro i limiti del tuo account.
- La funzionalità di reporting consiste in una dashboard nella console e in record grezzi trasmessi tramite API, che è possibile archiviare e analizzare insieme ai propri dati.
Il punto è che l' API e la console sono due porte d'accesso a un unico livello di distribuzione: stesso instradamento, stessa copertura, stessa gestione del consenso e delle opzioni di disattivazione.
Quando hai bisogno di entrambi
La maggior parte delle organizzazioni finisce per usarle entrambe, e nella maggior parte dei casi è la soluzione giusta. Lo schema è chiaro: l' API gestisce il traffico transazionale generato dall'applicazione (codici, ricevute, avvisi), mentre la console gestisce le campagne gestite manualmente dal team di marketing. Stesso account, stesse identità del mittente, stessi report, due interfacce adatte a due tipi di lavoro.
Dividere i compiti in questo modo permette anche di assegnare le responsabilità a chi di dovere. Gli sviluppatori non vengono coinvolti in ogni invio promozionale e i responsabili marketing non sono bloccati in attesa di una nuova versione per modificare una riga di testo.
Scegliere e passare da uno all'altro.
Iniziate da chi gestisce l'invio. Se è una persona a decidere cosa viene inviato e a chi, iniziate dalla console: è la via più breve per un programma funzionante. Se è il software a decidere, integrate l' API. Se entrambe le condizioni sono vere, create un unico account e sfruttate ogni funzionalità per cui è più adatto.
La migrazione è solitamente un processo additivo, non una sostituzione completa. I team che iniziano con la console e in seguito necessitano di automazione mantengono i propri contatti, modelli e ID mittente, aggiungendo poi le chiamate API per i flussi che devono essere automatizzati. I team che iniziano con un approccio API-first spesso aggiungono la console in un secondo momento, in modo che i colleghi non tecnici possano gestire le campagne senza dover scrivere codice. Poiché entrambe le piattaforme si basano sulla stessa connettività, il passaggio dall'una all'altra non implica la necessità di riottenere la deliverability o di riapprovare gli ID mittente.
BroadNet gestisce questo livello di distribuzione dal 2003, raggiungendo oltre 200 paesi attraverso più di 1.000 connessioni con operatori. La scelta che proponiamo ai clienti è quasi sempre la stessa: abbinare l'interfaccia a chi effettua l'invio e utilizzare entrambe le opzioni quando entrambe sono vere.