Blueprint Vs Journey Builder - Analogie e differenze

Blueprint Vs Journey Builder in Zoho CRM

Blueprint e Journey Builder in CRM possono avere analogie tecniche in termini di componenti del builder - come Stati, Transizioni e azioni automatizzate.

Tuttavia, poiché differiscono principalmente nel loro scopo e obiettivo, idealmente non vi è spazio per confusione su ciò che si propongono di realizzare. 

La confusione, se presente, tra Blueprint e Journey Builder potrebbe derivare dal fatto che entrambe le soluzioni hanno blocchi costruttivi simili - Stati, Transizioni e Azioni. Questo perché entrambe le soluzioni sono sviluppate sulla base del concetto di Macchina a Stati Finiti (FSM).

Scopra di più sui sistemi di gestione dei processi e una panoramica delle funzionalità di processo in Zoho CRM. 

Macchina a Stati Finiti (FSM) - Il modello alla base dei Process Builder

FSM è un modello matematico ampiamente utilizzato per progettare sistemi sequenziali nei campi del software, dei videogiochi, dell'intelligenza artificiale e altro.

"È una macchina astratta che può trovarsi in esattamente uno di un numero finito di stati in qualsiasi momento. La FSM può passare da uno stato all'altro in risposta ad alcuni input; il passaggio da uno stato all'altro è chiamato transizione. Una FSM è definita dall'elenco dei suoi stati, dal suo stato iniziale e dagli input che attivano ciascuna transizione."

Fonte: Middle Tennessee State University

Alcuni esempi reali di FSM includono un tornello a gettoni ampiamente diffuso nelle stazioni della metropolitana, oppure ascensori, serrature a combinazione e distributori automatici. Un tornello può trovarsi solo in uno stato bloccato o sbloccato - quindi ci sono due stati (finiti). Per passare da bloccato a sbloccato, è necessario un gettone. Il gettone attiva la transizione dallo Stato A allo Stato B. Quando è sbloccato, un gettone non lo riporterà allo stato bloccato - deve essere girato e riportato in posizione. Allo stesso modo, senza un gettone, non è possibile aprirlo. Quindi è un sistema chiaro e infallibile - acquisti un gettone per sbloccare il passaggio attraverso il tornello.

Nel software, diverse soluzioni BPM sono state modellate sulla Macchina a Stati Finiti, e pertanto sono destinate ad essere simili. È probabile che tutte abbiano stati e transizioni, poiché è ciò che il metodo della Macchina a Stati Finiti comporta principalmente.

Pertanto, Blueprint e Journey Builder in Zoho CRM, entrambi modellati sulla Macchina a Stati Finiti, contengono gli stessi blocchi costruttivi - Stati, Transizioni e Azioni. Tuttavia, ciò che si fa con questi componenti differisce in entrambi, perché gli obiettivi delle due soluzioni sono diversi. Ecco alcuni fattori fondamentali di differenza tra i due. 

Scopo principale

Blueprint è uno strumento di gestione dei processi aziendali per promuovere la conformità, mentre Journey Builder è uno strumento per ottimizzare il percorso del cliente attraverso i punti di contatto aziendali.

Stati in un processo Vs stati in un percorso

Gli stati in Blueprint sono costruiti a partire dai valori degli elenchi a discesa presenti nel layout di un record. Poiché aiuta a gestire la conformità, Blueprint consente di considerare i valori degli elenchi a discesa come stato del lead, fase della trattativa, come fasi e aiuta a governare la progressione di un record attraverso le diverse fasi dal momento della sua creazione.

Gli stati nel Journey Builder indicano in quale punto dell'intero percorso di acquisto si trova un cliente. Questo stato può essere associato a un modulo CRM. Ad esempio, quando un visitatore si registra per il Suo prodotto, può essere classificato come lead e la sua registrazione tramite modulo web potrebbe essere indicata nel percorso come uno stato chiamato Lead Creato mappato al modulo Lead. Man mano che attraversano il percorso, è necessario istruire il CRM su quale modulo devono essere mappati, per tenere traccia. Inoltre, gli stati nel Journey Builder sono stati liberi, ovvero è possibile creare uno Stato a propria scelta durante la costruzione del percorso. Non provengono specificamente da un campo elenco a discesa e non devono essere predefiniti come in un Blueprint. 

Transizioni Vs Trigger

