Immaginate questa situazione: è venerdì pomeriggio. La vostra organizzazione si sta preparando per una migrazione su larga scala della piattaforma di supporto durante il fine settimana. Entro lunedì mattina, i vostri team devono poter accedere ad anni di cronologia dei ticket, dati dei clienti e flussi di lavoro, senza interruzioni o perdita di contesto.
In situazioni come questa, la definizione delle priorità di migrazione diventa fondamentale. Non tutti i record devono essere migrati nello stesso ordine e trattare tutti i dati allo stesso modo può rallentare la transizione. I team di supporto spesso necessitano di accedere immediatamente ai ticket attivi, alle conversazioni recenti, ai clienti prioritari o a gruppi specifici, mentre i dati storici possono continuare a essere migrati in background. Senza una chiara strategia di migrazione e una definizione delle priorità, i team potrebbero trovarsi a gestire dati incompleti, notifiche duplicate o un'inutile pressione operativa durante la fase di messa in produzione.
Una migrazione rapida dell'help desk adotta un approccio più intelligente: la logica a due fasi. Prima rendiamo operativo il tuo team, poi spostiamo silenziosamente i dati storici in background. Non si tratta di perdere dati, ma di migrare nell'ordine corretto.
1. Cosa distingue la migrazione espressa dalla migrazione standard?
Una migrazione standard tenta di spostare tutto in un'unica, complessa operazione: ticket aperti, record chiusi, allegati di grandi dimensioni e log di sistema. Per set di dati di grandi dimensioni, questa singola operazione si protrae facilmente ben oltre la normale finestra temporale di una notte.
Questo crea un periodo di incertezza di diversi giorni. Gli operatori sono costretti a gestire due sistemi contemporaneamente; nessuno sa quale piattaforma contenga la vera fonte di informazioni e gli errori nei dati si accumulano di ora in ora.
Una migrazione rapida dell'help desk elimina questo problema. Tracciando una linea netta tra due cicli di migrazione mirati, questo di migrazione dell'help desk senza tempi di inattività mantiene le code di supporto sempre attive. Nessun blackout di più giorni. Nessun agente lasciato inattivo.
- Passaggio 1: Trasferimento pulito del set di dati minimo indispensabile di cui il tuo team ha bisogno per assistere i clienti fin dal primo giorno. Questo include ticket aperti, ticket in sospeso, contatti, aziende e la tua knowledge base attiva. Poiché questo set di dati rappresenta solo una frazione del tuo archivio totale, il trasferimento si completa facilmente durante la notte.
- Fase 2: L'archivio storico. Tutto il resto, ovvero l'archivio dei ticket chiusi, viene trasferito in fasi gestibili e pianificate dopo che il tuo team è già operativo sulla nuova piattaforma. Nessuna fretta, nessun panico del fine settimana e nessuna interruzione per il tuo supporto quotidiano.
Il tuo team ha completato un passaggio di piattaforma senza intoppi e nei tempi previsti. La cronologia completa dei dati procede in sicurezza sullo sfondo.
1.1 La logica a due runplain
Considerate il Passaggio 1 come una lezione magistrale di "lazy loading". Invece di far aspettare l'utente fino al caricamento di tutti gli elementi pesanti del piè di pagina, degli script di tracciamento e delle immagini di sfondo, renderizzate immediatamente i contenuti essenziali nella parte superiore della pagina, in modo che l'utente possa iniziare a interagire con essa subito.
Lunedì mattina, ai tuoi agenti basteranno gli elementi essenziali, ben visibili nella parte superiore della pagina: conversazioni attive, profili cliente aggiornati e documentazione tecnica per risolvere i ticket. Non hanno bisogno di un ticket risolto tre estati fa per rispettare gli SLA del primo giorno.
Il passaggio 2 consiste nel caricamento asincrono in background. Questo passaggio popola il resto dell'archivio storico secondo le vostre esigenze, anche molto tempo dopo che la fase di transizione, che rappresenta un momento critico, è stata completata. Entrambi i passaggi condividono lo stesso obiettivo: un trasferimento dati completo. Questo approccio di migrazione a fasi garantisce al vostro team il pieno controllo della tempistica operativa.
1.2 Cosa NON è Express Migration
Chiariamo subito: la migrazione express non significa tagliare i costi o eliminare definitivamente i vostri archivi. Ogni singolo ticket chiuso, risoluzione passata e file storico viene trasferito in modo sicuro durante la Fase 2. L'intera cronologia arriva intatta. Stiamo modificando strategicamente le tempistiche di consegna.
La principale preoccupazione dei responsabili IT è che i dati storici vengano abbandonati. Ma non è così. La Fase 2 è una fase di ingegneria fondamentale, non un ripensamento opzionale. Per i team vincolati da rigidi framework di conformità, audit normativi o modelli di customer success in cui gli operatori fanno costantemente riferimento a interazioni precedenti, il completamento della Fase 2 è una parte imprescindibile del nostro processo. La migrazione rapida è una strategia di sequenziamento, non una cancellazione selettiva.
2. Lista di controllo pre-migrazione: tutto ciò che è necessario configurare prima del trasferimento dei dati
Ogni attività in questa sezione deve essere completata prima che inizi il passaggio 1 per il trasferimento dei dati. Saltare questi passaggi è il modo più rapido per trasformare un passaggio di consegne notturno ben pianificato in un grosso grattacapo interno. Utilizzate questa lista di controllo principale per la migrazione helpdesk .
2.1 Disabilitare automazioni, notifiche e trigger attivi sulla piattaforma di destinazione
Quando vecchi record vengono inseriti in una piattaforma attiva durante un'importazione, il motore di automazione del sistema li considera come eventi completamente nuovi. Se le regole aziendali sono attive, verranno eseguite immediatamente.
Il risultato è un incubo di notifiche di massa: migliaia di email obsolete e confuse vengono inviate ai clienti riguardo a ticket risolti mesi fa. Peggio ancora, i timer SLA si reimpostano in modo errato sui dati storici e le regole di instradamento attive includono accidentalmente record inattivi nelle code live agent .
Questo è il passaggio più frequentemente trascurato nella checklist di transizione per la migrazione helpdesk e, se omesso, causa i danni operativi più gravi.
Prima di avviare il passaggio 1, accedi al pannello di amministrazione della piattaforma di destinazione e disattiva tutte le automazioni, i trigger di notifica e le regole aziendali attive:
- Zendesk: Amministrazione > Regole aziendali > Trigger
- Freshdesk: Amministrazione > Flussi di lavoro > Automazioni
- Intercom: Impostazioni > Posta in arrivo > Automazione
2.2 Verificare la creazione dell'agente e mappare i profili del team sul target infront
La mancata configurazionefront dell'assegnazione degli agenti causa la creazione di ticket orfani. I record vengono inseriti nella nuova piattaforma senza un proprietario valido, venendo assegnati automaticamente a un utente di sistema non monitorato. In un ambiente di supporto in tempo reale, i ticket orfani comportano la perdita di conversazioni e un'interruzione dei livelli di servizio.
Prima di avviare il passaggio 1, verifica che tutti i profili agente, sia attivi che storici, siano presenti nella piattaforma di destinazione. Successivamente, apri la mappatura nella procedura guidata di migrazione per collegare le identità di origine e di destinazione. Il modo migliore per garantire una corrispondenza automatica è utilizzare indirizzi email identici su entrambe le piattaforme. Se le convenzioni per gli indirizzi email differiscono, mappa manualmente tali utenti prima che il flusso di dati abbia inizio.
3. Passaggio 1. Aprire i biglietti durante la notte
Obiettivo: Far sì che il tuo team sia operativo sulla piattaforma di destinazione entro la mattina successiva.
La Fase 1 è la parte più critica in termini di tempo. Ogni decisione su cosa includere ed escludere si riduce a una sola domanda: il team ha bisogno di questo per iniziare a lavorare lunedì?
3.1 Cosa includere nella Fase 1
Limita il trasferimento iniziale a quanto necessario ai tuoi agenti per gestire le code in tempo reale e migrare i ticket aperti nei nuovi ambienti helpdesk in modo pulito:
- Ticket aperti e in sospeso: questa sezione rappresenta il carico di lavoro operativo in tempo reale e l'arretrato di ticket attivi. Tutto il resto verrà gestito nella Fase 2.
- Contatti e aziende associati: il contesto è fondamentale. Importare un ticket senza il relativo profilo cliente interrompe il flusso della conversazione e rallenta gli operatori.
- Articoli della knowledge base in tutte le versioni linguistiche: la knowledge base è uno strumento operativo fondamentale. Gli agenti necessitano di un accesso immediato alla documentazione interna e i centri di assistenza self-service devono rimanere attivi per i clienti fin dal momento del passaggio al nuovo sistema.
3.2 Cosa escludere dalla Fase 1
- Cronologia dei ticket chiusi e risolti: questa parte appartiene interamente alla Fase 2. Spostare questi record nella prima esecuzione aggiunge un volume di dati enorme, gonfiando pericolosamente la finestra temporale notturna per risorse che nessuno toccherà lunedì mattina.
- Allegati di record archiviati: gli allegati introducono un volume di dati del tutto sproporzionato rispetto al loro valore operativo immediato durante una transizione. Rimandateli alla Fase 2. (Gli allegati collegati a ticket attivi e aperti possono essere inclusi se la finestra temporale notturna lo consente.)
- Cronologia delle attività degli agenti: le tracce di audit interne storiche e le cronologie delle prestazioni con l'archivio dei ticket chiusi dovrebbero rimanere e spostarsi insieme all'archivio storico.
Mantenere snella la Fase 1 è fondamentale per rispettare la finestra di elaborazione notturna. Ogni megabyte risparmiato durante l'esecuzione iniziale è una garanzia per il lancio di lunedì mattina.
3.3 Utilizzo della migrazione multithread per rispettare la finestra di transizione
I limiti delle API della piattaforma di destinazione rappresentano il limite di velocità assoluto di qualsiasi migrazione digitale. Un motore di migrazione standard a singolo thread elabora le richieste in sequenza. Questo comporta una notevole perdita di velocità, risultando molto più lento di quanto la nuova piattaforma sia effettivamente in grado di gestire.
L'esecuzione di una migrazione helpdesk multithread cambia le carte in tavola. Eseguendo più thread di richiesta simultanei, il processo di importazione viene spinto al limite assoluto della capacità API della piattaforma di destinazione.
Ad esempio, un dataset di 50.000 ticket che richiede 8 ore per essere trasferito su un singolo thread può essere completato in 3-4 ore tramite un trasferimento multithread. Questo risparmio di tempo è spesso la differenza tra un'implementazione di successo e lasciare gli operatori frontlinea senza un sistema attivo all'inizio del turno.
Con il nostro pacchetto Signature Service, il multithreading è automatico e lo consigliamo vivamente come primo passo. Ricorda però che i limiti delle API variano notevolmente a seconda del fornitore e del piano. Un piano Freshdesk Growth ha limiti molto più rigidi rispetto a un account Enterprise, e Zendesk adatta le sue velocità in base al piano. Non sei sicuro che la tua configurazione possa gestire un passaggio immediato? Contatta il nostro team di ingegneri prima di fissare una data di passaggio.
3.4 Esecuzione della Fase 1: Dal lancio di venerdì all'attivazione del sistema
Avvia la procedura guidata di migrazione venerdì sera. Monitora il flusso di dati tramite la dashboard in tempo reale e non chiudere la scheda del browser (gli aggiornamenti vengono inviati automaticamente). Non perdere tempo ad aggiornare manualmente la pagina; riceverai notifiche automatiche nella tua casella di posta elettronica non appena l'operazione sarà completata.
Non appena il passaggio 1 si conclude, passate direttamente alle fasi di transizione:
- Passa immediatamente tutti i canali di comunicazione alla nuova piattaforma. Attiva l'inoltro delle email, sostituisci i widget della chat live del tuo sito web e reindirizza i link del centro assistenza alla nuova piattaforma. In questo modo, impedirai che il traffico di nuovi clienti raggiunga il tuo vecchio sistema.
- Imposta la piattaforma di origine in modalità di sola lettura. Rimuovi le autorizzazioni di modifica del tuo team oppure aggiungi un banner di sola lettura. Il vecchio help desk ora è solo una fonte di sola lettura, non un'area di lavoro attiva.
In questo modo il tuo team sarà pronto per lunedì mattina. I tuoi agenti accederanno e lavoreranno sulla nuova piattaforma, ma il vecchio sistema non potrà ricevere o generare nuove conversazioni.
3.5 Cosa succede se il passaggio 1 non è completato entro la mattina
Se durante la finestra di migrazione arrivano nuovi ticket o le conversazioni esistenti vengono aggiornate, Delta Migration funge da livello di sincronizzazione integrato. Trasferisce automaticamente i record appena creati e quelli aggiornati di recente dopo la fase iniziale di migrazione.
La migrazione Delta verifica la presenza di nuove attività nel tuo vecchio help desk dopo della Fase 1 e le sincronizza con il tuo nuovo spazio di lavoro. Poiché la sincronizzazione Delta rileva silenziosamente questi ticket residui in background, i tuoi agenti possono iniziare a lavorare immediatamente lunedì mattina senza perdere alcun dato.
È necessario eseguire la migrazione Delta entro 10 giorni dal completamento della fase di migrazione iniziale; questa operazione è inclusa nel nostro piano Signature. Molti team mantengono inoltre la piattaforma precedente disponibile in modalità di sola lettura durante il periodo di transizione, consentendo agli agenti di accedere ai dati storici di riferimento mentre il nuovo ambiente di lavoro si stabilizza completamente.
4. Lancio del primo giorno: le fasi finali del passaggio al nuovo sistema
Questo è il flusso di lavoro ufficiale per il giorno del lancio. Segui questi passaggi alla lettera prima che il team inizi a lavorare lunedì mattina.
4.1 Passare tutti i canali di comunicazione alla piattaforma di destinazione
Trasferisci il traffico dei tuoi clienti al nuovo sistema. Inoltra le email di supporto alla nuova casella di posta, aggiorna il codice della chat live sul tuo sito web e reindirizza gli URL del tuo centro assistenza. Questo reindirizzamento del canale è invisibile; i tuoi clienti non si accorgeranno di nulla perché tutti i loro punti di contatto abituali rimarranno invariati. Esegui questa operazione prima che gli operatori accedano al loro primo turno.
4.2 Impostare la piattaforma di origine in modalità sola lettura
Blocca il vecchio sistema e imponi lo stato di sola lettura, in modo che gli agenti non lo utilizzino accidentalmente. Revoca i loro permessi di modifica o aggiungi un banner chiaro che li indirizzi al nuovo desk. Se un agente aggiorna un ticket nella sorgente di sola lettura per abitudine, crea un enorme caos di dati che vanifica lo scopo della migrazione notturna.
Il tuo team può ancora accedere per consultare il contesto delle conversazioni precedenti, ma il vecchio sistema non sarà più utilizzabile per nuove attività a partire dal momento del passaggio al nuovo sistema.
4.3 Eseguire la migrazione Delta per individuare eventuali aggiornamenti dei ticket persi
Anche con una Fase 1 completata senza intoppi, è comunque necessario recuperare tutti i ticket che sono stati trasferiti durante la sincronizzazione. Avvia la migrazione Delta come parte del passaggio al nuovo sistema, subito prima che il tuo team acceda. Tieni presente che questa funzionalità è disponibile nel piano Signature e deve essere avviata entro 10 giorni dal completamento per garantire che il tuo nuovo spazio di lavoro sia aggiornato.
4.4 Effettuare un briefing di squadra di 10 minuti prima dell'inizio del primo turno
Evitate le interminabili sessioni di formazione del giorno del lancio. Concentratevi sugli aspetti pratici. Il giorno del lancio, il vostro team deve fornire supporto ai clienti, non assistere a presentazioni interminabili.
Tratta esattamente quattro aspetti:
- Nuove credenziali di accesso.
- Dove trovare biglietti aperti.
- Come funzionano la ricerca e la cronologia.
- A chi rivolgersi in caso di smarrimento di un oggetto.
Se avete già utilizzato un ambiente di test (sandbox) o eseguito una migrazione di prova, i vostri agenti conosceranno già l'interfaccia. Questa riunione informativa è solo un rapido controllo di allineamento, non un tutorial sulle funzionalità.
5. Fase 2: Spostamento dei ticket chiusi in blocchi in background
Obiettivo: Trasferire l'intero archivio storico senza interrompere le operazioni in corso.
I tuoi agenti stanno già eseguendo le loro code, quindi la fase di intenso controllo del tempo del passaggio 1 è terminata. Il passaggio 2 non ha un limite di tempo rigido. L'unico obiettivo ora è l'esecuzione in background che evita:
- Influisce sulle prestazioni live agent o sulla velocità dell'area di lavoro.
- Sovraccarico della quota API durante il normale orario lavorativo.
5.1 Perché la cronologia dei ticket chiusi è ancora importante
Non confondete i ticket chiusi con dati inutili. Sono fondamentali per tre motivi principali dopo la messa in produzione:
- Audit di conformità e normativi: a seconda del settore in cui operi, potresti essere legalmente obbligato a conservare le conversazioni con i clienti per anni. Il passaggio 2 garantisce la piena conformità della tua politica di conservazione dei dati.
- Contesto dell'agente: i clienti spesso menzionano problemi precedenti. Quando un agente apre un nuovo ticket e vede una cronologia vuota, si trova a operare alla cieca. Mantenere la cronologia dei ticket chiusi a portata di mano consente di conservare soluzioni, note e preferenze precedenti.
- Continuità nella reportistica: per monitorare le tendenze a lungo termine, i volumi stagionali o i punteggi CSAT storici, è necessario che tutti i dati siano raccolti in un unico luogo. Dati frammentati significano metriche disordinate e incomplete.
5.2 Pianificazione temporale dell'archivio: come suddividere gli intervalli di date
Utilizza i filtri per data per suddividere il tuo enorme archivio storico in blocchi più piccoli e gestibili. La strategia più efficace è quella di procedere a ritroso nel tempo. Inizia migrando prima i dati più recenti, poiché sono quelli che i tuoi agenti attivi consulteranno con maggiore probabilità.
La tabella di marcia per la migrazione graduale
| Fase | Ambito di applicazione | Tempistica/Metodo | Stato |
| Fase 1. Giorno di messa in produzione | Ticket aperti e in corso + KB migrati tramite sincronizzazione notturna | Sincronizzazione notturna | Vivere |
| Fase 2. Archivio storico | Biglietti chiusi più vecchi e storico a lungo termine | Carico di fondo | In corso |
Configura ogni batch come un processo di migrazione separato all'interno della procedura guidata di migrazione. Segmentare i dati in questo modo riduce al minimo il carico sul sistema. Se un'API di un fornitore si interrompe durante il trasferimento, l'impatto si limiterà a quel singolo blocco isolato, senza costringerti a ricaricare l'intero database.
5.3 Utilizzo della migrazione a intervalli per mettere in pausa durante l'orario di lavoro
L'utilizzo della logica dei ticket di supporto per la migrazione a intervalli consente di sospendere il trasferimento dei dati durante le ore di punta e di riprenderlo automaticamente di notte o nei fine settimana.
Anziché eseguire una sincronizzazione dati massiccia che satura i limiti dell'API e rallenta l'area di lavoro attiva, ogni pausa a intervalli suddivide il lavoro in finestre intelligenti.
In questo modo il passaggio 2 rimane invisibile al tuo team:
- Nessun rallentamento degli agenti: il tuo team di supporto non subirà ritardi o interruzioni dell'interfaccia durante le ore di punta.
- Silenzioso lavoro di costruzione in background: l'archivio storico si riempie mentre tutti sono offline.
- Programmazione automatizzata: non è necessario avviare e arrestare manualmente lo strumento; la gestione dei tempi è automatica.
Per i team aziendali con elevati volumi di ticket e SLA stringenti, la migrazione a intervalli trasforma un carico di dati pesante in un processo silenzioso in background.
5.4 Quanto tempo richiede la fase 2?
A differenza della fase 1, che richiede una scadenza precisa, la fase 2 non ha una data di scadenza fissa.
Alcune aziende completano il trasferimento dei dati storici in sole due notti. Altre optano per un approccio più prudente, distribuendo il lavoro su due o tre settimane ed eseguendo i processi in background solo nei fine settimana.
In definitiva, il ritmo di migrazione ideale dipende da tre fattori:
- il volume totale dei tuoi dischi.
- limiti API della piattaforma di destinazione.
- quanta larghezza di banda hai effettivamente a disposizione per monitorare i processi.
Consiglio degli esperti: se il tuo archivio supera i 200.000 record o se il tuo team è vincolato da scadenze di conformità stringenti, non devi affrontare tutto da solo. Il nostro team di Servizi Professionali può definire, suddividere ed eseguire la sincronizzazione storica end-to-end in modo completo.
6. Note temporali specifiche per la piattaforma
Sebbene la procedura per il passaggio 2 sia sempre la stessa, la tempistica esatta della sincronizzazione in background dipende dalla coppia di piattaforme che si stanno utilizzando.
Ogni help desk ha i propri limiti di utilizzo delle API, regole di limitazione della velocità e strutture dati. Ad esempio, il passaggio da Zendesk a Freshdesk richiede una strategia di pianificazione diversa rispetto all'esecuzione di una Intercom a Zendesk migrazione da Freshdesk a Intercom o da .
Gli stessi principi si applicano a progetti come la migrazione da Zendesk a Intercom , la Intercom a Freshdesk o persino un Zendesk a Zendesk consolidamento. Ogni piattaforma gestisce in modo diverso le strutture dati, le conversazioni, gli allegati e la sincronizzazione, il che può influenzare i tempi e la pianificazione della migrazione.
Allo stesso tempo, la maggior parte delle moderne piattaforme di help desk offre piani aziendali o componenti aggiuntivi API con una maggiore capacità di elaborazione, consentendo di eseguire migrazioni di grandi dimensioni in tempi significativamente più rapidi quando necessario. Ecco perché il successo delle migrazioni dipende meno da rigide limitazioni tecniche e più da una pianificazione intelligente, dalla definizione delle priorità e dalla scelta della strategia di migrazione più adatta alle tempistiche operative.
Ecco una rapida panoramica di cosa aspettarsi da ciascun ecosistema, in modo da poter pianificare i vostri batch di background senza sorprese.
6.1 Migrazione Zendesk Express
Zendesk limita la velocità di estrazione e importazione in base a rigidi limiti di frequenza delle API. A seconda del piano contrattuale, è possibile aspettarsi da 400 a 700 richieste al minuto. Una helpdesk massimizza completamente questa velocità di elaborazione.
Tuttavia, è necessario modificare le configurazioni in anticipo per evitare cicli di email automatiche di massa. Prima di eseguire il passaggio 1, accedi a Zendesk, vai su Amministrazione > Regole aziendali > Triggere disattiva tutti i trigger attivi. Dovresti anche controllare le configurazioni attive in Regole aziendali > Automazioni.
Lasciare attiva anche una sola notifica consente alla piattaforma di inviare aggiornamenti accidentali ai clienti preesistenti, corrompendo i metadati storici durante la transizione.
Allo stesso tempo, la migrazione rappresenta anche un'opportunità per eliminare i campi obsoleti o superflui. Non tutti i campi preesistenti devono essere trasferiti e molti team scelgono intenzionalmente di lasciare i campi personalizzati inutilizzati per evitare di ingombrare il nuovo spazio di lavoro.
6.2 Migrazione Freshdesk Express
Freshdesk adatta la velocità di acquisizione e importazione dei dati in base a rigidi limiti di frequenza delle API. A seconda del piano contrattuale, è possibile aspettarsi da circa 40 richieste al minuto nei piani di livello inferiore a circa 1.000 nel piano Enterprise. Se il team utilizza un piano Growth, questa velocità di elaborazione inferiore limita notevolmente un'esecuzione standard notturna.
Gestisci con attenzione i tuoi blocchi di dati attivi per evitare blocchi di integrazione a livello di account. L'utilizzo della migrazione a intervalli ti consente di sospendere il trasferimento in background durante le ore di punta diurne e di riprenderlo automaticamente quando il traffico diminuisce. Questa scelta operativa impedisce che carichi di dati elevati limitino il tuo spazio di lavoro o causino timeout di sistema per gli operatori dell'assistenza clienti.
6.3 Migrazione Intercom Express
Intercom regola la velocità di importazione utilizzando un esclusivo sistema di quote giornaliere anziché limiti al minuto. A seconda del piano contrattuale, gli spazi di lavoro ricevono un budget fisso di chiamate API che si azzera a mezzanotte UTC.
Assicurati di fronti contenuti della Knowledge Base (KB) direttamente nel passaggio 1. Caricare gli articoli in anticipo garantisce che gli live agente le funzionalità Fin AI dispongano di un database di alta qualità pronto per le risoluzioni fin dal primo giorno. Per i dati legacy che minacciano il tuo budget giornaliero, verifica la quota rimanente nel tuo Intercom Developer Hub prima di impostare la data di lancio.
7. Domande frequenti sulla migrazione rapida: Gestire la sequenza di migrazione in due fasi
Quanto tempo richiede la Fase 1 della migrazione rapida?
Per i team di supporto con meno di 50.000 ticket aperti e in sospeso, la Fase 1 si conclude generalmente entro 4-8 ore. La velocità effettiva dipende dal volume dei record, dai limiti di frequenza delle API della piattaforma e dal multithreading. Il modo più semplice per valutare la tempistica precisa per la propria coppia di piattaforme è eseguire una breve demo di prova.
I miei clienti si accorgeranno che abbiamo cambiato piattaforma?
Non se indirizzi i tuoi canali email, i widget di chat e gli URL del portale clienti al nuovo sistema prima che gli agenti effettuino l'accesso. I tuoi canali di comunicazione principali rimangono invariati; cambia solo il software di back-end che li gestisce. Se eseguito correttamente, il passaggio alla nuova piattaforma è impercettibile per gli utenti finali.
Che fine fanno i ticket creati durante la Fase 1?
La migrazione Delta cattura ogni singolo ticket creato o aggiornato nella vecchia piattaforma dopo l'avvio della Fase 1, trasferendolo in modo sicuro alla nuova destinazione. Questa rete di sicurezza colma eventuali lacune di dati durante il periodo di transizione. Ricorda di avviare la sincronizzazione Delta entro 10 giorni dal completamento della Fase 1. Questa opzione è disponibile nel piano Signature.
Devo disattivare le automazioni prima della migrazione?
Sì. Saltare questo passaggio è un errore incredibilmente costoso in una migrazione Express. Mantenere attivi trigger o flussi di lavoro automatizzati nel nuovo sistema durante un'importazione fa sì che la piattaforma invii migliaia di notifiche obsolete ai vecchi contatti dei clienti. Inoltre, altera in modo permanente i timer di monitoraggio degli SLA nell'intero archivio storico.
Quando è consigliabile avvalersi di servizi professionali anziché procedere in autonomia?
Per migrazioni complesse che coinvolgono oltre 200.000 record, scadenze di transizione rigorose in base agli SLA o mappature di campi personalizzate e disordinate, consigliamo di avvalersi di servizi professionali. Se state consolidando più piattaforme di origine in un'unica piattaforma, il nostro team di ingegneri può definire, mappare ed eseguire l'intera sequenza in tutta sicurezza per vostro conto.
8. Configurazione consigliata per la migrazione rapida
Se il tuo team di supporto lavora con un databasepulito (ovvero con meno di 50.000 ticket attivi e aperti) e hai un weekend pieno a disposizione, la nostra procedura guidata self-service può gestire facilmente il carico. Ti basta configurare il Passaggio 1 nella tua dashboard, spuntare la lista di pre-migrazione e fare clic su Avvia.
Ma quando databasesono enormi o pieni di dati obsoleti, le cose si complicano. Se vuoi che il tuo team acceda senza intoppi lunedì mattina, il tuo successo dipende interamente da come sfrutti due caratteristiche fondamentali dell'ingegneria:
- Migrazione multithread: questo protocollo spinge l'API della piattaforma di destinazione fino al suo limite di prestazioni per ridurre i tempi della Fase 1. Disponibile nel nostro Pacchetto Servizi Signature, è lo strumento principale per forzare l'elaborazione di grandi quantità di dati iniziali attraverso la pipeline.
- Migrazione a intervalli: questa funzione gestisce i trasferimenti di dati storici di Fase 2 in modo completo, al di fuori del normale orario di lavoro. Poiché mette automaticamente in pausa il caricamento dei dati durante il giorno e lo riprende di notte, la sincronizzazione in background non rallenta mai gli front.
Se vi trovate a dover gestire una scadenza imminente di un contratto software, volumi di archivio enormi o una combinazione di piattaforme estremamente restrittiva, un approccio fai-da-te potrebbe non essere sufficiente. Il nostro team di professionisti è a vostra disposizione per definire la vostra architettura specifica e gestire l'intero progetto di migrazione dall'inizio alla fine.
Migrazione rapida: operativa entro lunedì, archiviazione secondo le tue esigenze
Una migrazione rapida colma il divario tra velocità e sicurezza dei dati. I tuoi addetti all'assistenza clienti dovranno semplicemente accedere alla nuova piattaforma il lunedì mattina e iniziare a lavorare, mentre i tuoi archivi storici verranno aggiornati silenziosamente in background, a una velocità che si adatta al tuo flusso di lavoro.
La logica di base non cambia in base al fornitore del servizio di assistenza. Inviare prima i dati essenziali del primo giorno e poi trasmettere in streaming gli archivi a lungo termine è un framework che funziona per qualsiasi configurazione aziendale. Gli unici elementi che variano realmente sono le vostre specifiche metriche di temporizzazione:
- La velocità della Fase 1 dipende interamente dal volume di ticket attivi e dai limiti dell'API della piattaforma.
- Le tempistiche della Fase 2 si adattano in base alla profondità totale dell'archivio e alle finestre di sincronizzazione giornaliere.
Il risultato è prevedibile. Non si verificano interruzioni operative, nessun operatore si trova a dover gestire due sistemi separati e non si corre il rischio che le email indesiderate infastidiscano i clienti.
Gestire un'infrastruttura aziendale complessa significa guardare oltre la fase iniziale di transizione del fine settimana. Consulta la nostra Guida completa alla migrazione dei dati per analizzare l'intera architettura della tua pipeline di dati, oppure leggi la Guida alla migrazione basata sull'IA per configurare la tua nuova piattaforma per gli strumenti di supporto automatizzati.
