Un agente hotel acquisisce una prenotazione diretta. Il workflow mostra verde: API riuscita, conferma preparata, CRM aggiornato. In serata la reception scopre che nel PMS non esiste nessuna reservation.
Il workflow ha concluso. Il processo business no.
La reconciliation serve a trovare questa differenza. Dopo l’esecuzione non si controlla soltanto se ogni step tecnico ha restituito successo: si verifica se lo stato business desiderato esiste davvero nei sistemi autorevoli.
Nella contabilità il principio è normale. Nelle automazioni viene dimenticato perché la UI mostra già una sequenza di check verdi. Ma ogni check descrive il proprio step, non l’intero risultato.
La riconciliazione parte dalla post-condition
Prima bisogna definire cosa significa “finito”.
Per un appuntamento: esiste esattamente un evento nel calendario con cliente, orario e servizio corretti; il CRM contiene l’ID; la conferma cliente fa riferimento allo stesso evento.
Per hotel: reservation ID confermato nel PMS, date e rate corrette, guest record collegato, conferma coerente.
Per follow-up: provider email ha accettato il messaggio, CRM aggiornato e next task presente.
success nel workflow non è una post-condition.
workflow distribuiti possono creare stati parziali; i pattern Saga e le compensating transaction gestiscono processi multi-step in cui non tutto fallisce o riesce insieme.
Raccomandazione: definire per ogni automazione importante uno stato finale verificabile.
Missing, wrong e duplicate
Missing: l’oggetto previsto manca. Un timeout, mapping errato o delete manuale possono esserne la causa.
Wrong: l’oggetto c’è, ma con dato sbagliato: orario, cliente, prezzo, quantità o stato.
Duplicate: l’azione esiste più volte. Qui riconciliazione e idempotenza si sovrappongono.
Attenzione a non confondere questi problemi con l’eventual consistency. Alcuni sistemi propagano i write dopo alcuni secondi o minuti. Controllare troppo presto crea falsi allarmi.
La finestra di check deve seguire il processo: secondi per un pagamento, minuti per un booking, magari fine giornata per una sincronizzazione non urgente.
Il reconciliation job dovrebbe essere noioso
Se bisogna verificare «esiste reservation ID 88421?», non serve una risposta creativa.
Un controllo robusto può fare:
- Salvare intended state nel caso originario.
- Leggere il target dopo il delay appropriato.
- Confrontare la post-condition: esistenza, campi, numero di oggetti e riferimenti.
- Applicare tolleranze note, ad esempio sync delay o arrotondamenti.
- Ricontrollare mismatch temporanei prima dell’escalation.
- Creare un’eccezione con owner, includendo previsto, reale e ultimo step noto.
L’IA può aiutare a sintetizzare log non strutturati. La verifica di ID e campi, quando possibile, è meglio deterministica.
Non riparare automaticamente una modifica umana corretta
Durante un outage una dipendente sposta manualmente il cliente dalle 14 alle 15. Il vecchio job dell’agente ha ancora intended state = 14.
La reconciliation vede differenza. Se rimette automaticamente 14, fa danno.
Servono regole di precedenza: quale modifica è più recente? Chi l’ha fatta? Il caso era in degraded mode? Il campo è sicuro da ripristinare?
Un tag interno può essere corretto automaticamente. Un orario cliente, un prezzo o un pagamento modificati da una persona dovrebbero normalmente creare un’eccezione.
Human handover qui è ristretto: il personale vede solo le differenze che il sistema non può risolvere con certezza.
Un pilota minimo con errori inseriti apposta
Scegliete un workflow che crea un output chiaro. Salvate per ogni caso target ID o business key e fate girare il confronto ogni pochi minuti o a fine giornata.
Eliminate un record di test, modificate un campo, create un duplicato e ritardate intenzionalmente una sync. Il controllo deve distinguere l’errore persistente dal normale delay.
Misurate post-condition soddisfatte, missing/wrong/duplicate rate, false alert, tempo medio di rilevazione, tempo medio di risoluzione e eccezioni con owner assegnato.
La metrica più interessante spesso è quante situazioni business incomplete vengono trovate nonostante il workflow originale le avesse marcate come riuscite.
l’automazione non termina con 200 OK. Termina quando il sistema che fa fede contiene lo stato corretto. La reconciliation è il controllo che rende visibile questa differenza.
La reconciliation funziona meglio quando esiste un ledger minimo dell’intenzione. Al momento dell’azione salvate intended state, business key, target ID se disponibile, timestamp, actor e ultimo stato conosciuto. Senza questa traccia, un controllo successivo vede soltanto differenze ma non sa cosa il workflow voleva ottenere.
La frequenza dipende dall’impatto. Un tag interno può essere controllato a fine giornata; una prenotazione per la sera stessa richiede una verifica molto più rapida. Prevedete anche un grace period per sistemi con sincronizzazione ritardata: altrimenti ogni write corretto diventa temporaneamente un falso allarme.
Separate poi detection da repair. Il sistema può trovare automaticamente quasi tutte le discrepanze, ma non dovrebbe correggere automaticamente ogni campo. Duplicate tecnici o metadati innocui possono avere regole di auto-fix; prezzo, pagamento, orario cliente e modifiche recenti di un dipendente devono normalmente aprire un’eccezione.
L’eccezione deve essere leggibile: cosa era previsto, cosa esiste ora, quale sistema fa fede, chi ha modificato per ultimo e quale azione è proposta. In questo modo l’handover non è “controlla i log”, ma una decisione concreta che una persona può prendere in pochi minuti.
L'idempotenza evita molti doppioni. L'arresto d'emergenza limita l'errore. La riconciliazione prova il risultato.
Fonti
FAQ
Reconciliation e logging sono la stessa cosa?
No. Il log racconta cosa è successo; la reconciliation confronta ciò che doveva succedere con lo stato reale.
Bisogna verificare tutto subito?
No. Tenete conto dei normali tempi di sincronizzazione.
Il sistema può auto-riparare i mismatch?
Solo quelli chiaramente sicuri e reversibili. Stati cliente, prezzi e pagamenti richiedono più cautela.
Serve IA per fare reconciliation?
Non necessariamente. ID e campi strutturati sono spesso meglio controllati con logica deterministica.
Come si collega all’idempotenza?
L’idempotenza evita la doppia esecuzione; la reconciliation rileva risultati mancanti, errati o doppi dopo l’esecuzione.