Checklist di lancio RCS: andare online con un agent verificato

Questa checklist è rivolta ai team marketing, CRM e prodotto che hanno deciso di provare la messaggistica business RCS e ora devono mettere online un agent senza perdere settimane in rifacimenti. Percorre ogni fase, dalla scelta del primo caso d'uso alla lettura dei risultati del pilota. Se vi servono prima le basi su che cos'è l'RCS e in cosa differisce dall'SMS, partite da RCS Business Messaging spiegato e poi tornate qui.

Che cosa comporta un lancio RCS?

Un lancio RCS ha cinque fasi: definizione dell'ambito, asset, approvazione, sviluppo e test, pilota. La maggior parte dei ritardi nasce nelle prime tre, non nello sviluppo, perché le approvazioni dipendono dalle evidenze sul brand e dal processo di ciascun operatore.

RCS Business Messaging (RBM) passa dalla piattaforma RBM di Google, che Google chiama oggi RCS for Business. Il brand è rappresentato da un "agent": il profilo mittente verificato con il vostro nome, il logo e la descrizione. Il vostro provider di messaggistica collega i vostri sistemi alla piattaforma e gli operatori mobili decidono se il traffico RBM raggiunge i loro abbonati.

Fase 1: come scegliere il primo caso d'uso?

Scegliete un caso d'uso in cui i contenuti ricchi battono chiaramente il testo semplice e in cui inviate già SMS, così avete una base di confronto. Un primo lancio circoscritto viene approvato più in fretta e dà risultati più puliti.

La revisione al lancio di Google vi chiede di dichiarare il caso d'uso dell'agent. Le categorie indicate nella documentazione sono OTP, transazionale, promozionale e multiuso. Il caso d'uso dichiarato orienta ciò che i revisori si aspettano di vedere in attivazioni, contenuti e gestione dell'opt-out, quindi siate precisi.

Buoni candidati per iniziare:

• Aggiornamenti su ordini e consegne. Una rich card con l'immagine dell'articolo, la fascia di consegna e le azioni "Traccia" o "Riprogramma" sostituisce un SMS lungo con un link.
• Promemoria di appuntamenti. Una card con data, ora e luogo, più risposte suggerite come "Conferma" e "Riprogramma" e un'azione "Aggiungi al calendario".
• OTP brandizzato. Un breve messaggio con il codice da un mittente verificato, che aiuta i clienti a distinguere i codici autentici dal phishing. Mantenete l'SMS come percorso garantito; vedi la nostra guida ai messaggi OTP.
• Promozioni mirate. Un carosello di prodotti per i clienti che hanno dato il consenso al marketing. Le promozioni affrontano la revisione e le aspettative sul consenso più severe, quindi raramente sono il miglior primo lancio.

Mappare paesi e operatori

Elencate i paesi di destinazione e, in ciascuno, gli operatori che servono la maggior parte dei vostri clienti. RBM raggiunge un abbonato solo se il suo operatore ha lanciato RBM e ha approvato il vostro agent. Nel GCC e nella più ampia area MENA la disponibilità dipende da operatore e paese e viene confermata durante l'attivazione (onboarding); non basate il piano su un'affermazione a livello di paese del tipo "qui l'RCS è attivo".

Fase 2: quali asset servono prima dell'invio?

Preparate ogni asset prima di inviare la richiesta, perché le modifiche successive fanno ripartire parti della revisione. Il profilo dell'agent è anche ciò che vedono i clienti: trattatelo come lavoro di brand, non come burocrazia.

Checklist del profilo dell'agent

