In questo articolo, MuleSoft approfondisce la modalità con cui la società OneMain Financial (holding americana di servizi finanziari) ha creato un framework di notifica omnichannel per i clienti utilizzando la piattaforma Anypoint.
La società attualmente sfrutta molteplici fornitori attraverso diverse tipologie di canali di comunicazione elettronica. L’integrazione di tali vendor ha fornito la capacità necessaria richiesta dalle diverse linee di business per soddisfare le molteplici esigenze.
Fino a due anni fa, le integrazioni con i vendor apparivano come illustrate nell’immagine seguente. Sono integrazioni point-to-point che richiedono un codice personalizzato significativo.
Inoltre, sono state sviluppate applicazioni ad-hoc per casi d’uso e vendor specifici, ancora non la strategia per le comunicazioni aziendali non era ben chiara e definita.
Tale ambiente ha consentito ai singoli progetti di definire la propria architettura e ha comportato sforzi duplicati. In definitiva, ciò ha causato incongruenze nella capacità di supportare tali servizi, in particolare con un aumento del volume delle comunicazioni tra i sistemi OneMain e la loro base di clienti.
Questo ha spinto OneMain a definire una strategia aziendale per progettare al meglio soluzioni che sfruttano il riutilizzo di risorse, mitigano i rischi e portano ad una riduzione dei costi.
Per l’istituto finanziario è stato fondamentale comprendere ogni caso d'uso e le diverse modalità di coinvolgimento dei clienti. Ad esempio, poiché questi casi d'uso si concentravano su attività di marketing nel campo assicurativo per l’apertura di una pratica di finanziamento e il recupero, la società ha dovuto considerare anche iniziative di tipo operativo che fornissero al cliente un unico mezzo di comunicazione su una varietà di canali diversi.
Pertanto, l’architettura doveva essere sufficientemente flessibile da raggiungere direttamente i clienti da qualsiasi canale, se necessario.
L’integrazione con MuleSoft per l’invio delle notifiche si è evoluta nell'ultimo anno. Il primo vero caso d'uso ha riguardato l’integrazione con Twilio per un sistema di avviso per le notifiche di finanziamento.
Di recente OneMain ha iniziato ad offrire il deposito diretto come opzione per ricevere i fondi al momento della prenotazione di un prestito. Pertanto, quando un cliente riceve con successo il deposito diretto, tale funzione proviene da un'applicazione che risiede in uno dei sistemi principali. Questa transazione viene consegnata su una coda contenente il numero di telefono di destinazione e il contenuto del messaggio.
Tale coda è monitorata da un listener implementato all'interno di un'API di esperienza progettata specificamente per quell'applicazione e l'API stessa effettua una richiesta http a un'API di sistema per inviare un messaggio con Twilio.
È stata sviluppata un'API di sistema specifica per Twilio che è configurata con tutti i dettagli degli account di OneMain e, sebbene sia molto specifica per la società, fornisce un'interfaccia restful generica per qualsiasi API di livello superiore che desideri utilizzarla.
Sono stati convertiti altri alert come la notifica di passcode una tantum in Mule dai servizi legacy. Anche se i trigger di queste trasmissioni sono processi aziendali completamente diversi, sono comunque in grado di riutilizzare la stessa API di sistema per consolidare tutto il traffico SMS su Twilio.
Tale approccio all’integrazione consente maggiore flessibilità, velocità e la possibilità di riutilizzo di risorse. I costi di sviluppo e il time-to-market si sono notevolmente ridotti nel momento stesso in cui è partita la nuova iniziativa di comunicazione digitale con i clienti.
L’obiettivo principale di questa nuova iniziativa è l'invio di notifiche push mobile ai clienti. In questo modo i clienti possono essere avvisati quando il loro estratto conto è disponibile per la visualizzazione e ricevono un promemoria quando un pagamento è in scadenza.
La soluzione di messaggistica consente la consegna gratuita di messaggi ad applicazioni mobile native, indipendentemente dal tipo di telefono del cliente. Internamente, è stata una sfida mantenere un database per le preferenze dei clienti insieme a ciascuno dei token Firebase per quantificare il numero di dispositivi.
Pertanto, è stata creata un'API esposta sul front-end dell’applicazione web che consentisse a un utente di mantenere le proprie preferenze di attivazione e registrare i dispositivi sul proprio account.
Ciò significa che l’applicazione Web è un host di service layer ed ha la funzione di proxy tra il service bus aziendale e l'applicazione Web rivolta ai clienti di OneMain.
Le notifiche push stesse sono generate in due passaggi diversi. Questo perché il trigger che crea la notifica proviene dall'applicazione principale o dal mainframe, ma in realtà è orchestrato all'interno dell’API di processo.
Quindi, in primo luogo, i trigger sono creati e messi in coda su richiesta dal sistema di consumo, quindi tale sistema di consumo specifica l'identificatore del cliente che dovrebbe ricevere quel push.
Quindi, l'API verifica che il cliente a cui il sistema principale desidera inviare la notifica push sia effettivamente abilitato per riceverla, e che disponga di uno o più token del dispositivo disponibili a cui inviarla.
Questo controllo viene eseguito all'interno del process layer utilizzando i dati recuperati in risposta alle richieste a un'API del system layer supportata da un database. Se la convalida va a buon fine, i clienti abilitati dispongono di un device token che accoda le notifiche all'interno del sistema.
La fase di delivery è separata, perciò viene utilizzato uno scheduler esterno configurato per avviare un processo. Tale processo recupera e avvia la delivery di tutte le notifiche di insorgenza per casi d'uso specifici.
Ciò fornisce la flessibilità aziendale per decidere quando inviare tali notifiche, in che modo coinvolgere i clienti per casi d'uso specifici, ecc.
Quando l'API di processo viene attivata, inizia a fornire notifiche e recupera tutte le notifiche non inviate di un determinato tipo. Quindi le fornisce al client che può quindi richiedere la consegna di tali notifiche una alla volta o insieme in batch. È possibile riutilizzarli in altri casi d'uso aziendali.
Inoltre, il record del database creato e la coda delle notifiche sono quindi corretti per riflettere l'esito della transazione con Firebase. Il vantaggio di ciò è che le transazioni non riuscite devono rimanere non inviate e possono essere re-inviate durante il successivo intervallo pianificato.
Questo è il punto in cui OneMain ha visto l'opportunità di sfruttare ulteriormente la riutilizzabilità nel process layer stesso sviluppando un framework di notifica omnichannel più flessibile in cui le notifiche stesse sono indipendenti dai canali su cui vengono inviati.
Lo stack di API che implementano questo processo è costruito su un database SQL che viene utilizzato per tre scopi diversi. Ci sono tabelle utilizzate per la configurazione, quindi gli eventi di notifica sono definiti per primi. Ad esempio, ciò potrebbe includere il promemoria di scadenza di un pagamento, l'avviso di modifica del punteggio di credito o la consegna del passcode monouso.
Tutti questi eventi definiti sono quindi associati a una o più configurazioni diverse che determinano il canale come SMS o email. Ciò fornisce al consumatore dell'API di processo la flessibilità di scegliere come target in modo selettivo i canali per inviare un evento su uno o più canali.
Questo framework consente di definire nuovi eventi e quindi associarli alle diverse categorie di preferenze che appaiono all'interno dell'app mobile.
I clienti possono attivarli o disattivarli. OneMain dispone anche di sistemi di template di messaggi flessibili che consentono di personalizzare e parametrizzare la copia ricevuta dagli utenti finali. Piuttosto che richiedere al client system di definire costrutti e inviare ogni volta effettivamente i contenuti tramite l'API Mule, il consumatore deve solo inviare i pezzi necessari che vengono inseriti in template predefiniti associati allo specifico evento.
In alternativa, è possibile avere un client che attiva un processo separato che inizia dall'orchestrazione raccogliendo dinamicamente i dati necessari per essere inseriti in un modello. Qui, l'API di processo attiva direttamente l'evento con l'informazione richiesta, mantenendo semplice l'interfaccia client a monte.
Il database SQL di OneMain registra anche una cronologia di tutte le notifiche in uscita consentendo di interrogare eventi specifici. Utilizzando tali informazioni, è possibile prendere decisioni informate, risolvere i problemi e aumentare la tolleranza alle anomalie.
Ciò è particolarmente utile per le notifiche in semi-real-time o batch in cui è possibile attendere eventuali problemi transitori del sistema client o problemi del sistema downstream e riprovare.
Riutilizzando questo processo, è stato creato un framework di notifiche configurabile in cui il customer engagement può essere avviato in una varietà di client ed esperienze diversi.
Inoltre, sono state sviluppate diverse API di esperienza per ascoltare e tradurre qualsiasi dato necessario prima di richiamare il processo con altre API di esperienza consumate dalle applicazioni mobili e web.
I fornitori devono solo preoccuparsi di fornire il minimo indispensabile di informazioni per inviare un evento anche ai clienti.
Quindi, quali sono i vantaggi raggiunti? Ce ne sono alcuni fondamentali:
- le integrazioni specifiche su Anypoint Platform sono state progettate per essere scalabili;
- è stato creato un trattamento specifico del fornitore che è delegato alle API di sistema in base alle esigenze per incapsulare la logica e rendere più facile/più veloce reagire ai cambiamenti senza causare un impatto di vasta portata;
- quasi tutti i casi d'uso con fornitori esistenti sono richieste solo modifiche alla configurazione all'interno del database, quindi nessuna modifica al codice;
- l'aggregazione dei log avviene utilizzando lo stack Elk, quindi il team di supporto alla produzione è stato in grado di creare e sostenere una solida suite di dashboard;
- sempre più processi aziendali utilizzano Anypoint Platform come livello di integrazione, consentendo alla società di catturare più customer journey dei clienti su queste dashboard;
- sensibile miglioramento nel rilevamento delle anomalie durante la risoluzione dei problemi, il che significa che è più probabile che i problemi siano risolti in modo proattivo prima che abbiano un impatto negativo sui processi aziendali;
- migliore capacità di mettere a punto le prestazioni e ottimizzare i processi secondo necessità.
Nel complesso, l'implementazione di MuleSoft e la creazione di un framework omnichannel per le notifiche ai clienti ha consentito a OneMain di soddisfare le esigenze aziendali e superare le aspettative.
