I vantaggi e gli svantaggi della creazione di MMS nativi di Braze

Pubblicato: 2021-02-20

La piattaforma di coinvolgimento dei clienti Braze è progettata per essere sia naturalmente cross-channel che indipendente dal canale, consentendo ai marchi di raggiungere i propri clienti sui canali che parlano loro in modi che supportano esperienze personalizzate e intuitive. Ciò significa che siamo sempre alla ricerca di opportunità per espandere il mix di canali di messaggistica supportati dalla nostra piattaforma. Poiché Braze è progettato per supportare funzionalità avanzate come la personalizzazione dinamica e l'analisi predittiva su ogni canale, dobbiamo anche riflettere su ciò che costruiamo e su come lo facciamo per garantire un prodotto scalabile ed efficace.

Cosa succede quando si combina questo approccio meticoloso all'espansione del canale con la crescente necessità di supportare esperienze di messaggistica sempre più ricche e accattivanti? Ottieni il servizio di messaggistica multimediale (MMS) nativo di Braze, che abbiamo iniziato a supportare all'inizio di quest'anno. Diamo uno sguardo dietro le quinte a questo nuovo canale chiave e al modo in cui l'organizzazione del prodotto e dell'ingegneria ha lavorato per renderlo una realtà per i nostri clienti.

Creazione di MMS Braze Native: come si presentava il processo

Il lancio del supporto nativo per SMS all'interno della nostra piattaforma nel 2019 ha aperto nuove grandi opportunità di coinvolgimento dei clienti per i marchi. Una volta che gli SMS facevano parte del nostro mix di messaggistica, l'aggiunta di MMS sembrava un'estensione naturale di questo canale, consentendo ai clienti di sfruttare appieno sia gli SMS che gli MMS non solo per i casi d'uso delle transazioni tradizionali, ma anche per coinvolgenti campagne di marketing.

La domanda dei clienti attuali e potenziali ci ha rapidamente ispirato a sostenere questo canale. La creazione di una funzionalità come l'MMS nativo di Braze è un processo iterativo in più fasi, che richiede a diversi stakeholder di tutta l'organizzazione di valutare, condividere le proprie conoscenze e assistere in varie fasi. Per noi, questo sforzo si svolge come segue:

1. Assemblare la tua squadra

Prima di poter dare il via a un progetto come la creazione di MMS nativi di Braze, devi mettere insieme un team. Poiché la nostra organizzazione di prodotto e ingegneria opera in verticali mirati, ciò significava riunire rappresentanti incentrati sugli SMS dei nostri team di gestione del prodotto, progettazione del prodotto e ingegneria per collaborare allo sforzo e identificare altri potenziali stakeholder, a seconda dei casi. In questo caso, il nostro team si è impegnato a toccare la base 1-2 volte a settimana oltre gli standup generali del team, al fine di garantire che stessimo comunicando regolarmente su come si stava evolvendo il progetto.

2. Esecuzione della scoperta

Una volta creato il nostro team, abbiamo iniziato un solido processo di ricerca e scoperta, con l'obiettivo di rispondere alle seguenti domande:

  • C'è un'esigenza concreta del cliente per questa funzione?
  • Che aspetto hanno le offerte di altre piattaforme di coinvolgimento dei clienti quando si tratta di MMS?
  • Come possiamo connettere senza problemi gli MMS al nostro canale SMS nativo esistente?
  • In definitiva, vale la pena dare la priorità a questa funzione e, in tal caso, come dovremmo approcciarci alla sua creazione?

Il nostro processo di scoperta tende ad essere relativamente standard in diversi verticali di prodotto. Quando abbiamo a che fare con una nuova funzionalità come MMS, quel processo prevede conversazioni interne con i membri del team go-to-market, interviste ai clienti, analisi della concorrenza e altro ancora. L'obiettivo è sempre quello di identificare presupposti e rischi, misurare la domanda dei clienti e valutare se lo sforzo proposto è sia fattibile che prezioso per la nostra base di clienti.

Durante la fase di scoperta di questo progetto, abbiamo scoperto che l'MMS arrivava sempre più spesso con potenziali clienti, così come con clienti esistenti che cercavano di inviare messaggi più ricchi tramite il marketing dei messaggi di testo. Il nostro punto di partenza è stato che l'MMS è stato visto sempre più come un componente fondamentale di una strategia di marketing dei messaggi di testo e ha rafforzato l'importanza di trovare un modo per arricchire la nostra offerta di SMS nativi con gli MMS.

