Workflow e Blueprint in Zoho CRM: perché la scelta conta
Workflow e Blueprint in Zoho CRM sono i due strumenti con cui si automatizza e si governa il lavoro all'interno del CRM, e la scelta fra i due incide direttamente su come i Suoi commerciali lavorano ogni giorno. In sintesi, una regola di workflow esegue azioni in automatico quando un record soddisfa determinate condizioni. Un Blueprint, invece, accompagna l'utente lungo un processo a fasi e gli impedisce di saltare i passaggi obbligatori.
La confusione tra i due strumenti è diffusa anche tra chi usa Zoho da tempo. Nella community ufficiale un utente ha chiesto che cosa distingua workflow, journey e Blueprint, osservando che tutti e tre vengono presentati come strumenti per automatizzare i processi del CRM. Un altro utente, alle prime armi, ha chiesto se esista una vera e propria «regola» per decidere quando usare l'uno o l'altro, e nella discussione pubblicata non compare alcuna risposta.
Questa guida prova a colmare quella lacuna. Definisce i termini, riassume la decisione in una tabella, segue un esempio concreto sul modulo delle trattative e raccoglie gli errori di configurazione più frequenti. Se sta ancora impostando il sistema, conviene leggerla insieme alla nostra checklist di configurazione di Zoho CRM prima della messa in produzione.
Che cos'è una regola di workflow
Una regola di workflow è un'automazione legata a un modulo del CRM, per esempio Leads o Deals. Si compone di tre elementi: un evento scatenante (trigger), una o più condizioni sui campi del record e le azioni da eseguire. Il trigger può essere la creazione o la modifica di un record, oppure una data: in questo secondo caso l'azione parte in un momento definito dopo un evento, come la creazione del lead.
Le azioni disponibili coprono la maggior parte delle attività ripetitive:
- invio di un'email o di una notifica;
- creazione di un'attività (task) assegnata a un utente;
- aggiornamento di un campo;
- chiamata di un webhook, cioè l'invio automatico dei dati a un indirizzo web di un altro sistema;
- esecuzione di una funzione personalizzata scritta in Deluge, il linguaggio di scripting di Zoho;
- aggiunta di un tag al record.
Una singola regola può eseguire più azioni insieme. Il punto essenziale è che nessuno deve intervenire: se la regola dice «una settimana dopo la creazione del lead invia questa email», l'email parte senza che un utente acceda al CRM o prema un pulsante.
Il limite è altrettanto importante. Una regola di workflow reagisce a ciò che è già successo, ma non lo impedisce. Può aggiornare un campo e inviare un'email quando lo stato di una trattativa cambia, ma non può bloccare quel cambiamento se mancano informazioni. Per imporre un controllo serve un altro strumento.
Che cos'è un Blueprint: stati, transizioni e le tre sezioni
Zoho descrive il Blueprint come la funzione che aiuta a far rispettare processi standard su larga scala. Il processo si disegna con un editor visivo e, per ogni fase, si stabilisce che cosa l'utente deve fare, automatizzando al tempo stesso le azioni standard.
Stati e transizioni
Un Blueprint si appoggia a un campo a elenco (picklist), di solito il campo Stage del modulo Deals. Ogni valore del campo diventa uno stato, per esempio Qualification, Needs Analysis o Closed Won. Una transizione è il passaggio che sposta il record da uno stato all'altro. Una transizione comune è visibile da qualunque stato ed è tipica per esiti come Closed Lost.
Le tre sezioni di ogni transizione
- Before: stabilisce se la transizione compare per un certo utente e un certo record, per esempio solo per un determinato profilo.
- During: è la lista guidata di ciò che l'utente deve compilare o creare, come campi obbligatori, attività o voci di checklist. Le voci di checklist del Blueprint non sono attività del CRM.
- After: esegue automazioni simili alle azioni di workflow, una volta completata la transizione.
Con i criteri di ingresso si decide quali record entrano nel Blueprint. Quando una trattativa vi entra, il campo Stage si blocca e l'utente può avanzare solo con i pulsanti di transizione. Se non ha ancora tutte le informazioni, può salvare la transizione come bozza. Zoho indica inoltre che il Blueprint serve a evitare che un lead o una trattativa restino fermi troppo a lungo in una fase, e che i report integrati mostrano dove gli utenti spendono più tempo e dove il processo si blocca.
La differenza decisiva e la tabella per scegliere
Entrambi gli strumenti definiscono condizioni e fanno scattare azioni, per questo si confondono. La differenza vera è un'altra: la regola di workflow agisce da sola quando le condizioni sono soddisfatte, mentre il Blueprint richiede che un utente compia un'azione deliberata prima che il record possa avanzare. Il primo automatizza, il secondo guida e controlla.
La tabella seguente parte dall'esigenza concreta e indica lo strumento adatto, compresi quelli vicini che spesso vengono sostituiti a torto da un workflow o da un Blueprint.
| Esigenza | Strumento | Perché |
|---|---|---|
| Inviare un'email o creare un'attività quando un record cambia | Regola di workflow | Non serve alcuna decisione umana |
| Eseguire un'azione a una data, per esempio una settimana dopo la creazione del lead | Regola di workflow con trigger temporale | L'azione dipende dal tempo, non da una persona |
| Impedire che una trattativa avanzi senza i dati obbligatori | Blueprint, sezione During | Il workflow non può bloccare un cambio di stato |
| Riservare la chiusura vinta a un responsabile | Blueprint, sezione Before | La transizione compare solo per un profilo |
| Far approvare uno sconto da un responsabile | Approval process | Serve un'approvazione formale e tracciata |
| Condurre una sequenza di email e telefonate su più passaggi | Cadences | Gestisce il ritmo del contatto nel tempo |
| Assegnare il record all'utente o al team giusto | Regole di assegnazione | Si attivano alla creazione o modifica del record |
| Ripetere un'azione su calendario fisso, ogni giorno o ogni settimana | Funzione pianificata in Deluge | Non dipende da un singolo record |
Se l'esigenza contiene le parole «impedire», «obbligare» o «solo chi», la risposta è quasi sempre un Blueprint. Se contiene «avvisare», «ricordare» o «aggiornare», è quasi sempre una regola di workflow.
Un esempio completo sul modulo Deals
Prendiamo un'azienda che vende impianti con trattative che durano alcune settimane e vuole due cose: che nessuna trattativa avanzi senza i dati minimi e che l'amministrazione sia avvisata subito quando un contratto viene chiuso. Ecco come impostare il processo, con i nomi dei menu nella versione inglese dell'interfaccia.
- Creazione: in Setup, nella sezione Process Management, si apre Blueprint e si crea un nuovo processo sul modulo Deals, scegliendo il campo Stage. Come criterio di ingresso si limitano le trattative a quelle create da oggi in poi, così le vecchie non vengono coinvolte.
- Da Qualification a Needs Analysis: nella sezione During si rendono obbligatori i campi che l'azienda considera indispensabili, per esempio importo stimato e data di chiusura prevista.
- Da Needs Analysis a Proposal: nella sezione During si chiede di creare un'attività di follow up; nella sezione After si aggiorna un campo che segnala che l'offerta è stata inviata.
- Da Proposal a Closed Won: nella sezione Before si rende la transizione visibile solo al profilo Sales Manager.
- Closed Lost come transizione comune: disponibile da ogni stato, con il motivo della perdita come campo obbligatorio.
- Regola di workflow parallela: sul modulo Deals, trigger alla modifica del record, condizione Stage uguale a Closed Won, azioni: email all'amministrazione e attività di avvio commessa per il responsabile di progetto.
Il risultato è una divisione chiara dei compiti. Il Blueprint garantisce che la trattativa arrivi alla chiusura con i dati completi e con l'autorizzazione giusta. La regola di workflow si occupa delle conseguenze, senza che nessuno debba ricordarsene. Prima di pubblicare, conviene far provare il processo a un gruppo ristretto di commerciali.
| Passo | Che cosa si imposta | Dove |
|---|---|---|
| 1. Creazione del processo | Blueprint sul modulo Deals, campo Stage | Setup, sezione Process Management |
| 2. Criterio di ingresso | Solo le trattative create da oggi in poi | Impostazioni del Blueprint |
| 3. Da Qualification a Needs Analysis | Campi indispensabili resi obbligatori | Sezione During della transizione |
| 4. Chiusura con Closed Won | Avviso immediato all'amministrazione | Sezione After della transizione |
| 5. Esito negativo | Transizione comune verso Closed Lost | Visibile da qualunque stato |
Come combinare workflow e Blueprint senza conflitti
I due strumenti convivono bene se ciascuno ha un compito preciso. Il principio più utile è questo: il Blueprint è il proprietario del campo Stage, le regole di workflow svolgono il lavoro di contorno. Una transizione del Blueprint modifica il record e può quindi far scattare le regole di workflow che creano attività, inviano email o aggiornano campi.
Proprio qui nascono i conflitti. Se la stessa email è configurata nella sezione After di una transizione e anche in una regola di workflow sul cambio di stato, il cliente o il collega la ricevono due volte. Se una regola scritta prima del Blueprint continua a modificare gli stessi campi che la transizione chiede di compilare, i dati inseriti dall'utente possono essere sovrascritti senza che nessuno se ne accorga.
Per questo, nei progetti Svennis, prima di pubblicare un Blueprint verifichiamo una per una le regole di workflow già attive sullo stesso modulo e decidiamo per ogni azione un unico punto in cui vive. L'errore che incontriamo più spesso non è un Blueprint sbagliato, ma una vecchia regola dimenticata che continua a scattare sui campi del processo.
Un secondo punto di attenzione riguarda le modifiche successive. Quando si ripubblica un Blueprint, Zoho propone diverse opzioni per i record che vi si trovano già, e una di esse può farli uscire dal processo in modo definitivo. Legga sempre quelle opzioni prima di confermare, soprattutto se ha trattative aperte in fasi avanzate.
| Blueprint | Regola di workflow | |
|---|---|---|
| Chi avvia l'azione | L'utente, con un passaggio deliberato | Il sistema, quando le condizioni sono soddisfatte |
| Campo Stage | Lo fa avanzare tramite le transizioni | Reagisce al cambio di stato |
| Dati minimi per fase | Li rende obbligatori nella sezione During | Aggiorna campi in automatico |
| Email, attività e webhook | Nella sezione After, se non già previsti da una regola | Li esegue quando il record cambia |
| Primo utilizzo consigliato | Un solo modulo, di solito Deals, con poche fasi | Notifiche interne, follow up e promemoria |
Cadences, approvazioni e gli altri strumenti vicini
Molti problemi di configurazione nascono dal forzare un workflow o un Blueprint a fare il lavoro di un altro strumento. Zoho CRM ne offre diversi, ciascuno pensato per un'esigenza precisa.
Approval process e My Jobs
Zoho definisce l'approval process come uno strumento di automazione dei processi che consente di automatizzare le approvazioni nell'organizzazione. My Jobs è la vista unica da cui il responsabile approva le richieste. Quando serve la firma di un manager, per esempio su uno sconto, questa è la strada più pulita rispetto a una transizione del Blueprint costruita a mano.
Cadences
Le Cadences gestiscono sequenze di contatto su più passaggi, alternando email e telefonate nel tempo. Sono adatte a chi deve seguire molti lead in modo costante, e sostituiscono con vantaggio una catena di regole di workflow temporali difficile da mantenere.
Regole di assegnazione e Layout Rules
Le regole di assegnazione attribuiscono automaticamente il record all'utente o al team corretto quando viene creato o modificato. Le Layout Rules guidano invece la compilazione dei moduli mostrando le informazioni giuste al momento giusto. Zoho ha annunciato per le Layout Rules nove nuove azioni, l'esecuzione in base al profilo e un'anteprima interattiva, disponibili per tutti gli utenti. Se il Suo problema è solo mostrare o nascondere campi, spesso bastano queste, senza costruire un Blueprint.
Gli errori di configurazione più frequenti
Gli errori si ripetono con una certa regolarità, indipendentemente dal settore. Quasi tutti derivano dall'aver progettato il processo come dovrebbe essere, anziché come il team commerciale lavora davvero.
- Troppa ingegneria: troppe diramazioni, troppi passaggi obbligatori e un processo che non corrisponde al modo in cui si vende. Gli utenti lo aggirano o smettono di aggiornare il CRM.
- Aspettarsi un blocco da un workflow: una regola può reagire a un cambio di stato, non impedirlo. Se il controllo è necessario, serve un Blueprint.
- Azioni duplicate: la stessa notifica configurata sia nella sezione After sia in una regola di workflow.
- Nessun criterio di ingresso: tutte le trattative, anche quelle vecchie o di tipo diverso, finiscono nel processo.
- Checklist scambiate per attività: le voci di checklist del Blueprint non sono attività del CRM, quindi non vanno usate per ciò che deve comparire tra le attività dei commerciali.
- Ripubblicazione frettolosa: scegliere l'opzione sbagliata per i record già presenti e farli uscire dal processo in modo definitivo.
- Nessuna prova e nessuna formazione: pubblicare per tutti senza un test con un gruppo ristretto e senza spiegare agli utenti perché certi campi sono diventati obbligatori.
La regola pratica è semplice: meno fasi, meno obblighi, ciascuno con una motivazione che un commerciale capisce. Un Blueprint che il team accetta vale più di uno perfetto che il team evita.
Cosa automatizzare per primo e cosa mai
Chi inizia tende a voler automatizzare tutto subito. Conviene invece procedere per gradi, partendo dalle attività che non richiedono giudizio e che oggi qualcuno esegue a mano ogni giorno. È il principio alla base di qualunque progetto di automazione dei processi.
Da automatizzare per primo
- notifiche interne quando un record cambia stato;
- creazione di attività di follow up ricorrenti;
- assegnazione dei nuovi lead all'utente o al team corretto;
- promemoria legati a una data, come la scadenza di un'offerta.
Solo dopo, con queste regole stabili, ha senso introdurre un Blueprint su un unico modulo, di solito Deals, con poche fasi.
Da non automatizzare mai
- la qualificazione di un lead e la chiusura di una trattativa, che richiedono una valutazione umana;
- lo spostamento automatico del campo Stage da parte di una regola, che svuota di significato il Blueprint;
- l'invio di email automatiche a contatti non verificati, che sporca il database e danneggia la reputazione del dominio.
Zoho ha introdotto in Zoho CRM agenti nativi che consentono di configurare le impostazioni in linguaggio naturale. Anche quando una regola viene creata con l'aiuto dell'intelligenza artificiale, va letta e verificata come qualunque altra prima di attivarla.
Cosa significa per un'azienda italiana
Molte aziende italiane vendono attraverso agenti, rivenditori e distributori, con margini di trattativa sul prezzo che il titolare o il direttore commerciale vuole controllare. In questa situazione la combinazione più utile è quasi sempre la stessa: un Blueprint che impone i dati minimi a ogni fase, un approval process per gli sconti oltre una certa soglia e regole di workflow per gli avvisi.
Un secondo tratto comune è la dimensione del team. In una piccola o media impresa la stessa persona spesso vende, prepara l'offerta e segue la consegna. Un Blueprint con dieci fasi e venti campi obbligatori, pensato per una grande organizzazione, rallenta proprio chi ha meno tempo. Meglio tre o quattro fasi con nomi che il team usa già nel linguaggio quotidiano.
Nella manifattura, dove l'offerta dipende da specifiche tecniche e la chiusura avvia una commessa, il Blueprint aiuta a garantire che l'ufficio tecnico e la produzione ricevano informazioni complete. Nella nostra pagina su Zoho CRM per la manifattura trova come impostiamo questi flussi nel settore. Il consiglio vale però per qualunque azienda: prima di aprire l'editor, scriva su un foglio le fasi reali della vendita e chi è autorizzato a far avanzare la trattativa in ciascuna.
Prossimi passi concreti
Se vuole mettere ordine tra workflow e Blueprint nel Suo CRM, può procedere in questo ordine:
- Inventario: elenchi tutte le regole di workflow attive, con modulo, trigger e azioni. Spesso emergono regole duplicate o non più necessarie.
- Mappa del processo: descriva su carta le fasi di vendita reali e, per ciascuna, i dati indispensabili e chi può farla avanzare.
- Scelta dello strumento: usi la tabella di questa guida per attribuire ogni esigenza a workflow, Blueprint, approval process, Cadences o regole di assegnazione.
- Un solo modulo: costruisca il primo Blueprint su Deals, con poche fasi e criteri di ingresso chiari.
- Prova e formazione: lo faccia usare a un gruppo ristretto, raccolga le difficoltà e spieghi al team il motivo di ogni campo obbligatorio.
- Revisione: dopo alcune settimane consulti i report del Blueprint per vedere dove le trattative si fermano e semplifichi di conseguenza.
Se preferisce affidare progettazione e verifica a chi lo fa ogni giorno, sulla pagina dedicata all'implementazione di Zoho CRM trova come lavoriamo e come richiedere un primo confronto. Se la Sua azienda usa anche strumenti di marketing e assistenza, valuti la suite Zoho CRM Plus, dove le stesse logiche di automazione si estendono ad altri reparti.
