L'automazione sul cambio stage è una decisione, non un trigger

Un deal passa a Won. Dietro al CRM un workflow si sveglia e costruisce quello che viene dopo: un progetto, una cartella, una sequenza di onboarding, un task per chi si occupa della delivery. Quasi sempre funziona.

La domanda di design è cosa fa il giorno in cui non riesce a capire cosa è stato venduto davvero.

Quasi tutte le automazioni sul cambio stage rispondono tirando a indovinare, perché quella domanda non gliel’ha mai posta nessuno. Il trigger parte, il workflow percorre l’unica strada che conosce, e un cliente nuovo passa la prima settimana dentro una struttura di progetto pensata per un altro tipo di lavoro. Nessun errore. Nessun alert. L’automazione ha fatto esattamente quello che le era stato detto, su un presupposto che nel frattempo aveva smesso di essere vero.

Questo è il percorso dell’altro design: un cambio stage che porta con sé una decisione, un sistema che si va a prendere il contesto da solo prima di agire, e due guardie il cui unico compito è fermarsi quando non sanno. Uso il workflow di Novrith come esempio concreto, quello che trasforma un deal chiuso in un progetto di delivery, perché è quello di cui ho dovuto digerire i fallimenti. Gli strumenti sono Attio, n8n e ClickUp. Il pattern è il punto; quelli sono solo il posto dove lo si vede girare.

Il trigger non ti dice quasi niente

Vale la pena costruire su un cambio stage per un motivo solo: è l’unico momento in cui tutti, a valle, sono d’accordo che qualcosa è vero. Quell’accordo è anche tutto quello che il trigger porta con sé. Chiamiamolo effetto collaterale innescato dallo stage: un’automazione che parte da un cambio di stato invece che da un form o da uno scheduler.

L’errore è trattare quel momento come un’istruzione. Non lo è. È la notifica che forse esiste un’istruzione.

Il nostro payload è volutamente scarno. Attio chiama POST /webhook/attio-deal-won e manda esattamente un campo: { record_id }. Non il nome del deal, non l’azienda, non l’importo, non cosa è stato venduto. Un identificativo.

Sembra una dimenticanza ed è l’opposto. Un payload di cambio stage è quello che il CRM si trovava in mano nel microsecondo in cui lo stage è scattato, modellato da una mappatura che qualcuno ha configurato mesi fa. Il workflow lo butta via e va a leggersi il record: recupera il deal da Attio, segue la relazione verso l’azienda, si costruisce il quadro dalla fonte.

Due chiamate API prima di qualsiasi logica, qualche centinaio di millisecondi. Quello che compri è un workflow che sa cosa dice il deal adesso, non cosa diceva la mappatura del webhook l’ultima volta che qualcuno l’ha toccata.

La logica è leggere cosa è stato venduto

Una volta recuperato il deal, l’automazione deve rispondere a una domanda prima di poter costruire qualsiasi cosa: di quale struttura ha bisogno questo ingaggio?

Da noi la risposta vive in un campo single-select sul deal che si chiama service, le cui opzioni codificano tre cose insieme. Revenue Engine - Scale. Support Add-On - Priority. Operations Engine - Strategic Sessions - 5-Hour Package. Engine, offering e tier, compressi in un titolo di opzione che un commerciale sceglie una volta sola, nel momento in cui sa la risposta.

Il workflow riporta quel titolo alle sue tre parti e ramifica sull’offering, perché è l’offering a determinare la forma di quello che viene costruito:

Core Implementation crea sempre una lista nuova, istanziata da uno dei dodici template engine-tier. Quattro engine, tre tier, e il template porta con sé la struttura a milestone e i deliverable standard, così due ingaggi dello stesso tipo non partono mai diversi.

Automation-as-a-Service riusa una lista esistente se il cliente ce l’ha già, perché questi arrivano in modo ricorrente e non devono frammentarsi in un contenitore nuovo ogni volta.

Strategic Sessions riusa o crea, poi aggiunge una milestone intitolata all’anno e alla dimensione del pacchetto, visto che l’unità tracciata sono ore contro un impegno, non uno scope.

