Valutazione di una o più istanze Zendesk

La tua azienda può avere più organizzazioni che includono una varietà di reparti con processi, esigenze di sicurezza e workflow diversi. È utile valutare se una sola istanza Zendesk è adatta alla tua situazione o se più istanze sono migliori. Questo articolo descrive i vantaggi, le considerazioni e le conseguenze dell’uso di più istanze di Zendesk anziché di una sola. L'articolo include le seguenti sezioni:

• Considerazioni sulle funzionalità
• Domande sull’ambito
• Riepilogo

Considerazioni sulle funzionalità

Questo argomento tratta l'impatto dell'uso di un'istanza Zendesk per più team per le funzionalità seguenti: 

• Impostazioni globali
• Regole aziendali
• Integrazioni
• Autenticazione e accesso
• Gestione utenti finali
• Autorizzazioni degli agenti e accesso ai ticket
• Report
• Widget Web (versione classica) e widget di chat
• Guide

Impostazioni globali

Questa sezione descrive le considerazioni sulle impostazioni globali. 

• Abbonamento
  Se disponi di un'istanza Zendesk, tutti gli agenti devono avere lo stesso tipo di piano per Support, Guide, Talk e Chat. In particolare, per Guide, tutti gli agenti Support devono essere agenti Guide. Se solo un team utilizza Guide, questa è una considerazione da tenere in considerazione per il risparmio sui costi.

• Firme agente
  Esiste una firma agente globale nativa per ciascun Zendesk. Come soluzione alternativa, puoi personalizzare i trigger per ciascun team, con la firma nel trigger o nelle condizioni di Liquid Markup.

• Modello email
  Esiste un solo modello email nativo per Zendesk. La soluzione alternativa è personalizzare tutte le regole aziendali che supportano HTML, CSS o Liquid Markup. VediLiquid markup e Zendesk Support.
  

• Email di benvenuto/di verifica
  Esiste una sola email di benvenuto/verifica di benvenuto per l’utente finale nativo dopo il nome dell’account aggiunto in Impostazioni > Account.

• Sottodominio
  Puoi avere un solo sottodominio che tutti gli agenti possono usare e ricordare. Non è possibile personalizzare il sottodominio agente in base ai nomi dei team.
  
  
• Chiunque può inviare richieste?
  Un account Zendesk deve essere aperto a tutti gli utenti o chiuso a tutti gli utenti. Se è aperto, chiunque può inviare una richiesta, accedere a Guide o inviare un ticket con il widget. Se chiuso, l’utente finale deve essere un utente esistente in Support per inviare una richiesta o accedere a Guide. Consulta Configurazione delle modalità di accesso e accesso a Zendesk Support da parte degli utenti finali.
  
  
• Nome account
  • Esiste un solo nome account. Vedi Come posso cambiare il nome del mio account in Zendesk Support?.
  • Il nome dell’account è visibile nelle email se si usano segnapostoformattati . Il nome dell’account fa parte dell’email inviata ed è visibile agli utenti finali. Per aggirare questo problema, devi smettere di usare segnaposto formattati e usare invece segnaposto per contenuti avanzati che supportano il testo RTF. Tuttavia, ciò elimina l'esperienza estetica dei segnaposto formattati.
  • Infine, il nome dell’account è visibile nella pagina di accesso/richiesta di accesso e non è modificabile.

• Consenti agli utenti di appartenere a più organizzazioni
  Se decidi di usare un’istanza Zendesk in team diversi, esiste un’impostazione globale abilitata o disabilitata per l’intera istanza.
  
  
• Sondaggio sulla soddisfazione
  Anche se i sondaggi sulla soddisfazione sono abilitati o disabilitati per l’intera istanza di Support, puoi modificare le regole aziendali in modo che non vengano attivate per determinati gruppi. È possibile generare un link relativo alla soddisfazione per qualsiasi ticket usando dei segnaposto. ConsultaUso di segnaposto per le valutazioni della soddisfazione dei clienti.
  
  
• Esportazione dei dati
  Le esportazioni di dati di ticket, utenti e organizzazioni sono globali per l’intero account. Tuttavia, puoi usare l’API Zendesk Core per recuperare dati più specifici.
  
  
• Tags
  In un'istanza con più team, i tag non devono essere riciclati per più workflow o risorse.

Regole aziendali

Questa sezione descrive le considerazioni relative alle regole aziendali.

