Introduzione
La maggior parte dei progetti UCaaS non falliscono perché la piattaforma è stata la scelta sbagliata. Falliscono a causa degli stessi errori evitabili: una data di trasferimento che slitta, un record di indirizzi di emergenza che non corrisponde al nuovo sistema o un dipendente chiave che scopre che manca una funzionalità due giorni dopo che il vecchio sistema telefonico è già stato spento. L'implementazione di UCaaS è il processo di pianificazione, configurazione, test e implementazione di una piattaforma di Unified Communications as a Service per sostituire o integrare gli strumenti telefonici e di collaborazione esistenti di un'azienda e, se ben eseguita, segue una sequenza definita di fasi anziché un singolo fine settimana di transizione. Questa guida illustra cosa comporta effettivamente l'implementazione, le sei fasi seguite dalla maggior parte delle migrazioni, tempistiche realistiche in base alle dimensioni dell'azienda, i controlli tecnici che prevengono i problemi iniziali, le insidie che fanno fallire progetti altrimenti ben pianificati e come convincere i dipendenti a utilizzare effettivamente il nuovo sistema una volta che è attivo.
Cosa comporta effettivamente l'implementazione dell'UCaaS?
L'implementazione di UCaaS copre tutto, dalla firma di un contratto all'attività completamente operativa sulla nuova piattaforma: valutazione dell'attuale infrastruttura telefonica e di rete, configurazione del nuovo sistema in modo che corrisponda al modo in cui opera effettivamente l'azienda, trasferimento dei numeri di telefono esistenti, test della configurazione prima che qualcuno dipenda da essa, formazione dei dipendenti e abbandono del vecchio sistema.
È un progetto con una data di inizio e di fine, non una singola installazione. Le aziende che lo trattano come se si azionasse un interruttore tendono ad essere quelle che si imbattono nelle insidie nascoste più in basso.
Quali sono le 6 fasi di un'implementazione UCaaS?
La maggior parte delle migrazioni UCaaS ben gestite seguono la stessa struttura in sei fasi, indipendentemente dal fornitore:
- 1Scoperta e valutazione - verificare gli attuali sistemi telefonici, la capacità della rete, i volumi delle chiamate e le caratteristiche su cui fanno effettivamente affidamento i diversi team
- 2Progettazione e configurazione — impostare il routing delle chiamate, gli interni, la segreteria telefonica e le integrazioni per adattarli al modo in cui opera oggi l'azienda
- 3Distribuzione pilota — distribuire il nuovo sistema innanzitutto a un piccolo gruppo di utenti, anziché all'intera azienda contemporaneamente
- 4Test paralleli — eseguire brevemente il nuovo sistema insieme a quello vecchio, in modo che i problemi emergano prima che il vecchio sistema venga disattivato
- 5Taglio della produzione - cambiare l'intera organizzazione, in genere programmata per un periodo di volume inferiore come un fine settimana
- 6Ottimizzazione post-migrazione — regolazione delle configurazioni, riqualificazione dove necessario e risoluzione dei problemi che si presentano solo nell'uso quotidiano reale
Saltare le fasi pilota o di test paralleli per risparmiare tempo è uno dei modi più comuni in cui un progetto altrimenti ben pianificato finisce per avere problemi in seguito.
Quanto tempo richiede l'implementazione di UCaaS?
Le tempistiche variano in modo significativo in base alle dimensioni dell'azienda e alla complessità della configurazione esistente, da poche settimane a diversi mesi. Come punto di riferimento, un'implementazione ben gestita per un'azienda di circa 50 persone richiede in genere dalle sei alle dieci settimane dalla firma del contratto al passaggio netto. Le organizzazioni più grandi, le aziende con più sedi o quelle con elevati requisiti di integrazione nei CRM o in altri sistemi aziendali dovrebbero aspettarsi un percorso più lungo.
Affrettare questa sequenza temporale per raggiungere una data di avvio arbitraria è una fonte comune di insidie descritte di seguito, in particolare test saltati e personale poco formato.
Quali requisiti tecnici devono essere controllati prima della migrazione?
La preparazione della rete non è facoltativa ed è uno dei passaggi più comunemente saltati in un'implementazione affrettata. Prima della migrazione, un'azienda deve verificare:
- Larghezza di banda è sufficiente per gestire il volume previsto di chiamate e video senza competere con altro traffico di rete
- Qualità del servizio (QoS) è in atto una configurazione per dare priorità ai pacchetti voce e video rispetto al traffico meno sensibile al fattore tempo
- Latenza rimane entro intervalli accettabili per le chiamate in tempo reale, poiché anche piccoli ritardi sono evidenti durante una chiamata dal vivo
- Hardware fisico, dove è ancora utilizzato, è stato effettivamente testato in condizioni di rete reali anziché semplicemente collegato e ritenuto che funzioni
Saltare questi controlli è il motivo per cui alcune implementazioni UCaaS incorrono in reclami sulla qualità delle chiamate quasi immediatamente dopo il go-live, anche quando la piattaforma stessa funziona esattamente come progettata.
Quali sono le insidie più comuni nell'implementazione di UCaaS?
Gli stessi errori rappresentano la maggior parte delle implementazioni UCaaS che incontrano seri problemi:
- Le date di trasferimento slittano, lasciando un'azienda temporaneamente senza il suo numero di telefono principale o facendo funzionare due sistemi più a lungo del previsto
- I record di indirizzi E911 non corrispondono il nuovo sistema, creando una lacuna di sicurezza se qualcuno ha bisogno di chiedere aiuto di emergenza da un nuovo interno
- Gli utenti chiave scoprono le funzionalità mancanti solo dopo che il vecchio sistema è già stato spento, senza possibilità di ripristinarlo rapidamente
- Telefoni e softphone non vengono testati in condizioni di rete reali prima del cutover, facendo emergere problemi di qualità delle chiamate fin dal primo giorno
- La formazione avviene una volta, subito prima del go-live, invece di continuare dopo che il sistema è effettivamente in uso quotidiano
La maggior parte di questi sono evitabili con l'approccio graduale e le verifiche tecniche sopra descritte; tendono a verificarsi quando un progetto ha fretta di rispettare una scadenza piuttosto che una lacuna di capacità nella piattaforma stessa.
Come convincere i dipendenti ad adottare effettivamente una nuova piattaforma UCaaS?
Un report di Tangoe ha rilevato che solo il 39% dei decisori IT ritiene che i propri investimenti in UCaaS abbiano pienamente prodotto i risparmi sui costi e i vantaggi di facilità di gestione che si aspettavano, e la debole adozione è una ragione comune per cui.
La resistenza dei dipendenti a una nuova piattaforma di comunicazione è uno dei maggiori ostacoli all’adozione, soprattutto tra i team che si sentono a proprio agio con gli strumenti legacy. Per superarlo è necessaria più di una singola sessione di formazione: la leadership deve utilizzare e sostenere visibilmente la nuova piattaforma, e i team IT dovrebbero fornire supporto continuo e specifico per ruolo anziché considerare la formazione come un evento una tantum prima del go-live. Inquadrare il cambiamento attorno a ciò che è effettivamente più semplice per il lavoro quotidiano di ciascun dipendente, e non solo al modo in cui funziona tecnicamente il nuovo sistema, tende a spostare l'adozione oltre la durata della formazione stessa. Il pilotaggio con un piccolo gruppo prima di un'implementazione completa offre inoltre all'azienda la possibilità di risolvere flussi di lavoro confusi prima che raggiungano tutti.
L'onboarding di Ringflow segue lo stesso processo?
La disciplina sottostante viene mantenuta anche se Ringflow non è una piattaforma UCaaS. Impostazione Instradamento delle chiamate e la connessione dei sistemi esistenti beneficia ancora di un’implementazione graduale, di un gruppo pilota prima dell’implementazione completa e dello stesso tipo di controlli di disponibilità della rete che contano per qualsiasi piattaforma di comunicazione cloud. Ciò che differisce è l'ambito: le implementazioni di Ringflow si concentrano sui flussi di chiamate rivolte al cliente, sul routing delle campagne e Integrazioni CRM piuttosto che sostituire un PBX interno o migrare gli interni dei dipendenti, quindi la fase di scoperta si concentra più su come un team di vendita o di supporto gestisce effettivamente le chiamate oggi che sui record degli indirizzi di emergenza o sugli inventari dei telefoni fissi.
Sfide di adozione più ampie come queste sono documentate in Meridiano ITLa ricerca di UCaaS sugli ostacoli comuni all'implementazione di UCaaS, riecheggiando lo stesso approccio pilota e di formazione continua delineato sopra.
Conclusione
Un'implementazione UCaaS ha successo o fatica in base alla disciplina più che alla tecnologia: se il progetto passa attraverso test pilota e operazioni parallele prima del cutover, se la disponibilità della rete viene verificata anziché presunta e se la formazione continua oltre la prima settimana invece di fermarsi lì. Le piattaforme stesse sono abbastanza mature a questo punto che i fallimenti di cui preoccuparsi sono quasi sempre fallimenti di processo, non di prodotto.
Pronto quando lo sei tu
Stai pianificando il lancio di una piattaforma di comunicazione?
Scopri come Cloud Contact Center e AI Sales Platform di Ringflow affrontano l'onboarding graduale per i flussi di chiamate rivolti ai clienti e i team connessi al CRM.
Domande frequenti
Una tipica implementazione UCaaS segue sei fasi: scoperta e valutazione, progettazione e configurazione, implementazione pilota con un piccolo gruppo di utenti, test paralleli insieme al vecchio sistema, passaggio alla produzione e ottimizzazione post-migrazione. Saltare la fase pilota o di test parallelo è uno dei motivi più comuni per cui le implementazioni incontrano problemi.
Le tempistiche variano in base alle dimensioni e alla complessità dell'azienda, da poche settimane a diversi mesi. Un'implementazione ben gestita per un'azienda di circa 50 persone richiede in genere dalle sei alle dieci settimane dalla firma di un contratto al passaggio definitivo, anche se le organizzazioni più grandi o più complesse dovrebbero aspettarsi più tempo.
Le cause più comuni sono date di trasferimento del numero spostate, record di indirizzi E911 che non corrispondono al nuovo sistema, dipendenti chiave che scoprono funzionalità mancanti solo dopo che il vecchio sistema telefonico è già stato spento e telefoni che non sono mai stati testati in condizioni di rete reali prima del go-live.
Non necessariamente. Molte implementazioni attuali prevedono innanzitutto il softphone, utilizzando un'app sul computer o sul dispositivo mobile esistente di un dipendente, con telefoni fisici da scrivania riservati principalmente alle aree reception e alle sale conferenze piuttosto che a ogni dipendente.
L’adozione migliora quando la leadership sostiene visibilmente la nuova piattaforma e la formazione è continua e specifica per il ruolo piuttosto che una singola sessione di onboarding. Inquadrare la formazione attorno a ciò che è effettivamente più semplice per il lavoro quotidiano di ciascun dipendente, e non solo al funzionamento del sistema, tende ad avere più importanza della durata della formazione.
La larghezza di banda, la configurazione della qualità del servizio e la latenza devono essere controllati prima della migrazione, poiché la qualità delle chiamate peggiora rapidamente su una rete che non è stata creata pensando al traffico vocale. Saltare questo passaggio è uno dei motivi più comuni per cui l'implementazione di UCaaS si imbatte presto in reclami sulla qualità delle chiamate.
La disciplina di base è simile, implementazione graduale, test pilota prima dell'implementazione completa e controlli di disponibilità della rete, anche se Ringflow è un Contact Center sul cloud e una piattaforma di vendita AI piuttosto che un prodotto UCaaS. L'ambito è diverso poiché le implementazioni di Ringflow si concentrano sui flussi e sull'instradamento delle chiamate rivolte al cliente piuttosto che sulla sostituzione di un PBX interno.