Support Add-On fa lo stesso su base mensile, con il monte ore che deriva dal tier.

La differenza non è cosmetica. Sbagli strada e ti ritrovi un contenitore che non può reggere l’ingaggio: ore tracciate contro uno scope che non ha ore, milestone su un retainer che non ha fasi, un template a scope fisso avvolto attorno a lavoro ricorrente.

Ed è per questo che il lavoro di design non sta in quelle quattro strade. Sta in cosa succede quando non ne vale nessuna.

I due modi in cui si rifiuta di indovinare

Due motivi per cui il sistema può non sapere quale struttura costruire, e meritano risposte diverse, perché a risolverli è una persona diversa.

Il campo è vuoto. Qualcuno ha portato il deal a Won senza registrare cosa è stato venduto. Chi può sistemarlo ha ancora la mano sul mouse, quindi il problema non viaggia: il cambio stage viene annullato, il deal torna da dove veniva, e un popup dice cosa manca. Nessuna coda, nessun passaggio di mano, nessun run dell’automazione. Il deal non è Won finché il record non sa dire cosa vuol dire Won, e la correzione costa cinque secondi perché avviene nel contesto.

Il campo contiene un valore che il parser non sa collocare. Qui, a monte, non ha sbagliato nessuno. Il valore è reale; è il modello di business dentro l’automazione a essersi invecchiato. Non c’è nessuno a cui rimandarlo. Quindi il workflow non ripiega su un default. Non sceglie il template più frequente. Scrive su un canale Slack interno, #ops-handovers, nomina il deal, dice chiaramente che non è riuscito a determinare cosa è stato venduto, e si ferma.

Quella distinzione è tutto il design. Manda il fallimento a chi può davvero risolverlo: il commerciale, subito, nella schermata che sta già guardando, oppure l’operatore, in modo asincrono, con il contesto conservato. Un sistema che manda entrambi sullo stesso canale Slack ha reso il problema facile costoso quanto quello difficile.

Un dettaglio della seconda strada vale la pena rubarlo. Prima di arrendersi, la cartella cliente la crea comunque.

È un’asimmetria voluta. La cartella è identica a prescindere da cosa è stato venduto, quindi crearla non costa niente nemmeno se l’ipotesi fosse sbagliata. La lista codifica la decisione, quindi aspetta una persona. Chi apre Slack dieci minuti dopo parte da una struttura mezza costruita che è corretta per quel che c’è, e prende l’unica decisione che la macchina non poteva prendere.

La forma generale: quando un’automazione non può completare, dovrebbe finire la parte che non dipende da ciò che non sa, e passare a mano la parte che ne dipende.

La strada del passaggio a mano è anche quella che tagliano tutti. Gestisce un caso che non si verifica quasi mai, è la cosa meno gratificante da costruire, e una demo gira benissimo senza. Costruiscila lo stesso, e non per prudenza: ogni altro ramo di questo workflow dà per buono che il parser abbia ragione sul business, e il parser è una lista di titoli di opzione che ho scritto io una volta. Quel ramo è l’unico che non prende il mio stesso modello come dato.

L’output è una struttura, non un record

Quando il parsing va a buon fine, quello che viene creato non è “un progetto”. È una disposizione precisa che altrimenti qualcuno dovrebbe mettere insieme a memoria:

La cartella cliente su ClickUp, creata da template se non esiste e riusata se esiste. La lista di progetto, intitolata prima all’azienda e poi a engine e tier, così quello che un cliente compra dopo finisce accanto a quello che aveva comprato prima. Una milestone tipizzata come milestone vera di ClickUp invece che un task che tutti si sono accordati a trattare come tale. Un owner assegnato. Le date impostate.

Da dove arrivano quelle date è una decisione vera, non un default. Il workflow usa l’orario in cui il webhook è partito, non la close date del deal. Le close date vengono retrodatate durante le pulizie, modificate per far sembrare un trimestre più ordinato, messe al giorno della firma quando la delivery parte settimane dopo. L’orario del run è l’unico timestamp che descrive quello che è successo davvero: questo è girato, adesso.

