Questo articolo è una traduzione assistita dall’AI dell’originale in inglese, revisionata dall’autore.
Il cliente ancora in attesa quando si cambia piattaforma
Immaginate un retailer che lunedì mattina sposta il suo programma di customer engagement su una nuova CEP. I template sono stati ricostruiti, i profili importati, i trigger collegati e i primi invii di test approvati. Nel tracker della migrazione il journey post-acquisto è verde, perché il sostituto ha gli stessi messaggi, le stesse condizioni e gli stessi tempi di attesa.
Una cliente ha comprato un cappotto venerdì. Ha ricevuto la conferma d’ordine e aspetta il messaggio sulla cura del capo, che il vecchio journey invia sette giorni dopo l’acquisto. Un altro cliente ha comprato lo stesso cappotto un mese fa e ha già completato la sequenza. Entrambi i profili arrivano nella nuova piattaforma con la data di acquisto e le informazioni corrette sul prodotto: resta da capire cosa succede a ciascuno dei due.
L’esempio è costruito, ma è la domanda che metterei nel piano di migrazione prima di contare quanti journey sono stati ricostruiti. Se la nuova piattaforma vede due clienti con lo stesso attributo di acquisto, la differenza tra loro (uno aspetta un’azione, l’altro l’ha già ricevuta) deve stare da qualche parte, e un import dei profili riuscito alla perfezione può cancellarla del tutto.
Una migrazione CEP riesce quando la prossima interazione con il cliente resta corretta anche dopo il cutover. Riprodurre la configurazione fa parte del lavoro, ed è di solito la parte più facile da contare; conservare il comportamento di un sistema già in movimento richiede invece un altro inventario.
Nei pattern architetturali CDP-CEP ho separato la responsabilità sui dati cliente da quella di decidere e agire. La migrazione rende evidente questa separazione, perché il profilo si può spostare mentre la posizione operativa del cliente resta indietro.
Il 20 ottobre 2026 Salesforce ha firmato un accordo definitivo per acquisire Braze, con closing previsto nell’anno fiscale 2028 di Salesforce e ancora soggetto all’approvazione degli azionisti e delle autorità. Finché l’accordo non si chiude nulla deve muoversi, ma i clienti di Marketing Cloud Engagement e di Braze si chiederanno cosa significherebbe un consolidamento, e ho già letto l’accordo da architetto. Qualunque cosa dica la roadmap, il resto dipende da cosa ogni azienda decide di spostare e da quanta cura mette con i clienti già a metà di un percorso.
Lo stato del cliente dietro il canvas del journey
Il canvas dice cosa il programma potrebbe fare, mentre il sistema in esecuzione sa anche cosa ha già fatto, cosa sta aspettando e cosa non deve ripetere. Trattarle come un unico export fa sembrare la migrazione molto più semplice di quanto sia.
I dati di profilo descrivono il cliente: identificativi, preferenze, acquisti, attributi e il contesto di business che il livello di engagement usa. Lo stato di esecuzione descrive invece una specifica partecipazione a uno specifico processo: la versione del journey in cui il cliente è entrato, il ramo preso, lo step corrente, l’evento che l’ha avviato e la scadenza di un’attesa. Una persona può partecipare a più processi, e a volte più volte allo stesso, quindi un singolo campo “stato del journey” difficilmente descrive tutto ciò che conta. La distinzione tra ciò che è successo e ciò che è vero adesso attraversa ogni journey, e in una migrazione confonderle diventa costoso.
Lo storico dei contatti sta a cavallo tra i due. Sapere che un’email è stata inviata può decidere se un altro journey è eleggibile, se una regola di pressione consente il messaggio successivo o se un test ha già esposto il cliente al trattamento. Una soppressione può nascere da una preferenza attuale, da un errore di consegna precedente, da una regola di business o da un blocco operativo temporaneo, e ciascuna ha bisogno di un responsabile e di un significato che sopravviva allo spostamento.
“Sette giorni dopo l’acquisto” è una scadenza precisa, calcolata da un evento preciso. Se l’attesa riparte da zero all’import, la scadenza si sposta; se l’acquisto viene rigiocato, la sequenza può ripetersi; se lo si ignora, si evitano duplicati ma la cliente resta senza il messaggio sulla cura del capo. Ogni scorciatoia cambia qualcosa che il cliente nota.
L’assegnazione ai test aggiunge un’altra dipendenza. Se la vecchia piattaforma ha messo un cliente nel gruppo di controllo, riassegnarlo nella nuova ne cambia l’esposizione e il significato dei risultati. Può servire conservare l’assegnazione originale, oppure chiudere il test e avviarne uno nuovo con una finestra di misurazione dichiarata. È una decisione di misurazione da prendere con chi si occupa di analytics, prima che la migrazione la prenda da sola in fase di implementazione.
Per l’inventario chiederei, per ogni programma attivo, quale fatto può cambiare la prossima azione: così il lavoro resta circoscritto. Una vecchia variabile tecnica senza effetti può essere irrilevante, mentre una piccola lista di clienti che hanno già ricevuto un incentivo di benvenuto può essere decisiva. Conservare ogni oggetto storico è un progetto diverso dal conservare ciò che serve per continuare in sicurezza.
Cosa portare, cosa ricostruire, cosa chiudere
Fatto l’inventario, ogni journey attivo ha bisogno di una destinazione. Le opzioni vanno scritte nel piano, con un responsabile e una condizione di completamento, altrimenti le decide per caso la piattaforma di destinazione.
La prima opzione è lasciare che i partecipanti attuali completino il percorso sulla vecchia piattaforma, mentre i nuovi ingressi partono sulla nuova. Adobe Journey Optimizer documenta una distinzione utile: chiudere un journey ai nuovi ingressi permette a chi è già dentro di proseguire, mentre fermarlo interrompe il loro avanzamento. In Marketing Cloud Engagement, fermare un journey in Journey Builder espelle allo stesso modo tutti i contatti ancora presenti. Ogni prodotto ha le sue regole, ed è per questo che “spegnere il vecchio journey” non basta come istruzione.
Completare sul posto permette di conservare uno stato di esecuzione complesso senza tradurlo, ma prolunga la dipendenza dal vecchio sistema: integrazioni, supporto, contenuti e gli aggiornamenti dei dati di cui hanno bisogno i partecipanti rimasti, con l’ultimo messaggio pianificato magari a settimane di distanza. Un journey che aspetta un evento esterno richiede una finestra massima di continuazione esplicita, altrimenti la data di dismissione continua a slittare.
La seconda opzione è ricostruire nella destinazione il comportamento residuo. La piattaforma di arrivo potrebbe non consentire l’import di una posizione di esecuzione interna, e non darei mai per scontato che lo faccia. Un percorso di ingresso dedicato alla migrazione può invece usare fatti dichiarati, come l’evento di qualificazione originale, le azioni già completate e la scadenza residua. È una continuazione progettata da capo, e va testata come tale.
La terza opzione è chiudere deliberatamente la vecchia partecipazione. Alcune sequenze promozionali non servono più dopo lo spostamento, e portarle avanti può costare più del valore che hanno per il cliente. Chiuderle è difendibile quando la conseguenza è chiara; interrompere un obbligo di servizio, o lasciare senza responsabile un follow-up atteso, richiede tutt’altra valutazione.
Le scelte possono cambiare all’interno dello stesso programma. Gli acquisti recenti possono completare sul posto, i clienti in attesa di un follow-up con una data possono essere ricostruiti, i record vecchi rimasti incompleti possono essere chiusi e i nuovi acquisti entrare nella nuova piattaforma. Conta che le coorti siano distinguibili e coprano tutta la popolazione senza sovrapposizioni né buchi inspiegati, perché un cliente che cade tra due regole di migrazione resta comunque un cliente di cui qualcuno deve rispondere.
Due CEP, un solo diritto di contattare il cliente
La coesistenza si descrive di solito per sistemi: vecchia piattaforma, nuova piattaforma, integrazioni in mezzo. Trovo più utile descriverla per permessi di agire: quale piattaforma può inviare quale interazione a quale cliente, e in quale periodo.
Dividere solo per cliente può essere troppo grossolano, perché una persona può ancora ricevere i contenuti post-acquisto dalla vecchia piattaforma mentre la nuova le manda una campagna di lifecycle. Dividere solo per journey può far perdere di vista un limite di contatto condiviso. Il confine reale può combinare programma, coorte e scopo dell’interazione, con un identificativo stabile che colleghi la vista del cliente nei due sistemi.
La gestione della pressione diventa particolarmente scomoda, perché una piattaforma può applicare solo lo storico che conosce. Braze documenta un frequency cap applicato agli invii di campagne e di componenti Canvas e configurato all’interno di un workspace. Spostare altrove una parte del programma crea un bisogno di coordinamento fuori da quel controllo locale, e due cap corretti presi singolarmente possono consentire un carico complessivo che il business non ha mai voluto: è lo stesso punto cieco di cui ho scritto guardando a ciò che il frequency cap non vede.
Lo stesso vale per le preferenze: se durante la coesistenza un cliente revoca il consenso sulla vecchia piattaforma, la modifica deve arrivare ovunque l’interazione possa ancora essere eseguita. È un requisito operativo, quindi il progetto deve definire le regole su preferenze e policy insieme ai team che ne sono responsabili. Un import iniziale non basta a tenerla allineata nel tempo.
Per una sovrapposizione breve possono bastare esclusioni condivise e una regola di instradamento chiara. Una coesistenza più lunga può giustificare un registro dei contatti comune o un servizio decisionale. Sceglierei il meccanismo in base alla latenza richiesta e al comportamento in caso di guasto, e ci andrei cauto prima di introdurre un’altra piattaforma permanente solo perché due sistemi sono attivi per un periodo.
Resta da capire cosa succede quando il coordinamento si interrompe. Se il flusso condiviso delle preferenze non è disponibile, il progetto deve dire se un’interazione promozionale aspetta, si ferma o usa uno snapshot recente esplicitamente autorizzato, e chi riceve l’allarme. Vanno decise nel disegno della coesistenza, perché altrimenti il cliente subirà il default lasciato dall’implementazione. È poi lo stesso criterio che ho proposto per valutare l’accordo Salesforce-Braze dal lavoro che elimina: eleggibilità e tempi richiedono un responsabile esplicito, chiunque sia il proprietario delle piattaforme, e una migrazione rende visibile quella responsabilità una coorte alla volta.
Dimostrare il cutover con gli esiti per il cliente
Conteggi dei record e confronti tra template provano che parti dello spostamento sono arrivate, ma non dimostrano che il cliente giusto riceva la prossima interazione giusta.
Costruirei un piccolo insieme di storie rappresentative attorno ai rischi reali della migrazione. Per il programma post-acquisto: un cliente in attesa del messaggio sulla cura del capo, uno che l’ha già ricevuto, uno con l’ordine annullato, uno che ha cambiato preferenze e uno il cui evento di acquisto arriva in ritardo. Ogni storia ha una prossima azione attesa, un’azione che non deve avvenire e, dove serve, una scadenza.
Il test deve seguire la storia attraverso il confine: guardando solo la destinazione si perde il messaggio ancora pianificato nella sorgente, e guardando i due canvas senza i record dei partecipanti non ci si accorge che un journey ricostruito ha azzerato l’attesa. Un’esecuzione controllata su identità di test dovrebbe dimostrare il risultato combinato, mentre il confronto in produzione dovrebbe all’inizio evitare di generare contatti in più.
I tempi richiedono criteri di accettazione propri. Un comportamento equivalente non sempre richiede tempi identici al secondo, ma la tolleranza va concordata. Un messaggio sulla cura del capo in ritardo di qualche ora può essere accettabile; un’offerta a tempo inviata dopo la scadenza è un altro esito. Dire genericamente che la sincronizzazione è quasi in tempo reale non risolve nessuno dei due casi.
Qui torna la conclusione della sintesi delle Field Notes. Il vincolo ricorrente è la capacità dell’organizzazione di governare la velocità con cui una piattaforma può agire, e una migrazione concentra il problema in un periodo breve, in cui più sistemi possono agire e tutti hanno fretta di dichiarare il lavoro concluso.
Il rollback parte da ciò che è già successo
Un piano di rollback che ripristina la vecchia configurazione è incompleto dal momento in cui la nuova piattaforma ha contattato clienti reali. I messaggi consegnati fanno parte del nuovo stato delle cose, e riaprire la sorgente senza tenerne conto può ripetere un incentivo, far ripartire una sequenza o compromettere un test che la migrazione doveva proteggere.
Il cutover richiede quindi un registro delle azioni completate durante la sovrapposizione, legate al cliente e all’interazione a cui si riferiscono. Il registro deve distinguere un’azione pianificata, una richiesta inviata per la consegna, un’esecuzione confermata e un esito non risolto. Se la destinazione è andata in timeout dopo aver accettato un invio, trattare il risultato come un fallimento certo può generare un duplicato quando la vecchia piattaforma riparte.
Il ripristino va provato proprio su questa ambiguità, perché il team sappia cosa può riconciliare, quali azioni può ritentare in sicurezza e quali richiedono un’indagine. La domanda utile sul rollback è se l’assetto ripristinato sia in grado di prendere la prossima decisione corretta con le informazioni disponibili adesso.
La dismissione ha condizioni simili. I partecipanti hanno completato il percorso o ricevuto una destinazione esplicita, preferenze e storico dei contatti sono stati riconciliati, le integrazioni dipendenti hanno un responsabile e i dati necessari per la conservazione e la misurazione concordate restano accessibili. Un conteggio a zero dei journey attivi aiuta, ma da solo non basta a dimostrare tutto questo.
La cliente del cappotto non ha motivo di sapere che il retailer ha cambiato piattaforma. Il messaggio sulla cura del capo dovrebbe arrivare come il programma ha promesso, senza una sequenza di benvenuto ripetuta e senza sparire a metà della relazione.
È questa continuità il risultato della migrazione che difenderei in uno steering committee.
La nuova piattaforma è pronta quando può ereditare la prossima decisione senza dimenticare l’ultima.
Fonti
Adobe Journey Optimizer
- Adobe Experience League, Journey ending. Documenta la differenza tra chiudere un journey ai nuovi ingressi e fermarlo.
Salesforce Marketing Cloud Engagement
- Salesforce Help, Stop a Journey. Documenta che fermare un journey in Journey Builder ne interrompe le attività ed espelle tutti i contatti.
Braze
- Braze documentation, Rate limiting and frequency capping. Documenta le regole di frequency capping del workspace e la loro applicazione agli invii di campagne e componenti Canvas.
L’accordo tra Salesforce e Braze
- Salesforce, Salesforce Signs Definitive Agreement to Acquire Braze. Annuncia l’accordo e il closing previsto nell’anno fiscale 2028 di Salesforce, soggetto all’approvazione degli azionisti di Braze e delle autorità.
