Approvazione di sconti e contratti in Zoho CRM: come funziona in sintesi
L'approvazione di sconti e contratti in Zoho CRM richiede tre elementi. Il primo è una soglia misurata su un campo preciso del preventivo. Il secondo è un controllo che blocca il salvataggio quando la soglia viene superata. Il terzo è un approvatore con un sostituto. Lo storico serve poi a dimostrare chi ha deciso, quando e perché.
Un flusso di approvazione è una sequenza di regole che trattiene un record finché una persona autorizzata non lo accetta o lo respinge. Il record può essere un preventivo, un ordine di vendita o un contratto. Il flusso deve fermare solo le eccezioni. Le trattative standard devono proseguire senza attese, altrimenti il commerciale impara ad aggirare il sistema.
Questa guida segue l'ordine in cui conviene decidere: cosa bloccare, a quale soglia, con quale meccanismo, chi approva, cosa registrare e quali errori evitare. I meccanismi tecnici descritti provengono dalla documentazione e dalla community di Zoho. Le indicazioni di progetto sono indicate come tali. Se il Suo CRM non è ancora in produzione, conviene leggere prima la checklist di configurazione di Zoho CRM prima del go-live, perché ruoli e campi vanno definiti prima delle approvazioni.
Cosa bloccare: sconti oltre soglia e contratti non standard
Un flusso di approvazione efficace blocca due sole categorie di record: gli sconti oltre una soglia e i contratti con condizioni non standard. Tutto il resto deve passare senza intervento. Più ampio è il perimetro, più lunga diventa la coda di approvazioni e meno attenzione riceve ogni singola richiesta.
Uno sconto oltre soglia è una riduzione di prezzo superiore al limite che il commerciale può concedere da solo. Un contratto non standard è un accordo che si discosta dalle condizioni predefinite. Ne sono esempi un pagamento a rate, una durata diversa o una clausola concordata a parte.
In Zoho CRM i contratti passano spesso dall'ordine di vendita. Un Sales Order (ordine di vendita) è il documento che conferma l'acquisto. Un utente della community Zoho osserva che, nella prassi commerciale, un Sales Order firmato equivale a un contratto. Lo stesso utente nota che gli ordini hanno spesso un periodo di durata. Quel periodo si gestisce bene solo se il sistema tratta l'ordine come contratto, come discusso nel thread Sales Order e Contracts nella community Zoho.
La conseguenza pratica riguarda il punto di controllo. Gli sconti vanno verificati sul preventivo. Le condizioni contrattuali vanno verificate sul documento che diventa contratto, di solito l'ordine. Un solo controllo sul preventivo lascia passare le modifiche fatte dopo.
Soglie di sconto: su quale campo misurarle, con un esempio
La soglia di sconto va misurata su un campo preciso e documentato del preventivo. Non basta un'idea generica di "sconto alto". Prima di configurare qualsiasi regola, scriva quale campo viene confrontato e se il valore è una percentuale o un importo.
Un esempio dalla community Zoho mostra perché la scelta conta. In un preventivo il prezzo di listino è di 1000 dollari per articolo. Lo sconto è del 10% e vale 500 dollari sul totale. Il totale finale è di 4500 dollari.
Nello stesso esempio, l'utente voleva mostrare anche il prezzo unitario dopo lo sconto, cioè 900 dollari. Non trovava però un modo per farlo né con i workflow personalizzati né con i Price Books (listini prezzi). Il caso è descritto nel thread prezzo per articolo dopo lo sconto.
Lo stesso sconto si legge quindi in tre modi: 10%, 500 dollari, 900 dollari a pezzo. Una regola che confronta la percentuale tratta allo stesso modo un ordine piccolo e uno grande. Una regola che confronta l'importo dello sconto ferma soprattutto gli ordini di valore elevato. Come scelta di progetto, le consigliamo di fissare una soglia percentuale per proteggere il margine.
Alla soglia percentuale può aggiungerne una sull'importo per gli ordini più grandi. Entrambe le soglie devono leggere un campo che il commerciale non può riscrivere a mano.
Bloccare il salvataggio del preventivo con un Client Script
Un Client Script è un codice che Zoho CRM esegue nel browser durante l'uso di una pagina. Con un Client Script si può impedire il salvataggio di un preventivo che non rispetta una regola. Un suggerimento pubblicato nella community Zoho descrive questo schema per un problema vicino: creare o collegare una trattativa al salvataggio del preventivo.
Nel caso descritto, i commerciali creavano preventivi senza la trattativa collegata, e la reportistica ne soffriva. Lo script controlla al salvataggio se esiste una trattativa collegata. Se manca e il preventivo supera un importo stabilito, compare un popup. L'utente può creare una trattativa o collegarne una esistente. Finché non lo fa, il preventivo non si salva.
I passaggi indicati dall'autore sono questi:
- Aprire Settings > Client Script e scegliere "New Script", con nome e descrizione.
- Impostare Category: Module, Page: Create Page (Standard), Module: Quotes.
- Definire un evento di pagina attivato da
onSave.
L'autore suggerisce uno script per ciascuna azione: creazione, modifica e clonazione. In alternativa si può usare una risorsa statica richiamata una sola volta. Lo stesso schema, cioè controllo al salvataggio, soglia e blocco, si adatta a uno sconto oltre soglia. Questa è una scelta di progetto, non una funzione pronta.
L'autore del suggerimento avverte anche che il blocco non insegna ai commerciali il comportamento corretto. La formazione resta quindi necessaria.
Approvatori e sostituti: chi decide quando il responsabile è assente
Ogni livello di approvazione ha bisogno di un approvatore titolare e di un sostituto definito in anticipo. Senza sostituto, una sola assenza blocca tutte le offerte in attesa. Il commerciale cercherà allora una scorciatoia, per esempio dividere lo sconto su più righe per restare sotto soglia.
Zoho applica questa logica nell'app Incentives for Zoho CRM, dedicata alle provvigioni. L'app permette di assegnare utenti, ruoli o gruppi che approvano, respingono o delegano le provvigioni. È disponibile per le edizioni Enterprise e Ultimate, per Zoho CRM Plus e per Zoho One, per ora senza costi aggiuntivi. Richiede la nuova interfaccia di Zoho CRM e al momento non funziona nell'app mobile, come indicato nell'annuncio di Incentives for Zoho CRM. Se sta valutando l'edizione, la pagina su Zoho CRM Plus in Italia riassume cosa comprende la suite.
Per sconti e contratti valgono tre criteri di progetto:
- assegnare l'approvazione a un ruolo, non a una persona, così un cambio di organico non rompe il flusso;
- indicare per iscritto il sostituto di ogni ruolo e il periodo in cui può decidere;
- separare i livelli: il responsabile commerciale per gli sconti, la direzione o l'amministrazione per le condizioni contrattuali.
Storico delle approvazioni sulla scheda: cosa registrare per le verifiche
Lo storico delle approvazioni deve stare sulla scheda del record approvato, non in una email o in una chat. Durante una verifica interna, chi controlla apre il preventivo o l'ordine e deve trovare subito la risposta. Deve sapere chi ha chiesto l'eccezione, chi l'ha concessa, quando e con quale motivazione.
Come scelta di progetto, le suggeriamo di registrare sulla scheda almeno questi dati:
- il valore che ha fatto scattare l'approvazione, per esempio la percentuale di sconto;
- il nome di chi ha approvato o respinto, anche quando è il sostituto;
- la data della decisione;
- una motivazione breve, obbligatoria in caso di sconto o condizione non standard.
Lo storico deve restare coerente quando il record cambia. Il suggerimento della community citato sopra, nella sua prima parte, non aggiorna la trattativa in quattro casi. Sono il preventivo segnato come vinto, la modifica del subtotale, la presenza di più preventivi e l'aggiunta di una nota. Per questi casi l'autore rimanda a un workflow.
Per lo stesso motivo, un'approvazione registrata va invalidata se lo sconto aumenta dopo la decisione. Altrimenti lo storico attesta una decisione presa su numeri diversi.
Errori di configurazione più frequenti e come correggerli
Gli errori più comuni nascono da regole che controllano il campo sbagliato o il momento sbagliato, non da limiti del CRM. In Svennis, prima di attivare un blocco sugli sconti, facciamo provare la regola a un commerciale. Il test usa un preventivo reale sotto soglia e uno sopra soglia, perché l'errore che incontriamo più spesso presso i clienti è una soglia confrontata con un campo diverso da quello che l'azienda intendeva.
La tabella riassume gli errori da controllare, il loro effetto e la correzione.
| Errore | Effetto | Correzione |
|---|---|---|
| Soglia sulla percentuale quando conta l'importo, o il contrario | Si fermano gli ordini sbagliati | Scrivere il campo esatto prima di configurare |
| Controllo solo alla creazione del preventivo | Lo sconto aumentato in modifica passa senza verifica | Coprire creazione, modifica e clonazione |
| Approvatore indicato per nome | Ferie o uscite bloccano la coda | Assegnare a un ruolo, con sostituto |
| Importi copiati a mano su altre schede | Valori che divergono dal preventivo | Aggiornare i campi in automatico dal record di origine |
| Approvazione non invalidata dopo una modifica | Lo storico non corrisponde ai numeri | Annullare l'approvazione se il valore cambia |
Il quarto errore compare in un thread della community sulla relazione tra preventivo e trattativa. Il team inseriva a mano gli importi delle trattative e delle fatture sulle schede Account. L'obiettivo era che l'importo della fattura si aggiornasse da solo quando il preventivo passava ad accettato.
Cosa significa per un'azienda italiana con agenti e listini
Per un'azienda italiana, il flusso di approvazione serve soprattutto a governare la discrezionalità di chi vende fuori sede. Agenti, distributori e area manager negoziano spesso con il cliente davanti. Un flusso lento li spinge a promettere condizioni che il CRM non registra. Un flusso rapido e limitato alle eccezioni porta invece quelle condizioni dentro il sistema.
Le soglie vanno scritte con chi conosce il margine reale. Nella manifattura, lo sconto accettabile dipende dal costo di produzione e dal volume. Nell'agroalimentare dipende spesso dalla stagione e dal canale. Le pagine su Zoho CRM per la manifattura e su Zoho CRM per l'agroalimentare descrivono come impostare il CRM in questi settori.
C'è poi il passaggio al gestionale. Se gli ordini approvati proseguono verso un ERP, l'approvazione deve avvenire prima dell'invio. Una correzione a valle costa di più di un blocco a monte. Per chi usa SAP Business One, l'integrazione tra SAP Business One e Zoho CRM è il punto in cui verificare che passino solo ordini con approvazione registrata.
Prossimi passi per impostare le approvazioni nel Suo Zoho CRM
Il primo passo è scrivere le regole su un foglio, prima di toccare la configurazione. Le decisioni sulla carta richiedono meno tempo delle correzioni dopo il rilascio.
- Elenchi i casi da bloccare: sconti oltre quale percentuale o importo, e quali condizioni contrattuali sono non standard.
- Per ogni caso indichi il campo esatto del preventivo o dell'ordine che viene confrontato.
- Assegni ogni livello a un ruolo e scriva il sostituto.
- Decida quali dati dell'approvazione restano sulla scheda e quando un'approvazione viene annullata.
- Provi la regola con due preventivi reali, uno sotto e uno sopra soglia, in creazione, modifica e clonazione.
- Spieghi ai commerciali il perché della regola, perché il blocco da solo non cambia le abitudini.
Quando le regole sono scritte, può confrontarle con il modo in cui è configurato oggi il Suo sistema. Se preferisce farsi affiancare, la pagina sull'implementazione di Zoho CRM in Italia descrive come lavoriamo su progetti di questo tipo.
