Questo articolo è rivolto ai clienti Support Enterprise che attualmente usano una configurazione Hub and Spoke per gestire più brand e stanno valutando la possibilità di passare a Multibrand.
Prerequisiti per la migrazione a Multibrand
Se stai pensando, o addirittura pianificando, di migrare da Hub & Spoke (H&S) a Multibrand (MB), dai un’occhiata a questi roadblock principali che ci impediranno di migrare completamente il tuo account al Multibrand.
Prima di leggere i dettagli, chiediti se stai davvero usando tutti i tuoi Spoke. Abbiamo clienti che hanno configurato Hub & Spoke ma usano solo Hub. Se i tuoi Spoke non vengono usati o se gli Spoke non condividono i ticket con Hub, è probabile che non sia necessaria una migrazione.
- Community del Centro assistenza: puoi migrare i contenuti della community usando l’API del Centro assistenza. Per maggiori informazioni, consulta Argomenti e Post nella documentazione per sviluppatori.
- Multibrand o Hub & Spoke: un’istanza Multibrand non può esistere in una configurazione H&S. Questi prodotti si escludono a vicenda.
Se sei a tuo agio con quanto descritto sopra e vuoi saperne di più sulla migrazione multibrand, inizia dall’articolo Passaggi per la migrazione multibrand.
Confronto tra Hub and Spoke e Multibrand
Questa sezione descrive il cambiamento di comportamento che Hub & Spoke (H&S) potrebbe riscontrare dopo la migrazione a Multibrand. Abbiamo in programma di cambiare il comportamento di Multibrand per alcuni degli elementi seguenti, ma non abbiamo ancora una tempistica specifica.
- Autenticazione remota/Single Sign-On: ogni Centro assistenza reindirizza gli utenti allo stesso protocollo Single Sign-On e allo stesso database. Questo è un effetto collaterale del fatto che gli utenti sono per account e non per brand.
-
Branding del canale Zopim: i ticket creati tramite Zopim attualmente non sono consapevoli dell’attributo del brand. Vogliamo correggere anche questo in futuro. Nel frattempo, è possibile migliorare la configurazione multibrand di Zopim implementando un sottoinsieme di suggerimenti
- Firme agente: esiste una sola firma per agente. Gli agenti possono sfruttare le macro personali per creare una firma agente per ciascun brand.
-
Identità del brand degli utenti finali: attualmente non è possibile segmentare gli utenti finali per gli elenchi di clienti in base all'identità del brand perché non teniamo traccia di quali utenti hanno interagito con tali brand.
- Autorizzazioni agente: per impostazione predefinita, tutti gli agenti hanno accesso a tutti i brand. Puoi creare viste del brand che gli agenti possono usare. Se è necessaria una limitazione, usa i trigger per assegnare i ticket del brand ai gruppi e limitare le autorizzazioni degli agenti ai ticket in tali gruppi.
-
Autorizzazioni degli utenti finali: non è possibile nascondere determinati Centri assistenza a un sottoinsieme di utenti finali. In base all’impostazione predefinita, stiamo cercando un modo per supportare il servizio segmentato e con privilegi in base al tipo di utente. Tuttavia, è possibile impedire l’accesso ai contenuti, al portale utenti e alle community usando javascript e tag utente Zendesk.
-
Modelli email singoli: al momento del lancio, avrai a disposizione un solo modello HTML per account. Abbiamo in programma di aggiornarlo in futuro, ma per ora puoi creare un modello HTML condiviso e usare le macro per personalizzare il testo delle risposte
- Moduli ticket: puoi limitare l’accesso a moduli ticket specifici in base al brand (consulta Creazione e applicazione di moduli ticket con brand). Ciò ti consente di controllare i moduli ticket disponibili per gli utenti finali e gli agenti in base al brand del Centro assistenza o del ticket che stanno visualizzando.
-
Integrazioni: stiamo lavorando per garantire che il valore del brand si traduca nelle nostre principali integrazioni, tra cui JIRA e SFDC. Tutte le altre app dovranno essere aggiornate dai rispettivi proprietari.
- Reimpostazione della password: se un utente finale richiede la reimpostazione della password dal portale di un brand, reimposterà la password di tutti i brand contemporaneamente. L’email di reimpostazione della password non è personalizzabile, ma elenca tutti i Centri assistenza associati in modo che l’utente finale sappia dove è stata aggiornata la password.
I passaggi e le limitazioni della migrazione
Ecco gli elementi chiave della migrazione multibrand:
-
Passaggi e sequenza temporale
-
Limitazioni
Passaggi tipici e sequenza temporale
- Configura l’istanza MB (“Impostazioni”, “Canali”, “Brand”, Ruoli agente...).
- Zendesk migra un campione del contenuto (ticket e articoli del Centro assistenza).
- Verifica che la migrazione del contenuto campione sia andata come previsto.
- Zendesk completerà la migrazione dei contenuti, ad eccezione dei ticket meno di quelli chiusi (ossia, i ticket che sono in "volo").
- Potrai configurare il workflow nell’istanza MB (macro, trigger, automazioni e viste).
- Ti preparerai per il passaggio finale della migrazione comunicando ai clienti in merito al tempo di inattività imminente (messaggi nel Centro assistenza di Spoke ed eventualmente un’email di avviso).
- Esegui i compiti relativi ai tempi di inattività per eseguire la migrazione dei ticket rimanenti, passa da un sottodominio a un altro (da Spoke a Multibrand) e imposta la mappatura host per ciascun brand.
In termini di tempistica, questo impegno è limitato dalle risorse Zendesk disponibili per questo processo, dalla complessità della migrazione del programma e dalla reattività nel completare i compiti. Solo dopo aver raccolto i requisiti di migrazione saremo in grado di dirti qual è la data di completamento prevista per la migrazione.
- Ticket
- Migrazione di tutti i commenti, allegati e metadati (ovvero il valore corrente di ogni campo ticket e tag)
- Impossibile migrare gli eventi (il tag “xyz” è stato aggiunto dal trigger 123 il 12 dicembre 2014)
- Impossibile migrare l’ID ticket n. perché nell’istanza Multibrand vengono creati nuovi ticket.
- Contenuto Centro assistenza
- Migrazione degli articoli (e degli allegati). Dopo la migrazione, ogni articolo avrà lo stesso autore (il proprietario dell'account o una persona designata).
- La data di creazione dell’articolo, i commenti e l’abbonamento non sono disponibili. Lo stesso vale per le impostazioni della sezione e il contenuto delle community.
- I modelli non possono essere migrati (ad es., personalizzazione nel Centro assistenza)
- Impossibile migrare le impostazioni di categoria o sezione. Devi reimpostarli dopo la migrazione.
- Gli ID di categoria, sezione e n. articolo cambieranno durante la migrazione. Qualsiasi link esterno precedente dovrà essere aggiornato.
- Informazioni sull’utente
- È possibile eseguire la migrazione di utenti finali, agenti, gruppi e organizzazioni (non sono inclusi campi personalizzati, note utente e dettagli nelle informazioni di cui sopra)
- Impossibile migrare le password degli utenti finali. Pertanto, se i clienti accedono direttamente a Zendesk (ossia hanno un profilo di autenticazione Zendesk), dovranno reimpostare la password una volta completata la migrazione.
- Impossibile migrare i ruoli agente.
- Impossibile migrare i campi organizzazione, lingua, fuso orario, dettagli + note e personalizzati nei profili.
- Workflow
- Le migrazione delle macro è disponibile
-
Impossibile migrare le viste, i trigger e le automazioni (non avrebbe molto senso doverli rivedere tutti e adattarli al nuovo brand creato)
-
La migrazione del contenuto dinamico non è disponibile
- Altro
- Valutazioni della soddisfazione: non disponibile
- La migrazione delle “Impostazioni” e dei “Canali” non è disponibile (e non avrebbe molto senso dati i brand aggiuntivi).
- I segnalibri per articoli specifici indirizzano l’utente alla home page del Centro assistenza con brand (non all’articolo equivalente nel nuovo Centro assistenza con brand)
- Stiamo lavorando per garantire che il valore del brand sia trasmesso nelle nostre principali integrazioni, tra cui Jira e SFDC. Tutte le altre app dovranno essere aggiornate dai rispettivi proprietari.