Come automatizza sui campi del CRM di proprietà di un altro sistema?

01Il problema di business

Per la maggior parte delle organizzazioni di una certa dimensione, il CRM non è il sistema di riferimento per i fatti che contano di più dal punto di vista commerciale. Se un abbonamento viene pagato, quando termina il contratto, quante licenze sono concesse, quanto ha speso il cliente fino a oggi, se il suo accesso è attualmente sospeso: tutto questo appartiene alla fatturazione, al provisioning, a un ERP. Arriva nel CRM per replica.

Eppure quasi ogni automazione che sta davvero a cuore all'azienda si ramifica proprio su quei campi. Il promemoria di rinnovo, l'avviso di abbandono, l'escalation "questo account è diventato silenzioso", il report sui ricavi, la previsione dei rinnovi: tutti dipendono da dati che il CRM non ha prodotto e non può verificare.

Così l'azienda chiede al CRM di essere autorevole su cose che si limita a ripetere. È un'architettura perfettamente ragionevole, ed è quella normale. La domanda è che cosa si debba fare diversamente a causa sua.

Detto francamente: la sua automazione del CRM ha una dipendenza che non può vedere, non può testare e di cui non verrà informata quando si rompe.

02Perché l'approccio ovvio non funziona

L'approccio ovvio consiste nel sincronizzare il campo e poi usarlo esattamente come si userebbe un campo digitato da una persona. Quattro cose vanno storte, in ordine di gravità crescente.

Il campo è scrivibile, quindi qualcuno ci scrive

Un addetto all'assistenza vede una data di fine abbonamento che sembra sbagliata e la corregge. Resta corretta per circa un giorno. Il ciclo di replica successivo la sovrascrive, in silenzio, e ora la cronologia delle modifiche registra una persona che ha fatto una modifica annullata da una macchina per ragioni che nessuno ha documentato. Peggio ancora, nell'intervallo tra le due, l'automazione è scattata sul valore corretto a mano.

Un campo rispecchiato che chiunque può modificare non è uno specchio. È una seconda fonte di verità senza alcuna riconciliazione.

L'automazione si ramifica direttamente sul vocabolario upstream

Viene naturale scrivere il processo come "quando lo stato upstream diventa Cancelled, eseguire il lavoro di disdetta". Lo faccia in venti punti e l'enum del sistema upstream è diventato l'API pubblica del suo CRM.

Abbiamo visto un singolo campo di stato replicato letto da più di una dozzina di processi distinti. Quando il sistema upstream aggiunge un valore (e lo farà, perché è un sistema vivo con una propria roadmap), ognuno di quei processi instrada silenziosamente il nuovo valore verso quello che capita essere il suo ramo di ripiego. Di solito quel ramo è "non fare nulla", che non produce alcun errore né alcuna traccia che qualcosa sia stato perso.

Un campo che cambia non equivale all'evento che accade

Quando un campo replicato cambia, ciò che si è appreso è che la sincronizzazione è stata eseguita. Il timestamp della modifica è l'ora della replica, non l'ora dell'evento di business. Se il suo processo reagisce scrivendo Date lost = today, ha registrato la data in cui il CRM lo ha scoperto, non la data in cui il cliente se n'è andato.

Con una sincronizzazione giornaliera sana quella discrepanza è di un giorno e nessuno se ne accorge. Dopo un'interruzione è pari alla durata dell'interruzione, applicata a tutti i record interessati in una volta, e finisce nella reportistica sugli abbandoni.

Un campo che non cambia non equivale al fatto che non succeda nulla

È questo il caso che fa danni veri, ed è l'argomento del §6. L'automazione attivata dalle modifiche non ha alcun concetto di "avrebbe dovuto cambiare". Quando il sistema upstream smette di inviare, il livello di automazione del CRM non si degrada, non va in errore e non avvisa. Tace, e questo è indistinguibile da una settimana tranquilla.

03Modello dati: tre livelli, non uno

La soluzione è smettere di trattare "il campo" come una cosa sola. Lo suddivida in tre livelli con proprietari diversi e regole diverse.