• Trigger, automazioni, viste e SLA
  • Le regole aziendali sono valide per tutti i ticket, ma possono essere facilmente limitate con condizioni riguardanti il gruppo o il brand di ticket. Consulta Uso dei gruppi nelle regole aziendali. Gli amministratori sono globali e possono creare regole per gruppi diversi da quelli che amministrano. Ciò crea il rischio che un amministratore di un team modifichi le regole che influiscono sui ticket e sui workflow degli altri team. 
  • Se usi team diversi nella stessa istanza Zendesk, il numero di regole da gestire è sempre più elevato. Una maggiore complessità richiede una strategia di gestione delle modifiche e una collaborazione continua tra i team. Inoltre, aumenta il rischio di indirizzamento errato dei ticket a gruppi errati, con possibili ripercussioni sugli SLA.
  • È inoltre necessario considerare che le informazioni riservate o sicure siano visibili agli agenti che non dovrebbero avervi accesso. Non esiste un metodo nativo per organizzare le regole aziendali in base al gruppo.
  • Per facilitare l’organizzazione/raggruppamento delle regole aziendali, è possibile creare trigger di segnaposto o automazioni che hanno solo un nome che aiuta a creare l’esperienza di categorizzazione delle regole in base al team.
    
    
• Macro
  L’accesso alle macro può essere configurato per tutti gli agenti o per gli agenti nei gruppi. Per maggiori informazioni, consultaCreazione di macro personali per i ticket .
  
  
• Campi ticket e moduli ticket
  • I campi ticket e i moduli ticket sono globali per l’intera istanza. Tutti i team possono vedere tutti i moduli e i campi. I moduli ticket personalizzati devono avere moduli univoci per i diversi team e per l’esperienza degli utenti finali.
  • Nell'interfaccia agente, un'app personalizzata potrebbe nascondere o mostrare determinati campi a seconda dell'agente che sta visualizzando il ticket. Puoi anche prendere in considerazione l'implementazione della ricetta descritta nell'articolo sulla limitazione dei moduli ticket.
  • Le personalizzazioni del codice del centro assistenza possono nascondere i campi modificabili dagli utenti finali non obbligatori dalmodulo di richiesta.

Integrazioni

Questa sezione descrive le considerazioni per le integrazioni.

• JIRA
  La versione 3 dell’integrazione Zendesk JIRA è one-to-one. Non puoi collegare più integrazioni JIRA a un account Zendesk Support.
  
  
• Integrazioni personalizzate
  Molteplici istanze di Support richiedono la configurazione di ciascuna integrazione personalizzata. Ad esempio, l'esportazione di dati o la connessione a un database utente richiede lo sviluppo e la configurazione da entrambi i lati per ogni istanza di Support.
  
  
• App (ZAF)
  Le app devono essere installate e configurate in ogni istanza di Support. Se le opzioni native non sono sufficientemente dettagliate per le tue esigenze, puoi programmare un’app personalizzata per controllare il gruppo di utenti e nascondere o mostrare l’app. È possibile specificare l’accesso alle app per gruppo o per ruolo personalizzato in modo nativo. ConsultaLimitazione della visibilità di un’app in base al gruppo.

Autenticazione e accesso

Questa sezione descrive le considerazioni relative all'autenticazione e all'accesso.

• Autenticazione base
  Con più istanze di Zendesk, gli accessi (nome utente e password) sono univoci per ciascuna istanza. Gli agenti e gli utenti finali devono gestire e ricordare due set di credenziali per più istanze di Zendesk che usano l’autenticazione Zendesk nativa.
  
  
• Accesso API
  I token API sono globali, il che significa che qualsiasi utente con un token API può accedere a tutte le risorse e ai dati nell’account.
  
  
• OAuth
  È possibile definire l’ambito dei token OAuth in modo da accedere solo a determinate risorse. Tuttavia, i token non possono essereassegnati ai gruppi di agenti.
  
  
• Single Sign-On (SSO)
  • Il SSO nativo si applica all’intera istanza sia per la configurazione degli agenti che per quella degli utenti finali. Gli agenti e gli utenti finali di tutti i team devono essere configurati nel provider di identità SSO.
  • Esistono soluzioni alternative per consentire agli utenti di usare metodi di autenticazione diversi (autenticazione Zendesk e SSO), ma è necessario creare tali soluzioni dal lato del cliente. Vedi Intervento: Posso usare un’opzione di autenticazione più avanzata?