Blueprint guida i team di vendita attraverso un processo sistematico. Come parte della guida, Blueprint richiede dati ai team in ogni fase, valida i dati ricevuti e automatizza le azioni di routine, promuovendo così la conformità a tutti i livelli. L'esecuzione corretta di un requisito, che si tratti di compilare campi, allegare documenti o completare checklist, effettua la transizione del record da uno stato all'altro. 

Con Journey Builder, non si tratta di "raccogliere dati" o guidare i team, perché quello non è l'obiettivo. L'obiettivo è orchestrare una serie di eventi basati su un risultato precedente. Ad esempio, una visita al sito web dovrebbe attivare un messaggio di chat dal vivo per un visitatore, e una successiva risposta in chat dovrebbe allertare un agente nonché inviare una conferma all'email del cliente. Questa email dovrebbe successivamente attivare promemoria di follow-up per l'agente affinché risponda al messaggio in chat. In questo semplice esempio, si può vedere come l'obiettivo sia automatizzare una serie di azioni o eventi per rendere l'esperienza del cliente piacevole. Questo non vale solo per un singolo cliente, ma ogni cliente che passa attraverso il sito web e il widget di chat riceverà questa esperienza. Pertanto, si tratta di ottimizzare il percorso del cliente a tutti i livelli. 

Ciò che sposta un cliente da una fase all'altra del suo percorso di acquisto sono i segnali o gli eventi ricevuti, che attivano o spingono avanti nel percorso. Sulla base di questi trigger, vengono definite le azioni successive. Quindi il blocco di transizione qui non è un requisito di dati ma segnali o eventi. Esempi: Apertura di un'email, Risposta a un sondaggio, Creazione di un ticket Desk e così via. 

 

Fattori di differenza	Blueprint	Journey Builder
Scopo	Gestione della conformità	Ottimizzazione del percorso del cliente
Per chi è progettato?	Team interni dell'organizzazione	Clienti
Definizione di Stato	Ogni fase nel processo aziendale. Ovvero, i valori del campo elenco a discesa Stato selezionato.	La fase in cui si trova un cliente nel suo percorso di acquisto.
Definizione di Transizione	La Transizione in un Blueprint prescrive le linee guida da seguire, le azioni da eseguire e i dati da inviare dall'utente o dal team indicato. Il completamento delle azioni prescritte sposterà il record da uno stato all'altro.	La Transizione in un Journey Builder indica i segnali/trigger/eventi che, quando incontrati, sposteranno un record da uno stato all'altro.
Esempio di Stati e Transizioni.	Stato 1: Richiesta ricevuta Stato 2: Brief dei requisiti creato Transizione tra gli Stati 1 e 2: Crea brief Allega documento Aggiungi una Nota sul requisito Aggiungi Campi Obbligatori: "Prodotto/Servizio richiesto." Ciò significa che, dopo aver ricevuto una richiesta, il passo successivo è verificare e aggiungere i dettagli di contatto corretti. Solo quando i campi Telefono ed email saranno stati forniti, si passerà alla fase successiva "Richiesta coltivata".	Stato 1: Lead creato Stato 2: Lead interessato Transizione (Segnale/evento) tra gli Stati 1 e 2: Email aperta Quando il lead ha "Aperto l'email", che è stata probabilmente inviata come parte dello Stato 1. Quindi l'apertura dell'email è un segnale o evento affinché il CRM riconosca e sposti il potenziale cliente dal punto 1 al punto 2 nel suo percorso.

 

FAQ 

È corretto affermare che, in Zoho CRM, Command Center è un "Blueprint tra più moduli"? 

No. Non è corretto affermarlo, perché Blueprint e Command Center (Journey Builder) sono essenzialmente diversi nei loro obiettivi. È vero che attualmente Blueprint è costruito per un singolo modulo e Command Center può essere costruito tra più moduli. Ma questa è una differenza tecnica e solo per questa differenza non si può presumere che Journey Builder sia un Blueprint tra più moduli, perché entrambi sono progettati per risolvere problemi diversi. 

1. Blueprint è pensato per l'ottimizzazione dei processi interni e la conformità.
   Anche se Blueprint dovesse presto essere costruito tra più moduli, continuerà ad occuparsi della conformità, quindi il suo funzionamento sarà diverso da quello di un Journey Builder.
   
2. Mentre Journey Builder aiuta principalmente a orchestrare una serie di azioni di coinvolgimento pianificate attraverso i punti di contatto aziendali.
   Anche se fosse costruito per un singolo modulo, comprenderà trigger e azioni di coinvolgimento e non requisiti di dati come nel caso di un Blueprint. 
   

In cosa differisce Journey Builder da Cadence Studio?