1. Nome visualizzato che corrisponda esattamente al vostro brand consumer, non alla ragione sociale che i clienti non riconoscono.
2. Logo nel formato e nelle dimensioni indicati dal provider, leggibile se mostrato in piccolo e ritagliato in un cerchio.
3. Immagine banner per la pagina informativa dell'agent, senza testo di piccole dimensioni.
4. Colore del brand con un contrasto sufficiente per il testo sui pulsanti.
5. Breve descrizione che dica che cosa invia l'agent, ad esempio "Aggiornamenti sugli ordini e programmazione delle consegne di Rawda Home."
6. Opzioni di contatto: almeno una tra telefono, sito web ed email, tutte funzionanti e presidiate.
7. Informativa privacy e termini di servizio su un sito web pubblico, collegati dall'agent.
8. Lingue: decidete se l'agent scriverà in arabo, inglese o in entrambe e preparate i contenuti in ciascuna.

Checklist delle evidenze per la revisione

La documentazione di Google sul lancio elenca ciò che serve per una revisione gestita da Google. Preparate:

1. Un sito web del brand funzionante e accessibile pubblicamente.
2. I link all'informativa privacy e ai termini di servizio.
3. Una descrizione dell'esperienza dell'agent, con un video di anteprima o trascrizioni dettagliate delle conversazioni.
4. Il caso d'uso dichiarato.
5. Le descrizioni di come gli utenti vengono contattati, di come interagiscono e di come si disiscrivono, coerenti con il caso d'uso.
6. La gestione dello STOP in ogni lingua usata dall'agent, compresa una conferma che l'utente è disiscritto.

Scrivete trascrizioni che mostrino flussi reali, compreso ciò che accade quando un utente risponde con un testo libero che non vi aspettate.

Fase 3: come funzionano verifica del brand e approvazione al lancio?

La verifica del brand conferma che una persona autorizzata del brand approva le informazioni dell'agent e il diritto del vostro provider di gestirlo. Secondo Google, è richiesta prima del primo lancio e avviene dopo l'invio della richiesta di lancio.

Indicherete un referente del brand: un dipendente con l'autorità di confermare l'agent. Google, gli operatori o entrambi possono contattare questa persona, a seconda del tipo di lancio. Il ritardo evitabile più comune è un referente in ferie, che non riconosce la richiesta o che la inoltra a una casella che nessuno legge. Informatelo in anticipo.

L'approvazione al lancio è poi gestita da Google, dagli operatori o da entrambi, in base agli operatori selezionati. La documentazione di Google osserva che alcuni operatori svolgono una revisione propria e richiedono un accordo diretto con il brand, e che questi operatori rifiutano il lancio se non esiste un contratto. Per questo il piano di lancio va costruito per operatore, non per paese.

Checklist di approvazione

• Referente del brand individuato, informato e raggiungibile durante la finestra di revisione.
• Caso d'uso dichiarato e coerente con tutte le trascrizioni e le attivazioni.
• Elenco degli operatori confermato con il provider, compresi quelli che richiedono un contratto diretto.
• Testo dell'opt-out approvato dall'area legale in ogni lingua.
• Responsabile interno assegnato a rispondere rapidamente alle domande dei revisori.

Dopo il lancio, Google Messaggi mostra un segno di spunta di verifica accanto al nome dell'agent e la pagina dei dettagli dell'agent indica chi lo ha verificato.

Fase 4: come sviluppare e testare i messaggi RCS?

Costruite ogni messaggio come una coppia: la versione RCS e la versione SMS con le stesse informazioni essenziali. Poi testate su dispositivi reali prima del lancio.

Regole di design per ogni tipo di messaggio

La documentazione di Google fissa limiti entro cui progettare: messaggi di testo fino a 3.072 caratteri, rich card con fino a quattro suggerimenti ciascuna, caroselli da 2 a 10 card, fino a 11 suggerimenti per messaggio ed etichette dei suggerimenti fino a 25 caratteri. Anche i file multimediali hanno limiti di dimensione.

Regole pratiche valide per tutti i tipi:

• Mettete i fatti essenziali nel testo, non solo dentro un'immagine. Alcuni destinatari riceveranno la versione SMS e gli screen reader hanno bisogno di testo.
• Usate etichette dei suggerimenti che funzionino come verbi, come "Riprogramma" o "Paga ora", e mantenetele sotto il limite documentato in entrambe le lingue; le etichette in arabo richiedono spesso una revisione separata.
• Non esagerate. Un carosello da dieci card per un semplice promemoria aggiunge attrito e domande in fase di revisione.
• Gestite le risposte in testo libero. Instradate le risposte inattese a una persona o a un menu chiaro invece di ignorarle.

Costruire la logica di consegna

La documentazione di Google raccomanda di verificare le funzionalità supportate da un utente prima di avviare una conversazione e di usare solo ciò che il dispositivo supporta. I controlli di compatibilità restituiscono ciò che un dispositivo supporta quando il numero si è connesso di recente all'RCS; Google offre anche controlli in blocco che stimano quanti numeri sono raggiungibili senza rivelare le funzioni del dispositivo.

Prevedete tre esiti all'invio:

1. Accettato e consegnato. Ricevete sul webhook un evento DELIVERED ed eventualmente un evento READ se l'utente ha attivato le conferme di lettura.
2. Rifiutato all'invio. Google restituisce 404 NOT_FOUND quando il dispositivo non supporta l'RCS, l'RCS è disattivato o il vostro agent non è stato lanciato su quella rete, e 400 INVALID_ARGUMENT quando il messaggio usa una funzione che il dispositivo non supporta. Inviate subito la versione SMS.
3. Accettato ma non consegnato. L'utente potrebbe essere offline. Google mantiene in coda i messaggi non consegnati fino a 30 giorni, quindi impostate una scadenza del messaggio con ttl o expireTime. Alla scadenza la piattaforma revoca il messaggio e vi avvisa, e voi inviate la versione SMS.

Google raccomanda inoltre di confermare che un messaggio non sia stato consegnato prima di rinviarlo e di usare ID messaggio univoci, perché i clienti non ricevano duplicati. La nostra guida alla strategia di fallback tra canali tratta in dettaglio timeout e prevenzione dei duplicati tra WhatsApp, RCS e SMS.

Testare su dispositivi registrati

Prima del lancio, un agent RBM può scrivere solo a dispositivi di test che registrate e che accettano l'invito. Usateli in modo mirato:

• Almeno un dispositivo di test per ciascun operatore principale in ogni mercato di destinazione, con SIM attive.
• Android con Google Messaggi e iPhone su un operatore in cui l'RCS business è supportato, se il vostro pubblico comprende entrambi.
• Ogni messaggio visualizzato in arabo e in inglese, compreso il layout da destra a sinistra nelle card.
• Ogni risposta e azione suggerita toccata, e ogni risposta ricevuta dal vostro webhook.
• STOP e i suoi equivalenti testati in ogni lingua, con invio della conferma.
• Un dispositivo con RCS disattivato, per confermare che il fallback su SMS scatti.
• Un dispositivo offline, per confermare che la scadenza attivi il fallback e che nulla arrivi due volte.

Fase 5: come eseguire e misurare un pilota RCS?

Eseguite il pilota rispetto a un gruppo di controllo che riceve lo stesso messaggio via SMS e giudicatelo in base alle azioni completate per unità di costo.

Checklist del pilota

1. Definite l'azione che vi interessa: consegna programmata, appuntamento confermato, pagamento effettuato.
2. Dividete il pubblico tra i destinatari compatibili con l'RCS: la maggior parte riceve RCS, un gruppo di esclusione (holdout) riceve solo SMS. Confrontare utenti RCS con utenti non compatibili mescola l'effetto del canale con le differenze di pubblico.
3. Tracciate per messaggio: inviato, consegnato, letto dove disponibile, azione compiuta, fallback attivato, disiscrizioni.
4. Trattate con cautela le conferme di lettura. Dipendono dalle impostazioni dell'utente, quindi un evento READ mancante non dimostra che il messaggio non sia stato letto.
5. Calcolate il costo per azione completata per l'RCS, compreso l'SMS di fallback, e per il gruppo solo SMS. Il listino del provider indica i costi per messaggio; vedi i prezzi.
6. Verificate disiscrizioni e risposte per cogliere segnali che frequenza o contenuto non vanno.
7. Decidete: scalare, correggere e ripetere, oppure fermarsi.