Gestione utenti finali

Questa sezione descrive le considerazioni sulla gestione degli utenti.

• Campi organizzazione e utente
  I campi organizzazione e utente sono globali per l’intera istanza, il che significa che tutti gli agenti possono vederli ed eventualmente modificarli tutti. Come per i campi ticket, un’app personalizzata può nascondere o mostrare determinati campi organizzazione/utente a seconda dell’agente che li visualizza.
  
  
• Gestione dell’organizzazione
  • Le organizzazioni sono globali per l’intera istanza. Non è possibile segmentare le organizzazioni o visualizzare le autorizzazioni per gruppi di agenti.
  • Per la funzione di condivisione dei ticket dell’organizzazione, le autorizzazioni di accesso sono globali per tutti i ticket in un’organizzazione. Se questa opzione è abilitata, influisce sui ticket di tutti i team che usano Support e Guide.
  • I nomi delle organizzazioni devono essere univoci. Sebbene gli utenti possano appartenere a più organizzazioni, non è possibile avere due organizzazioni con lo stesso nome per ospitare più team.
    
    
• Autorizzazioni e accesso degli utenti finali
  • Tutti gli utenti finali sono globali per l’intera istanza. Non è possibile consentire a un utente finale di inviare richieste a un team in un'istanza, ma non a un altro.
  • In modo nativo, è supportato un solo metodo principale di autenticazione degli utenti finali. Gli utenti finali possono accedere a tutte le istanze del Centro assistenza. Esistono workflow che aggirano questo comportamento, ma sono altamente personalizzati e richiedono uno sviluppo da parte del cliente. 

Autorizzazioni degli agenti e accesso ai ticket

• Autorizzazioni degli agenti per la modifica degli utenti finali
  Esistono diverse considerazioni a seconda del tipo di piano:
  • Ruoli agente personalizzati: Se il tipo di piano include ruoli personalizzati, puoi consentire a un gruppo di agenti di modificare i profili degli utenti finali, ma non a un altro. Gli agenti possono visualizzare il profilo utente di tutti gli utenti finali. Esistono configurazioni per casi limite in cui un agente non ha accesso a un ticket in un altro gruppo, ma ha accesso alla modifica degli utenti finali. Ciò include l’assunzione da parte dell’utente finale in cui l’agente può vedere TUTTI i ticket richiesti dall’utente finale.
  • Ruolo agente: Nei piani senza ruoli agente personalizzati, solo gli agenti con accesso a tutti i ticket potranno aggiungere, modificare o assumere utenti finali.
  • Casi di utilizzo speciali in cui gli agenti di un team sono considerati utenti finali per un altro team: Gli agenti non possono inviare ticket usando il centro assistenza e, di conseguenza, i moduli degli utenti finali non funzioneranno per gli agenti. Indipendentemente dalle autorizzazioni del gruppo, gli agenti hanno accesso ai ticket quando sono richiedenti, il che significa che possono accedere a qualsiasi comunicazione interna per il proprio richiedente.
    
    
• Gestione dei gruppi e accesso ai ticket
  • I gruppi sono globali per l’intera istanza. È possibile creare gruppi per gestire più team e limitare l’accesso ai ticket per gruppo.
  • Con i piani Enterprise, puoi creare gruppi di ticket privati. I gruppi di ticket privati offrono un controllo più granulare sulla visibilità e l’accesso ai ticket in base all’assegnazione al gruppo, nascondendo completamente i ticket privati agli agenti che non hanno l’autorizzazione necessaria per visualizzarli.
  • Inoltre, con i piani Enterprise, puoi usare i ruoli agente personalizzati per controllare l'accesso degli agenti ai gruppi di ticket privati, inclusa la loro capacità di assegnare ticket a gruppi privati.

Report

Questa sezione descrive le considerazioni per la generazione di report.

• Report
  
  • Se usi un’istanza, i report sono centralizzati. Tutti i dati relativi a ticket, utenti e organizzazioni sono disponibili a tutti gli utenti con accesso ai report.
  • Nei diversi piani, l’accesso ai ticket controlla l’accesso ai report. Per visualizzare i report, gli agenti devono accedere a tutti i ticket.
  • I dashboard di report predefiniti sono globali per tutti i dati Support, il che significa che i report suddivisi per gruppo o altri attributi a livello di ticket (campi ticket personalizzati, brand del ticket, ecc.) dovrebbero essere creati in modo personalizzato.
    
    
