Automazioni in azienda: quando una regola NON deve partire

Quasi tutti i testi sull’automazione spiegano cosa può far scattare una regola. La domanda difficile è un’altra: quando è meglio che non faccia niente. Una regola che parte troppo spesso scrive a clienti che non aspettano nulla, e dopo due settimane qualcuno la spegne. Qui c’è la struttura che lo evita, e come si capisce, dopo, se una regola lavora davvero o sembra soltanto.

Una regola è fatta di quattro pezzi

Il nome. È la parte che si sottovaluta di più. Fra sei mesi starà in un elenco con altre venti, e chi lo legge deve capire senza pensarci cosa fa quella regola. “Notifica 3” non lo dice.

L’evento. Una regola non aspetta un orario: aspetta che succeda qualcosa nel lavoro di tutti i giorni, cioè che un record venga creato, modificato o eliminato. Insieme all’evento va detto dove: “nasce un ticket” è un’altra cosa rispetto a “cambia un preventivo”.

Le condizioni. Il cuore, e la parte che si salta più volentieri. Senza condizioni la regola parte a ogni evento. Con “priorità uguale ad alta” parte sui ticket che interessano. La differenza fra un’automazione utile e una che viene spenta sta quasi sempre qui.

Le azioni. Cosa succede dopo: un’email, un avviso al gruppo, un messaggio WhatsApp, un’attività da fare, un campo aggiornato, una riga nello storico. Più di una, in fila, è ammesso.

Prima di attivarla: la prova a vuoto

Prima di accendere una regola conviene provarla a vuoto. La prova valuta le condizioni e dice se sarebbero state soddisfatte e quante azioni sarebbero partite, senza che nessuno riceva niente. È il pulsante che toglie la paura di attivare, ed è l’unico modo serio di collaudare una regola che manda email a clienti veri.

Perché “saltata” non è un errore

Dopo qualche giorno la domanda interessante non è se la regola è attiva, ma cosa ha fatto davvero. Per rispondere serve un registro, e quel registro deve tenere distinti tre esiti:

• Riuscita — il lavoro è stato fatto: l’email è partita, l’avviso è arrivato.
• Saltata — l’evento c’era, ma la condizione non era vera, oppure al record mancava proprio il dato (un ticket aperto al telefono, senza l’email del cliente). Lì la regola non doveva partire.
• Errore — qualcosa è andato storto, e il motivo è scritto: nessun destinatario indicato, credenziali sbagliate, un campo che un’automazione non può modificare.

Molti programmi conoscono solo “eseguita” e “fallita”. Il risultato è che il registro di una regola perfettamente sana si riempie di righe rosse perché su venti ticket la condizione non era soddisfatta, e l’unico errore vero in mezzo non lo nota più nessuno. Chi valuta un software dovrebbe chiedere esattamente questo: una condizione non soddisfatta viene mostrata come una decisione o come un guasto?

Cosa un’automazione non dovrebbe toccare

Una regola che può sovrascrivere qualunque campo è un rischio, non uno strumento. Ha senso un elenco fisso di campi scrivibili: stato, assegnatario, priorità, una nota. Totali, giacenze, valori contabili e chiavi non ci stanno dentro: quelli li cambia una persona, o un’operazione con un documento dietro.

Altrettanto importante: una regola che scrive non deve poter richiamare se stessa. Senza un freno, un’automazione che aggiorna un campo si ripesca all’infinito da sola.

Come lo fa Blina Desk

In Blina Desk i quattro passi si compilano in una schermata sola, in quest’ordine, con la prova a vuoto in fondo. Le azioni sono un elenco chiuso invece di un accesso libero al database, e i campi aggiornabili sono decisi in partenza.

Il registro tiene separate riuscita, saltata ed errore, con il motivo scritto in chiaro: così si vede a colpo d’occhio se una regola non lavora o semplicemente non doveva. E poiché le automazioni sono dell’azienda e non della singola persona, è la direzione a decidere quali regole sono attive e chi può personalizzarle.

Alla fine la prova per qualsiasi software di automazione è sempre la stessa: non quanti modelli porta in dote, ma se fra due mesi riuscirai ancora a capire perché una regola, un martedì mattina, non è partita.