Uno stage precedente sullo stesso deal innesca un secondo effetto collaterale che avrei definito incondizionato. Quando un deal arriva a Proposal, viene creata una cartella cliente su Google Drive e connessa al record azienda, con dentro la cartella del deal. Quell’automazione ramifica solo sull’esistenza: la cartella c’è già, il collegamento c’è già. Find-or-create, due volte. Una cartella è una cartella.

Solo che la cartella del deal si chiama ITH-0015-26 | Revenue Engine - Scale, e quel suffisso legge lo stesso campo service. Quando ho archiviato i tre vecchi attributi, Attio ha smesso di restituirli, il suffisso si è risolto in una stringa vuota, e il workflow ha continuato a creare cartelle intitolate a nient’altro che un numero di deal, riportando successo a ogni run. L’ho scoperto tre settimane dopo, quando due di quelle cartelle sono state rinominate a mano.

È questa la coppia che vale la pena mettere una accanto all’altra, ed è quello che trasforma un workflow in un pattern. Due effetti collaterali, un campo solo sotto entrambi, e la differenza non è se ramificano. Ramificano tutti e due. Quello su Drive ramifica sull’esistenza, che è l’aspetto che ha l’idempotenza ed è quello che costruiscono tutti. Nessuno dei due ramificava sul significato, e a uno solo era stato insegnato ad accorgersi che non poteva saperlo.

Niente di tutto questo fa risparmiare a qualcuno i cinque minuti che servono a creare una lista. Toglie la possibilità che due ingaggi dello stesso tipo vengano impostati in modo diverso perché li hanno impostati due persone diverse. Se ti interessa il modello sotto quella struttura, l’ho scritto a parte come modello dati del ciclo di vita del progetto; questo pezzo parla della macchina che lo istanzia.

Sono i casi limite a decidere se sopravvive

Ogni automazione fa bella figura in demo. Quello che separa una che dura da una che viene spenta dopo un mese storto sta tutto nei casi che nessuno ha voglia di progettare.

Girare due volte. Un deal può rientrare in Won. Qualcuno lo riapre, corregge un campo, lo rimette, e il workflow riparte. Il nostro guarda prima di scrivere su tre strade su quattro: trova la cartella cliente per nome e la riusa, e le offerte ricorrenti fanno lo stesso con le loro liste. Core Implementation è l’eccezione. Niente scrive l’ID del deal sulla lista che ha prodotto, quindi quel ramo ne costruisce una nuova dal template ogni volta, e un deal Core già completato che rientra in Won lascia un doppione da cancellare. Ovunque altro rilanciare non costa niente, ed è per questo che rilanciare è il recupero. Sapere qual è l’unico punto in cui non vale fa parte del possedere l’automazione.

Completamento parziale. La cartella c’è, la lista no, perché il run si è fermato in mezzo. Il recupero deve essere rilanciare tutto il workflow, non un secondo workflow che finisce quelli lasciati a metà. Quando a luglio la nostra automazione si è rotta, ho prima sistemato il parser, poi ho ripuntato il webhook sullo stesso deal e l’ho lasciato girare da capo a fine. Ha trovato la cartella, l’ha saltata, e ha creato la lista. Una strada sola, percorsa due volte, e pulita solo perché la lista non c’era ancora. Riparare la causa e recuperare lo stato sono due lavori diversi, e solo il secondo dovrebbe essere un rilancio.

Il terreno che si sposta sotto. Questo è quello che ci ha morso davvero, due volte. A giugno ho consolidato tre campi service separati sul record deal nell’unico campo service descritto sopra. Buon cambio, più semplice da compilare, più difficile da sbagliare. Ho aggiornato il CRM e non ho aggiornato nessuno dei due workflow che lo leggono. Otto giorni dopo il primo deal a chiudersi Won è andato a cercare campi che non esistevano più, non ha trovato niente, ed è finito sulla strada del passaggio a mano. Quel giorno l’ho raccontato a caldo. Quello che il post non affrontava è la parte che generalizza.