Livello 1: campi rispecchiati (di proprietà dell'integrazione)

Una copia alla lettera del valore upstream. Di sola lettura per ogni ruolo, amministratori compresi, nel funzionamento normale. Contrassegnata da una convenzione di denominazione, così che chiunque legga un processo, un modulo o un report capisca a colpo d'occhio che questo valore viene dall'esterno: un suffisso o prefisso coerente nell'etichetta è sufficiente, e vale più di una documentazione che nessuno apre.

Questi campi esistono per essere letti. Nulla nel CRM dovrebbe mai scriverli.

Livello 2: stato derivato (di proprietà del CRM)

Un insieme volutamente ridotto di campi che esprimono ciò che il CRM ritiene vero sull'account, nel vocabolario del CRM stesso: uno stato del ciclo di vita, una data in cui il rapporto è terminato, le date di rinnovo su cui l'azienda pianifica. Quali fatti meritino un campo di livello 2 è la domanda che affronta il Blueprint 003.

Questo è il livello su cui si ramifica la sua automazione. Ogni processo a valle (il promemoria, il report, l'escalation, il filtro della dashboard) legge il livello 2. Soltanto una manciata di processi di mappatura legge il livello 1.

Il vantaggio è esattamente quello di qualsiasi adattatore: quando il vocabolario upstream cambia, si modificano i processi di mappatura e nient'altro. Il costo è che il livello 2 può divergere dal livello 1, ed è per questo che il §7 riguarda in gran parte la riconciliazione.

Livello 3: campi sullo stato di salute della sincronizzazione

Due campi che riguardano la replica stessa anziché il cliente:

• Un timestamp dell'ultima sincronizzazione sul record, così che qualsiasi processo possa chiedersi quanto siano freschi i suoi input.
• Un flag di replica completata che il sistema upstream imposta quando ha finito di scrivere il contenuto di un record.

Il secondo è il più interessante, e risolve un problema reale di ordinamento: veda il §5.

Alternative scartate

• Ramificarsi direttamente sul livello 1 ovunque. Scartata qui sopra. Lega l'intero parco di automazioni all'enum di qualcun altro.
• Rendere modificabili i campi rispecchiati "così l'assistenza può correggerli". Possono già correggerli, nel sistema che ne è proprietario. Modificare lo specchio produce una correzione che sopravvive fino alla sincronizzazione successiva e una cronologia delle modifiche che mente.
• Sincronizzare all'indietro così che il CRM diventi autorevole. Un'architettura legittima, e un progetto molto più grande con un proprio disegno per la risoluzione dei conflitti. Non è un rimedio a questo problema; è un problema diverso. Se oggi non ha una riscrittura verso il sistema upstream, non si lasci convincere da questo blueprint a inventarla.
• Ricalcolare lo stato derivato in lettura, in un campo formula. Allettante, ed elimina del tutto il problema della divergenza. Elimina però anche la possibilità di registrare quando si è entrati in uno stato, che è ciò di cui ha bisogno la maggior parte della reportistica, e non può fare da trigger per nulla.

04Configurazione a livello di campo

Due note sui tipi. Mantenga la copia rispecchiata nello stesso tipo del valore upstream anziché convertirla in ingresso: uno stato rispecchiato come testo e mappato su un dropdown nel livello 2 fallisce in modo evidente quando compare un nuovo valore, mentre un dropdown replicato può scartare un valore assente dal suo elenco di opzioni senza alcun errore. Non abbiamo testato che cosa faccia la sincronizzazione in quel caso, quindi non si costruisca su nessuno dei due esiti. E renda i marcatori di idempotenza campi o tag, non stato dedotto: alla domanda "l'abbiamo già inviato?" deve poter rispondere un filtro, non un ragionamento sulle date.

05Automazione e logica

Prima derivare, poi ramificare

Un processo di mappatura per ciascun campo upstream. Il suo unico compito è tradurre il livello 1 nel livello 2. Ogni processo di mappatura termina con un ramo per i valori non mappati: una condizione finale che intercetta tutto ciò che i rami precedenti non hanno intercettato, la cui azione è notificare a un amministratore che è comparso un valore non riconosciuto.

Quest'ultimo ramo è l'assicurazione più economica di tutto il blueprint. Trasforma un instradamento errato e silenzioso (l'esito predefinito quando un sistema upstream aggiunge un valore enum) in un messaggio.

Attivi il processo sul flag di completamento, non sul contenuto

Quando i campi di un record vengono scritti dalla replica, non arrivano tutti nello stesso istante. Una logica di processo che si attiva su un campo e ne legge altri cinque può scattare su un record scritto a metà e ramificarsi su un misto di valori nuovi e vecchi.

Lo schema che lo risolve: faccia impostare al sistema upstream un flag di replica completata come ultima scrittura del lotto di un record, e attivi il processo su quel flag, leggendo i campi del contenuto come condizioni anziché come trigger. Il processo gira allora una sola volta, dopo che il record è coerente.

Vale la pena costruirlo anche dove oggi la sincronizzazione sembra atomica, perché costa un campo ed è la differenza tra "funziona" e "funziona sotto carico".

Fonte. Centro assistenza Coevera, Automatizer — creating and running processes, per i tipi di trigger su cui si può costruire un processo. Ciò che non tratta, e che questo blueprint tratta, è quale di essi sia sicuro da puntare su un campo scritto da un altro sistema.

Rilevi le contraddizioni e le inoltri a una persona

Un sistema upstream emette combinazioni non valide. Non perché sia costruito male, ma perché due sistemi con orologi indipendenti e percorsi di modifica indipendenti producono stati in disaccordo, e alcuni di questi stati sono di quelli che le sue regole di business dicono impossibili:

• Una data di fine è valorizzata mentre lo stato risulta ancora attivo.
• Lo stato risulta annullato ma non è arrivata alcuna data di fine.
• Una data di inizio cambia su un abbonamento attivo da un anno.
• Un record è contrassegnato contemporaneamente come sospeso e come pagato.

Costruisca un processo per ciascun caso. La sua azione non è correggere i dati: il CRM non ne è proprietario e qualsiasi correzione viene sovrascritta al ciclo successivo. La sua azione è notificare a un ruolo designato la contraddizione specifica e il punto specifico in cui va corretta a monte.

Trattare il rilevamento delle contraddizioni come una funzionalità anziché come un gestore di errori è la differenza tra un'integrazione di cui ci si fida e una in cui ci si limita a sperare.

Scriva le condizioni come intervalli, sempre, con un controllo di idempotenza

Questa è la regola più importante di tutto il blueprint, ed è quella tratta più direttamente dall'incidente descritto nel §6.

La versione con l'uguaglianza è corretta in ogni giorno in cui la sincronizzazione è sana e sbagliata per sempre nei giorni in cui non lo è, perché la condizione è vera soltanto per un valore e nulla la riesamina in seguito. La versione a intervallo più un marcatore di idempotenza è idempotente e tollerante ai vuoti: esegue il lavoro in ritardo anziché per niente, e lo esegue una sola volta.

Le condizioni di uguaglianza su un campo replicato sono, di fatto, una scommessa che nessuna sincronizzazione verrà mai interrotta. Non è una scommessa che valga la pena fare per i due minuti che costa la versione a intervallo.

Subordini l'esecuzione alla freschezza dei dati, ma fallisca in modo visibile

I processi che agiscono su dati replicati dovrebbero controllare il timestamp dell'ultima sincronizzazione prima di agire. L'implementazione ovvia ("eseguire solo se l'ultima sincronizzazione è recente") nasconde una trappola descritta nel §6, quindi abbini il controllo a un log o a un avviso esplicito sul ramo di rifiuto. Un processo che rinuncia a girare deve dirlo.

06Limiti e compromessi

L'automazione attivata dalle modifiche è silenziosa, non in errore

Nessun processo onChange in ascolto su un campo replicato è scattato, semplicemente perché i campi non sono cambiati. Non esiste uno stato di errore per "atteso un evento che non è mai arrivato". Una settimana senza modifiche agli abbonamenti e una settimana con un'integrazione morta producono log identici.

Non esiste una soluzione lato piattaforma. Il monitor nel §7 non è un di più; è l'unica cosa che può avvisarla.

L'automazione pianificata continua a girare, con sicurezza, su dati obsoleti

È peggio che non girare affatto. I processi giornalieri sono scattati secondo il calendario in ogni giorno dell'interruzione e hanno operato su un'istantanea sempre meno veritiera, saltando account che erano diventati idonei ed elaborando account che non lo erano più. Le email ai clienti con il conto alla rovescia per il rinnovo sono partite calcolate su conteggi di giorni obsoleti: alcuni clienti hanno ricevuto un'email che indicava un numero di giorni sbagliato, altri non hanno ricevuto nulla al traguardo previsto.

Il recupero fa scattare tutto insieme, con il giorno di riferimento sbagliato

Quando la replica è ripresa, giorni di variazioni accumulate sono arrivati insieme e ogni processo attivato dalle modifiche è scattato in un'unica ondata. I valori dei campi erano corretti. Il giorno di riferimento no: ogni processo la cui azione era set date = today ha impresso la data del ripristino su un evento accaduto giorni prima. Le date di perdita, le date di disdetta e le date di chiusura dei record di perdita creati a partire da esse hanno richiesto tutte una correzione manuale in seguito.

Le condizioni di corrispondenza esatta vengono saltate per sempre e senza traccia

La categoria più dannosa, perché non lascia alcuna prova:

• Un processo giornaliero che cerca End Date = yesterday non troverà mai più quegli account. Restano senza alcun marcatore di fine vita, e le dashboard continuano a conteggiarli come attivi a tempo indeterminato.
• Un processo di traguardo che cerca tenure = 13 months vede il contatore saltare da 12 a 14 in una sola scrittura di recupero. Per quegli account non scatta mai, in nessun caso.
• I processi di revisione dei rinnovi che cercano un valore esatto di giorni al rinnovo saltano gli account il cui giorno esatto è caduto nella finestra dell'interruzione.

Nessuno di questi casi produce un errore, un nuovo tentativo o una voce in coda. Producono un report silenziosamente incompleto, scoperto settimane dopo, se mai lo si scopre.

Un controllo di freschezza può disattivare proprio la verifica che protegge

Un processo era condizionato a "eseguire solo se il timestamp dell'ultima sincronizzazione rientra nel periodo corrente", una protezione dall'aria sensata contro l'agire su dati obsoleti. Il timestamp dell'ultima sincronizzazione è però anch'esso un campo replicato. Durante l'interruzione ha smesso di avanzare, così il controllo è risultato falso per ogni account e il processo non ha fatto assolutamente nulla, per nessuno, compresi gli account di cui avrebbe dovuto sorvegliare le soglie.

Un controllo su un campo replicato non può distinguere tra "i dati sono obsoleti" e "i dati vanno bene ed è l'indicatore di obsolescenza a essere obsoleto". Subordini pure l'esecuzione alla freschezza dei dati, ma metta l'avviso sul ramo di rifiuto, altrimenti la protezione diventa essa stessa l'interruzione.

Le differenze rispetto al valore precedente sono anch'esse replicate

Gli avvisi di modifica del tipo "il numero di licenze è passato da X a Y" leggono di solito un'istantanea del valore precedente che è anch'essa sincronizzata. Dopo un vuoto, l'istantanea e il valore attuale possono essere separati da diverse modifiche, così la differenza riportata a una persona è aritmeticamente corretta e fattualmente fuorviante. Verifichi le differenze dopo ogni interruzione anziché fidarsi del testo dell'avviso.

Non c'è garanzia di ordinamento né transazionale, e non si può far attendere il CRM

L'automazione dei processi su questa piattaforma non è transazionale e non offre alcuna garanzia di ordinamento tra record. Non si può esprimere "trattenere questo processo finché la sincronizzazione non è completa", ed è per questo che il trigger sul flag di completamento in §5 è uno schema e non un'impostazione. Né si può rieseguire un processo attivato dalle modifiche per un periodo in cui non è scattato; il ripristino consiste in una query e in una riesecuzione manuale o massiva, ed è per questo che il §7 insiste perché quelle query vengano scritte prima che servano.

Il compromesso che sta accettando

Il modello a tre livelli le offre il disaccoppiamento e lo paga con la duplicazione. Il livello 2 può divergere dal livello 1, e lo farà: per le interruzioni, per errori di mappatura, per modifiche manuali fatte durante un ripristino. Sta accettando un obbligo di riconciliazione in cambio di un parco di automazioni che non va in frantumi quando un enum upstream cambia.

Vale la pena accettare questo scambio, a una condizione: che la derivazione sia rieseguibile. Un processo che ricalcola l'intero livello 2 dal contenuto attuale del livello 1, su richiesta, per un insieme filtrato di record, è la cosa singola più preziosa da costruire qui. È il suo strumento di ripristino, il suo strumento di migrazione e il suo banco di prova. Lo costruisca insieme alla mappatura, non dopo il primo incidente.

07Verifica

L'oggetto della verifica qui non è "l'automazione funziona?": ha funzionato, per tutta la durata dell'interruzione, ed era proprio questo il problema. È "il CRM riesce a capire quando i suoi input hanno smesso di essere veri?".

• Costruisca per primo il monitor di freschezza della sincronizzazione. Un processo pianificato, con una cadenza più breve della sua tolleranza al vuoto, che legge il timestamp di ultima sincronizzazione più recente tra i record e lancia un avviso se è più vecchio di una soglia. Non deve dipendere a sua volta da alcun campo replicato diverso dal timestamp. Senza di esso, l'unico rilevatore di interruzioni del CRM è una persona che nota che un report sembra strano, ed è ciò che è accaduto.
• Scriva le query di riconciliazione prima che servano. Per ciascun campo derivato, una query salvata che trova i record in cui il livello 2 è in disaccordo con ciò che il livello 1 implica: record con stato attivo che riportano una data di fine; abbonamenti terminati senza marcatore di fine vita; stati del ciclo di vita che nessuna combinazione attuale di campi rispecchiati produrrebbe. Le esegua secondo un calendario, e dopo ogni interruzione nota. Uno stato derivato che nessuna query di riconciliazione sa spiegare è il segnale di regressione.
• Testi il vuoto, non il percorso felice. In uno spazio di test, metta in pausa il flusso, lasci girare i processi pianificati per diversi cicli, riprenda con un recupero in lotto e poi controlli tre cose: che cosa è scattato, che cosa avrebbe dovuto scattare e non l'ha fatto, e quali date sono state impresse. Ogni risultato del §6 è riproducibile in questo modo, che è l'unico modo per sapere se il suo parco di automazioni ne è affetto.
• Registri i rifiuti. Quando un controllo di freschezza rifiuta, lo registri. "Non ha fatto nulla perché i dati erano obsoleti" e "non ha fatto nulla perché non c'era nulla da fare" devono essere distinguibili a posteriori, e per impostazione predefinita non lo sono.
• Controlli il giorno di riferimento dopo ogni ripristino. Cerchi i record le cui date di evento coincidono con la data del ripristino e confronti ciascuno con il sistema upstream. Un gruppo di eventi di business tutti datati allo stesso giorno è l'impronta di un'ondata di recupero, non una coincidenza.
• Riesegua la derivazione e ne confronti l'esito. Il processo di ri-derivazione del §6 funge anche da verifica: lo esegua su un campione, confronti il prima e il dopo e si accerti che nulla cambi. Tutto ciò che cambia è una divergenza che non sapeva di avere.

Che cosa segnalerebbe una regressione: qualsiasi condizione di uguaglianza su un campo replicato che compare in un nuovo processo; un contatore di traguardi o di notifiche che resta piatto in un periodo in cui il volume non è cambiato; qualsiasi campo data in cui un numero significativo di record condivide lo stesso valore; un processo di mappatura privo di un ramo finale per i valori non mappati.

Blueprint correlati

• Blueprint 003 — Come modella qualcosa per cui il suo CRM non ha un oggetto? La domanda preliminare. Decidere che cosa il CRM debba possedere in assoluto è ciò che determina quanta parte del suo parco di automazioni finisce nel livello 1.
• Blueprint 008 — Come prevede rinnovi che non esistono ancora come record? Le date di rinnovo sono i campi replicati più comuni in assoluto, e i meccanismi di previsione descritti lì si trovano direttamente a valle di questo schema.
• Blueprint 005 — Come migra i contatti da un altro sistema senza perdere dati senza accorgersene? La versione una tantum della stessa disciplina: riconciliare ciò che è arrivato con ciò che è stato inviato, anziché fidarsi del report di caricamento.