Esempio pratico: il primo agent RCS di un rivenditore di arredamento del Golfo

"Rawda Home" (nome di fantasia) è un rivenditore di arredamento che vende negli Emirati Arabi Uniti e in Arabia Saudita. Oggi invia SMS per programmare le consegne e molti clienti chiamano il contact center per cambiare fascia oraria.

• Ambito. Il team sceglie un caso d'uso transazionale: la programmazione delle consegne. Il provider conferma quali operatori di ciascun paese hanno lanciato RBM; la copertura differisce per operatore, quindi il pilota parte solo dove l'agent è approvato.
• Asset. Il marketing fornisce il nome del brand consumer, il logo, il banner e una descrizione in arabo e in inglese. L'area legale conferma il link all'informativa privacy e il testo dello STOP in entrambe le lingue. Il responsabile e-commerce viene indicato come referente del brand e informato.
• Messaggi. Una rich card mostra l'immagine del prodotto, la fascia di consegna proposta e tre risposte suggerite: "Conferma", "Cambia fascia" e "Parla con noi". "Cambia fascia" apre un carosello con le fasce disponibili. La versione SMS riporta la stessa fascia e un link a una pagina di programmazione.
• Logica di consegna. Ogni invio ha una scadenza impostata ben prima del termine ultimo del giorno di consegna. Una risposta 404 o una scadenza fa partire la versione SMS, e il sistema registra quale canale ha consegnato così nessuno riceve entrambi i messaggi.
• Pilota. Tra i clienti compatibili con l'RCS, un gruppo holdout riceve solo SMS. Al termine, il team confronta la quota di consegne confermate senza telefonata e il costo per consegna confermata, prima di decidere se aggiungere il tracciamento ordini come secondo caso d'uso.

Quali sono gli errori più comuni nel lancio?

La maggior parte dei lanci RCS falliti o lenti inciampa negli stessi pochi problemi.

• Lanciare più casi d'uso insieme. Ognuno aggiunge domande di revisione e contenuti da approvare.
• Usare la ragione sociale come nome visualizzato, che i clienti non riconoscono.
• Un referente del brand impreparato, che blocca la verifica.
• Dare per scontata la copertura a livello di paese. La raggiungibilità si decide per operatore, dispositivo e impostazione dell'utente.
• Nessuna versione SMS di ogni messaggio, così i destinatari non compatibili non ricevono nulla.
• Nessuna scadenza del messaggio, per cui gli utenti offline ricevono OTP obsoleti o offerte scadute giorni dopo.
• Rinviare senza verificare la consegna, creando duplicati.
• Considerare completi i tassi di lettura, quando le conferme dipendono dalle impostazioni dell'utente.
• Ignorare il consenso. Le promozioni RCS richiedono la stessa disciplina di opt-in e opt-out degli SMS; vedi la nostra guida al consenso.

Limiti di questa checklist: i requisiti di Google, i processi degli operatori e il supporto dei dispositivi cambiano. Confermate le regole attuali nella documentazione di Google e con il vostro provider prima di ogni lancio. Questa è una guida pratica, non una consulenza legale.

Come vi aiuta OmniChannels.ai

OmniChannels.ai offre la messaggistica business RCS tramite BroadNet Technologies, partner Google RBM. Avete un mittente brandizzato verificato, rich card, caroselli fino a 10 card, risposte e azioni suggerite e fallback automatico su SMS dove l'RCS non è disponibile, sfruttando la connettività diretta con gli operatori di BroadNet per gli SMS. Gli stati di consegna di ogni canale arrivano in un unico formato di webhook. Gli sviluppatori possono partire dalla documentazione dell'API RCS. La copertura degli operatori nei vostri mercati viene confermata durante l'attivazione (onboarding).