Nota quale delle due guardie l’ha preso. Non quella sul CRM: dal lato del commerciale non c’era niente di sbagliato, il campo era compilato con un valore che qualsiasi persona avrebbe letto correttamente. A non essere d’accordo era solo il parser. Dal lato dell’automazione, un cambio di schema è indistinguibile da un valore che non le è mai stato insegnato a leggere. Il contratto tra il campo e ciò che lo legge l’ho rotto io, in silenzio, nel corso di un miglioramento, senza nessun test a intercettarlo.

Ambiguità che non è un errore. Un tier che non vendevamo il trimestre scorso, aggiunto al campo del CRM il giorno in cui abbiamo iniziato a venderlo e mai insegnato al parser, non è un dato sbagliato. È business reale che il modello non ha ancora raggiunto. Rimandarlo indietro sarebbe offensivo; il commerciale l’ha registrato correttamente. Va sulla strada del passaggio a mano, e va letto come un invito ad ampliare il modello, non come una riga in un log delle eccezioni che nessuno apre.

Cosa monitorare

Parti dal controllo che intercetta il fallimento che non puoi vedere: dopo che l’automazione ha fatto il suo lavoro, dovrebbe verificare che la cosa per cui esiste esista davvero. Non che il run sia finito. Che il progetto ci sia. Ho sviscerato quel controllo a parte, perché è la prima guardia che aggiungerei a un’automazione di cui ti fidi già.

Quel controllo è per singolo run. A livello di pattern, tre segnali ti dicono se il design regge:

• Quanto spesso scatta ciascuna guardia, e il rapporto tra le due. I cambi stage annullati dovrebbero essere frequenti e noiosi: la gente dimentica i campi, il CRM dice no, li compilano. I passaggi a mano dovrebbero essere rari, e ognuno dice che il business si è spostato dove il modello non arriva ancora. Se il secondo numero sale verso il primo, il parser è rimasto indietro rispetto alle vendite. Se restano entrambi a zero per sempre, non è la vittoria che sembra: c’è un default che sta assorbendo in silenzio input che avrebbero dovuto fermare qualcosa.
• Se i rilanci sono puliti. Fai passare lo stesso deal due volte di proposito, in sandbox, una volta a trimestre. Se ottieni due cartelle, la tua idempotenza si è guastata dall’ultima volta che qualcuno ha controllato, e te ne accorgi durante un incidente invece che durante un test. Se ottieni due liste di progetto, su quel ramo non c’era mai stata.
• L’età della mappatura. La nostra tiene sedici ID di template ClickUp, di cui solo dodici sono la mappa engine-tier, e un parser legato ai titoli esatti delle opzioni di un campo del CRM. Quell’accoppiamento è invisibile finché qualcuno non modifica il campo. Tutto ciò che codifica il vocabolario di un altro sistema ha bisogno di una data sopra e di qualcuno che se lo rilegga quando quel sistema cambia.

Il terzo non ha una dashboard, ed è esattamente per questo che è quello che si rompe.

Sto pubblicando un video di due minuti con questo workflow che gira, incluso il ramo in cui si ferma e chiede una persona. Guardare una macchina che si rifiuta di fare qualcosa è una demo strana, ed è la parte che vorrei vedere io.

Cosa chiedere alla tua automazione sul cambio stage

L’automazione sul cambio stage non è difficile perché è difficile l’integrazione. È difficile perché un cambio stage è un evento che arriva con una decisione attaccata, e quasi tutti i workflow sono scritti come se quella decisione fosse già stata presa. Collegare Attio a ClickUp è un pomeriggio. Quasi tutto quello di cui è fatto davvero un progetto di Automation Engine sono le decisioni costruite attorno a quel pomeriggio.

Quindi la diagnosi, per qualsiasi cosa tu stia già facendo girare: prendi un’automazione e ricostruisci cosa fa quando l’input non è quello che si aspetta. Non cosa fa quando un’API è giù, che probabilmente l’hai già gestito. Cosa fa quando è tutto su, ogni chiamata torna 200, e il dato che sta leggendo non significa più quello che significava quando l’hai scritta.

Se la risposta è che tira dritto, con sicurezza, su un default, non hai un’automazione di cui fidarti. Ne hai una che non ha ancora sbagliato.