• Report nativi
  Generazione di report nativi (non Explore), Classifica, Knowledge, Community, Search e Talk sono strumenti analitici globali per l’intera istanza.

Widget Web (versione classica) e widget di chat

Questa sezione descrive le considerazioni relative al Web Widget (versione classica) e al widget Chat. Potrebbero non essere applicabili al Web Widget di messaggistica.

• Le personalizzazioni native e l’aspetto (colore, posizione, testo del pulsante) sono globali. È possibile usare l’ API del widget per personalizzare il widget in base al team, ma è necessario uno sviluppo personalizzato.
• I moduli ticket saranno necessari per offrire un modulo/esperienza sul campo su misura per ciascun team.
• La funzione Cerca nel widget del centro assistenza cerca nell’intera Knowledge base e solo in una. Tuttavia, con un po’ di personalizzazione, puoipersonalizzare i risultati della ricerca.
• La chat può essere attivata o disattivata per il widget, il che può avere implicazioni se un solo team usa Chat. Potresti essere in grado di sovrascrivere questa impostazione con le personalizzazionidell’API Widget e dell’APIChat.

Guide

Questa sezione descrive le considerazioni per la guida.

• Autorizzazioni per gli agenti
  • Se più team usano una stessa Guide, è necessaria una strategia collaborativa. Ad esempio, gli agenti di un team che sono manager saranno in grado di gestire i contenuti e modificare i temi per altri team, anche se stai usando il multibranding.
  • Le autorizzazioni di modifica e creazione degli articoli sono una combinazione delle impostazioni di Support e delle impostazioni a livello di sezione Guide. Per impostazione predefinita, gli amministratori Zendesk Support sono gestori di Guide.
  • Se hai un piano con ruoli personalizzati, puoi creare un ruolo personalizzato e impostare l’autorizzazione Gestore Guide. Se appartieni a un piano diverso, puoi determinare chi è un manager o un visualizzatore di Guide nella pagina del profilo dell’agente. Consulta Ruoli di Guide e impostazione delle autorizzazioni.
  • Gli agenti possono essere impostati come visualizzatori in Support, ma creano e modificano gli articoli in tutte le sezioni impostate su manager e agenti nelle autorizzazioni a livello di sezione.

• Esperienza utente finale
  • Usando un unico Zendesk, tutti gli utenti finali potranno accedere a tutti i Centri assistenza. Se ci sono utenti finali comuni quando più team usano un'istanza Zendesk Support per i ticket, se i team usano istanze di Support separate gli utenti finali disporranno di un set di credenziali di accesso anziché di più credenziali.
  • Gli utenti finali possono vedere tutti i ticket in un unico luogo se usano un’istanza di Support. Tuttavia, ciò non si applica se i ticket sono di brand diversi.
  • I segmenti di utenti e la strategia di autorizzazione sono necessari per gestire chi può visualizzare quali contenuti per tutti i Centri assistenza associati a un’istanza di Support.
  • Infine, se gli agenti di un team sono utenti finali di un altro team, l’esperienza del centro assistenza sarà ridotta. Verrebbero reindirizzati a Support per inviare e visualizzare le richieste.

Domande sull’ambito

Prima di prendere la decisione finale, considera queste domande sull’ambito:

Tutti gli agenti devono avere accesso a tutti i ticket?

Se stai usando un'istanza di Support con più team, ecco le considerazioni da fare su come consentire o non consentire l'accesso a tutti i ticket.

Consenti l’accesso a tutti i ticket:

• Se gli agenti possono accedere a tutti i ticket, quanto sarebbe complesso/scalabile impostare e separare l'indirizzamento dei ticket usando le regole aziendali (viste, trigger, automazioni, SLA, modelli email) per ciascun team poiché le regole aziendali sono globali per l'intera istanza? 
• Ad esempio, se due team (Assistenza e Vendite) usano un unico Zendesk, per personalizzare l’esperienza utente finale per ciascun team sono necessari un trigger di indirizzamento per ciascun team (oltre a trigger separati per ogni aggiornamento di risposta automatica/commento). 
• Maggiore rischio di indirizzamento errato di un ticket in termini di SLA.

Non consentire l’accesso a tutti i ticket:

• Per limitare l’accesso, è necessaria la configurazione di gruppi o ruoli personalizzati.
• È necessaria un’attenta gestione dell’indirizzamento dei ticket per evitare che vengano inoltrati accidentalmente a un gruppo che non dovrebbe accedervi.
• Limita la visibilità degli agenti sulle altre richieste cronologiche o correnti. La limitazione dell’accesso ai ticket può anche limitare l’accesso degli agenti ai report.
• A seconda della configurazione, se gli agenti con limitazioni possono assumere utenti finali, potrebbero potenzialmente accedere ai ticket al di fuori del proprio gruppo da Le mie attività nel centro assistenza.

Esiste una strategia di gestione degli utenti centralizzata o esistente?

Gli elementi da considerare per gli agenti e gli utenti finali sono:

• In termini di autenticazione Zendesk, gli utenti che sono agenti in entrambe le istanze disporrebbero di due set di credenziali.
• Se usi SSO, Zendesk deve essere configurato come provider di servizi per entrambe le istanze. Se stai trasmettendo dati utente personalizzati, devi creare campi utente o organizzazione in entrambe le istanze. Tutti i campi utente personalizzati, le organizzazioni e i ruoli hanno ID univoci, che richiede la configurazione di asserzioni SAML/JWT univoche.

Ulteriori considerazioni per gli utenti finali sono:

• Gli utenti finali devono avere accesso ai contenuti del centro assistenza per entrambi i team (ad esempio, sia le risorse umane che Support usano un'istanza?
• Gli utenti finali devono avere accesso a tutti i contenuti HR e Support?  

Riepilogo

Ecco una rapida panoramica dei vantaggi e delle considerazioni sull’uso di un’istanza rispetto a più istanze:

Se usi una sola istanza di assistenza Zendesk, i vantaggi includono:

• Esperienza cliente unificata.
• Report unificati.
• Costo agente: gli agenti di entrambi i team richiedono una sola licenza.
• Le escalation tra reparti o il monitoraggio dei problemi sono più facili in un’unica istanza di Support.
• Autenticazione e gestione unificata degli utenti:
• Un’unica fonte attendibile per gli utenti.
• Vista a 360 gradi del cliente.

Gli elementi da considerare sono:

• Per alcuni tipi di piani, limitare l’accesso ai ticket è complesso.
• L’esperienza degli agenti che sono utenti finali per altri team è ridotta.
• Richiede un processo e una strategia definiti di gestione delle modifiche.
• Maggiore complessità per l’indirizzamento dei ticket e le regole aziendali.
• Molte funzioni personalizzabili di Support sono configurate a livello globale (come autenticazione, modello email, nome account o email di benvenuto).

Se usi più istanze di Zendesk, i vantaggi includono: 

• La compartimentazione è più facile.
• Flessibilità per apportare modifiche che non rischiano di influire sugli altri team.
• Workflow della Knowledge base e self-service di livello 0, indipendenti e completamente personalizzabili (KCS, Answer Bot, Pubblicazione in team).
• Esperienza utente finale completamente personalizzabile e su misura per ciascun team (esperienza utente finale per gli agenti che sono utenti finali per altri team).
• Controllo da parte del team dell’accesso ai ticket e della sicurezza.

Gli elementi da considerare sono:

• Costi generali per la configurazione e l’analitica per più istanze.

• Configurazione di SSO, app e integrazioni necessarie per tutte le istanze.

• Gli utenti finali devono recarsi in luoghi diversi per inviare richieste o effettuare self-service.

• La complessità della collaborazione tra gli agenti aumenta a causa della necessità di usare la condivisione dei ticket tra istanze di Support.

• La funzione di collisione agente non è disponibile tra due istanze di Support.

• Sebbene la condivisione dei ticket possa consentire a due team di usare Zendesk per collaborare, gli aggiornamenti dei ticket sarebbero asincroni dal ticket di un'istanza di Support all'altra.

• Con alcuni tipi di piani, il controllo dell’accesso ai ticket e della sicurezza in base al team può essere ottenuto in una singola istanza creando gruppi di ticket privati.

Avvertenza sulla traduzione: questo articolo è stato tradotto usando un software di traduzione automatizzata per fornire una comprensione di base del contenuto. È stato fatto tutto il possibile per fornire una traduzione accurata, tuttavia Zendesk non garantisce l'accuratezza della traduzione.

Per qualsiasi dubbio sull'accuratezza delle informazioni contenute nell'articolo tradotto, fai riferimento alla versione inglese dell'articolo come versione ufficiale.