3. Definizione dell'ambito della funzionalità pianificata

Questa parte del processo, in cui determiniamo i must-have per una funzione in arrivo, è stata piuttosto fluida in questo caso. In gran parte, ciò era dovuto al fatto che l'MMS funziona in modo molto simile agli SMS e siamo stati in grado di fare affidamento sulle connessioni esistenti al nostro partner tecnologico Braze Alloys Twilio per trasmettere questo ulteriore livello di dati. Nel complesso, i problemi principali che abbiamo di fronte durante l'ambito della funzionalità non riguardavano il modo in cui avremmo dovuto supportare gli MMS e più il garantire che i dettagli fossero corretti. Per esempio:

  • Siamo chiari su quali configurazioni sono necessarie per espandere la nostra integrazione SMS per supportare gli MMS?
  • In che modo la nostra fatturazione esistente relativa all'utilizzo degli SMS da parte dei clienti è influenzata dall'introduzione degli MMS?
  • Cosa sarà necessario per impostare i clienti con l'MMS (ad es. abilitazione di codici brevi, ecc.) e ci sono dei passaggi che possiamo intraprendere per ridurre al minimo il lavoro necessario?

Per raggiungere l'allineamento su come rispondere a queste domande, abbiamo tenuto discussioni, sia interne che esterne, su quali funzionalità MMS fossero necessarie e sull'impatto consentito dai nostri contratti con i clienti, dal punto di vista della fatturazione. Dopo queste conversazioni, il team del prodotto si è seduto con l'ingegneria e il design del prodotto per parlare di come creare MMS nativi prima di iniziare a deridere il set di funzionalità. Una volta che il prototipo di design era pronto, abbiamo organizzato un lancio del prodotto in cui Engineering ha esaminato il design e il set di prodotti richiesto, quindi ha fornito indicazioni su ciò che era realizzabile oggi, su ciò che non poteva essere fatto e su ciò che doveva essere modificato affinché il progetto andasse avanti. In questo tipo di riunioni, l'obiettivo finale è concordare ciò che sarà incluso nella versione del prodotto MVP (Minimum Viable Product).

Uno dei grandi punti di discussione in questo caso era quante immagini potevano essere incluse nei messaggi MMS nella versione MVP della funzione. Idealmente, saresti in grado di aggiungere un numero qualsiasi di elementi visivi a un messaggio di testo. Tuttavia, la nostra ricerca ha rilevato che la maggior parte dei casi d'uso dei clienti associati all'MMS richiedeva solo una singola immagine per l'esecuzione, suggerendo che aveva più senso concentrarsi sull'avvio di un MVP in grado di supportare un'immagine per messaggio e quindi ripetere da lì.

Questa e altre decisioni simili hanno reso possibile che la versione iniziale fosse molto più veloce, perché ci ha permesso di fare affidamento su funzionalità e componenti esistenti come Braze Media Library, che già consentiva ai clienti di caricare e allegare foto e video ai messaggi in altri canali . Se avessimo scelto di lanciare con il supporto per più immagini, avrebbe richiesto molto più lavoro personalizzato e probabilmente avrebbe ritardato la nostra capacità di offrire supporto MMS nativo ai nostri clienti, rendendola un'opzione meno interessante dal nostro punto di vista.

4. Creazione di MMS nativi

Costruire un MVP non significa solo concordare tra i team ciò che deve essere incluso. Una volta ottenuto tale allineamento, attraversiamo un processo di pianificazione in cui identifichiamo le fasi e i passaggi specifici necessari per rendere l'MVP una realtà. Una volta che abbiamo questa tabella di marcia approssimativa, suddividiamo il progetto in fasi che possono essere realizzate una per una in una serie di sprint Agile. In questo caso, il lavoro che dovevamo spartire prevedeva:

  • Modifica del nostro schema di back-end per consentire l'allegato di un messaggio multimediale
  • Adeguamento del nostro frontend per consentire ai clienti di caricare elementi multimediali per MMS
  • Integrazione dei controlli sui prodotti per consentire al nostro team Customer Success di attivare e disattivare la funzionalità per i clienti
  • Integra le funzionalità di raccolta dei dati sull'utilizzo per supportare una fatturazione accurata e tempestiva in relazione all'utilizzo degli MMS