1. Cadence Studio può essere visto come un sottoinsieme del Journey Builder. 
   
2. Se la Sua esigenza è SOLO ottimizzare le azioni di follow-up - ovvero utilizzare una combinazione di Email, Attività e Chiamata per seguire un potenziale cliente fino al raggiungimento della risposta desiderata - allora utilizzi Cadence Studio. 
   
3. È possibile ottenere lo stesso risultato anche in Journey Builder, tuttavia potrebbe essere più laborioso in Journey Builder, ora che Cadence Studio La aiuterà a realizzare l'orchestrazione dei follow-up in pochissimo tempo. L'associazione di email, attività o chiamata, basata su una precedente apertura, clic o rimbalzo è più fluida e gestita direttamente nell'interfaccia di Cadence Studio, senza dover configurare meticolosamente questi trigger in Journey Builder. 
   
4. In questo modo può anche trasferire tutta l'orchestrazione del coinvolgimento basata sui follow-up dal Journey Builder a Cadence Studio e utilizzare efficacemente Journey Builder per concentrarsi maggiormente sulle azioni di coinvolgimento dedicate dopo un follow-up riuscito. 
   
5. Cadence Studio è efficace durante la gestione dei lead fino a quando il Suo potenziale cliente è coinvolto. Journey Builder potrebbe essere più efficace per continuare il coinvolgimento dopo il primo contatto riuscito e procedere a ottimizzare il percorso fino all'acquisto, alla fidelizzazione, alla lealtà e alla promozione. 

In cosa differisce Kiosk Studio da Wizards? Kiosk Studio è una soluzione di gestione dei processi? 

Kiosk Studio e Wizards sono entrambe soluzioni per personalizzare il Suo account Zoho CRM. Kiosk Studio è essenzialmente una soluzione di personalizzazione che aiuta a personalizzare i flussi dell'interfaccia utente per eseguire processi ad-hoc. È una piattaforma no-code per creare il proprio widget all'interno del quale è possibile eseguire azioni personalizzate come inserimento dati, recupero, automazione e così via. Mentre Wizards è una soluzione di personalizzazione specifica che si concentra sull'esperienza dei dati.

Wizards attualmente gestisce la creazione di un record in modo sistematico suddividendo un modulo lungo e disordinato in segmenti o "schermate" più ragionati, rendendo l'inserimento dei dati un'esperienza meno confusa e persino piacevole. È possibile salvare un record come bozza e tornarci quando si hanno più dettagli a disposizione. Ad esempio, ha un lead al telefono e sta cercando di spiegargli il Suo prodotto. Alcuni campi del lead come i dettagli sui requisiti, il background aziendale ecc. non Le sono chiari durante la chiamata. Quindi può semplicemente salvare il record come bozza e tornarci quando ha tutti i dettagli e poi pubblicare il record nel sistema. Pertanto, Wizards si concentra sul raggiungimento di questa flessibilità nell'esperienza dei dati nel CRM. È inoltre possibile automatizzare gli avvisi.  Scopra di più>> Documento di aiuto

Mentre Kiosk non riguarda solo l'inserimento o il recupero dei dati ma va anche oltre - può aiutare con l'inserimento dati, il recupero, l'esecuzione di avvisi, funzioni personalizzate e altre azioni di routine. Soprattutto, può essere distribuito in una posizione comoda nel Suo CRM come la scheda Home, la Vista Elenco o la Vista Dettaglio e persino lo spazio Impostazioni. Può utilizzarlo per recuperare record selezionati e aggiornare informazioni specifiche da più moduli all'interno di un singolo widget, può usarlo come script per le chiamate e personalizzarlo praticamente come desidera nella Sua organizzazione.

Scopra di più >> Documento di aiuto

Ecco un semplice Kiosk per un'azienda chiamata Zylker Travels. Immagini che un agente di viaggio sia al telefono con un cliente. Il cliente desidera riprogrammare rapidamente il suo viaggio. Potrebbe essere difficile per l'agente navigare nel modulo corretto e aggiornare i campi giusti. Quindi Zylker ha creato un Kiosk, senza l'aiuto di uno sviluppatore, per creare un widget personalizzato e lo ha distribuito nella Home page, così che l'agente possa accedervi rapidamente, interagire con il widget, aggiornare solo i campi pertinenti e navigare un flusso UI flessibile e semplicissimo specifico per la propria organizzazione. 

Ecco come appare la configurazione di un Kiosk:

Un Blueprint, Journey Builder e un flusso Cadence possono tutti eseguire i loro flussi senza problemi?