Le nostre organizzazioni di prodotto e ingegneria utilizzano Jira per supportare questo tipo di gestione dei progetti. Durante questa fase del progetto, costruiamo tutti questi diversi passaggi - e tutte le loro attività secondarie dipendenti - come "storie" Agile all'interno di Jira; insieme, tutti quei biglietti formano una "epopea" che rappresenta la creazione di una versione MVP del supporto MMS nativo all'interno della nostra piattaforma.

In generale, abbiamo lavorato per mantenere le singole storie sufficientemente piccole da poter essere gestite in un unico sprint, al fine di consentire test migliori e un flusso di lavoro più snello. Alcune delle attività erano di natura semplice, ad esempio, la creazione dei controlli del prodotto per i CSM (Braze Customer Success Manager) richiedeva solo poche righe di codice, ma altre erano abbastanza grandi da dover trovare il modo di suddividerle. Ad esempio, quando stavamo lavorando per creare il vero compositore di MMS all'interno di Braze, è stato necessario un discreto lavoro di frontend e backend. Allo stesso modo, il lavoro relativo all'aggiornamento del nostro back-end per consentire l'allegato di elementi multimediali era di portata troppo ampia per essere completato in un unico sprint.

Creazione del supporto MMS: sfide chiave che abbiamo dovuto affrontare

Sebbene alcuni sforzi di sviluppo del software possano essere intensi, complessi o comportare difficoltà significative dal punto di vista tecnico, la creazione del supporto MMS nativo all'interno di Braze ha finito per essere un progetto nel complesso piuttosto basso. Detto questo, ci siamo imbattuti in un paio di sfide:

Inserimento MMS

Sebbene SMS e MMS siano entrambi tipi di messaggi di testo, sono tecnicamente distinti quando si tratta di inviare contatti. In pratica, i numeri di telefono da cui questi marchi inviano devono essere abilitati rispettivamente per SMS o MMS prima che i messaggi possano essere inviati, il che significa che un marchio con un codice lungo o un codice breve abilitato solo a inviare messaggi di testo tramite SMS non è possibile utilizzare quel numero di invio per inviare messaggi MMS visivamente ricchi.

Quando stavamo sviluppando il supporto per gli MMS nativi, ciò significava che era necessario apportare modifiche al nostro processo di onboarding di SMS/MMS. Questi sforzi hanno contribuito a garantire che i marchi che desiderano inviare messaggi MMS dispongano degli strumenti necessari per ottenere i codici brevi o lunghi abilitati per gli MMS necessari per eseguire campagne in questo canale. Per fare in modo che ciò accadesse, abbiamo collaborato con il nostro team di integrazione e onboarding e ci siamo allineati con loro sulle esigenze e le sfide quando si trattava di sfruttare efficacemente l'MMS.

Supporto del tipo di file

Con il contenuto avanzato, è importante essere in grado di supportare i tipi di file multimediali che è probabile che la maggior parte dei clienti desideri utilizzare quando include elementi visivi nei propri messaggi. Ma come per la maggior parte degli aspetti della creazione di una nuova funzionalità, può essere difficile trovare la certezza su quali tipi di file creare supporto.

Quando stavamo creando il supporto per gli MMS, abbiamo utilizzato una ricerca di mercato per determinare che avremmo dovuto avviare con il supporto del tipo di file per i file GIF, PNG e JPEG. Tuttavia, poiché abbiamo monitorato i feedback sin dal lancio, abbiamo riscontrato un aumento delle richieste di supporto per diversi tipi di file, ad esempio PDF e file di invito del calendario (ICS). Quel feedback quindi influisce sul nostro processo di pianificazione per gli aggiornamenti al supporto MMS nativo in futuro.

Pensieri finali

Sebbene la creazione del supporto MMS nativo non sia stato il progetto più difficile o mission-critical che la nostra organizzazione abbia intrapreso, in un certo senso è uno dei più rivelatori.

Non esiste una creazione di funzionalità "tipiche" qui in Braze, ma questo tipo di progetto potrebbe essere il più vicino possibile, poiché è basato su un prodotto esistente, richiede supporto e collaborazione all'interno dell'organizzazione del prodotto e dell'ingegneria (e oltre) e è stato costantemente informato dalla nostra attenzione allo sviluppo di software Agile e ai cicli di feedback iterativi per il miglioramento continuo.

Per saperne di più su come supportiamo gli sforzi di marketing di SMS e MMS, consulta la nostra documentazione SMS/MMS. Interessato a far parte del team Braze Product and Engineering? Dai un'occhiata ai ruoli aperti nella nostra pagina Carriere.