Considerações sobre uma ou várias instâncias do Zendesk

Sua empresa pode ter várias organizações que incluem diversos departamentos com diferentes processos, requisitos de segurança e fluxos de trabalho. É útil considerar se uma instância do Zendesk funcionará bem na sua situação ou se o uso de várias instâncias será melhor. Este artigo descreve os benefícios, as considerações e as consequências de usar várias instâncias do Zendesk em vez de apenas uma. Ele inclui os seguintes tópicos:

• Considerações sobre recursos
• Perguntas de escopo
• Resumo

Considerações sobre recursos

Este tópico trata do impacto do uso de uma instância do Zendesk para várias equipes em relação aos seguintes recursos: 

• Configurações globais
• Regras de negócios
• Integrações
• Autenticação e acesso
• Gerenciamento de usuários finais
• Permissões do agente e acesso a tickets
• Relatórios
• Web Widget (clássico) e o widget de chat
• Guide

Configurações globais

Esta seção descreve considerações sobre configurações globais. 

• Assinatura
  Se você tem uma instância do Zendesk, todos os agentes precisam estar no mesmo tipo de plano do Support, Guide, Talk e Chat. No caso do Guide, em particular, todos os agentes do Support precisam ser agentes do Guide. Se apenas uma equipe utiliza o Guide, esta é uma consideração de economia de custos.

• Assinaturas do agente
  Existe uma assinatura de agente global nativa por Zendesk. Como alternativa, você pode personalizar gatilhos para cada equipe com a assinatura no gatilho ou nas condições de marcação Liquid.

• Modelo de e-mail
  Existe apenas um modelo de e-mail nativo por Zendesk. A alternativa é personalizar todas as regras de negócios que aceitam HTML, CSS ou marcação Liquid. Consulte Noções básicas sobre a marcação Liquid e o Zendesk Support.
  

• E-mails de confirmação ou boas-vindas
  Existe apenas um e-mail de boas-vindas ou confirmação de usuário final nativo que acompanha o nome da conta adicionado em Configurações > Conta.

• Subdomínio
  É possível ter apenas um subdomínio para que todos os agentes usem e memorizem. Não é possível personalizar o subdomínio de agentes com nomes de equipes.
  
  
• Qualquer um pode enviar solicitações?
  É preciso que uma conta do Zendesk esteja configurada como aberta ou fechada a todos os usuários. Quando aberta, qualquer pessoa pode enviar uma solicitação, entrar no Guide ou enviar um ticket com o widget. Quando fechada, o usuário final precisa ser um usuário existente do Support para enviar uma solicitação ou acessar o Guide. Consulte Configuração da maneira como os usuários finais acessam e entram no Zendesk Support.
  
  
• Nome da conta
  • Há apenas um nome da conta. Consulte Como altero meu nome da conta no Zendesk Support?.
  • O nome da conta fica visível em emails quando se usa placeholders formatados. O nome da conta faz parte do e-mail enviado e fica visível aos usuários finais. Para evitar isso, você precisa interromper o uso de placeholders formatados e, em vez disso, usar placeholders de conteúdo sofisticado, que aceitam rich text. Entretanto, isso estraga a experiência estética dos placeholders formatados.
  • Por fim, o nome da conta é exibido na página ou no prompt de entrada e não é editável.

• Permitir que os usuários pertençam a diversas organizações
  Se você decidir usar uma só instância do Zendesk para diferentes equipes, existe uma configuração global que é ativada ou desativada para toda a instância.
  
  
• Pesquisa de satisfação
  Embora as pesquisas de satisfação sejam ativadas ou desativadas para toda a instância do Support, é possível editar as regras de negócios para não as disparar para determinados grupos. É possível gerar um link de satisfação para qualquer ticket usando placeholders. Consulte Uso de placeholders do índice de satisfação do cliente.
  
  
• Exportação de dados
  As exportações de dados de tickets, usuários e organizações são globais para a conta. Entretanto, é possível usar a API Core do Zendesk para obter dados mais específicos.
  
  
• Tags
  Em uma instância com várias equipes, as tags não devem ser recicladas para vários fluxos de trabalho nem recursos.

Regras de negócios

Esta seção descreve considerações sobre regras de negócios.

• Gatilhos, automações, visualizações e SLAs
  • As regras de negócios são executadas em todos os tickets, mas elas podem ser facilmente restringidas com condições que consideram um grupo de tickets ou uma marca. Consulte Uso de grupos em regras de negócios. Os administradores são globais e podem criar regras para grupos fora daqueles que administram. Isso gera o risco de um administrador de uma equipe editar regras que afetam os tickets e fluxos de trabalho de outras equipes. 
  • Se você usa equipes diferentes dentro da mesma instância do Zendesk, há um número crescente de regras a gerenciar. A complexidade maior exige uma estratégia de gerenciamento de mudanças e a colaboração contínua entre as equipes. Também existe um risco maior de tickets serem encaminhados por engano para grupos incorretos, algo que pode ter implicações nos SLAs.
  • Você também precisa considerar a visibilidade de informações confidenciais ou protegidas para agentes que não devem acessá-las. Não existe um método nativo de organizar regras de negócios por grupo.
  • Para auxiliar na organização ou no agrupamento de regras de negócios, é possível criar gatilhos ou automações de placeholders cuja única função é ser um nome que ajuda a criar a experiência de categorização de regras por equipe.
    
    
• Macros
  O acesso a macros pode ser configurado para todos os agentes ou para agentes em grupos. Para obter mais informações, consulte Criação de macros pessoais para tickets.
  
  
• Campos e formulários de ticket
  • Os campos de ticket e os formulários de ticket são globais para a instância. Todas as equipes podem ver todos os formulários e campos. Os formulários de ticket personalizados devem ter formulários únicos para diferentes equipes e experiências do usuário final.
  • Na interface do agente, um aplicativo personalizado poderia ocultar ou mostrar determinados campos, dependendo do agente que está visualizando o ticket no momento. Você também pode considerar a implementação da receita descrita no artigo sobre a restrição de formulários de ticket.
  • As personalizações de código da central de ajuda podem ocultar campos editáveis de usuário final não obrigatórios do formulário.

Integrações

Esta seção descreve considerações sobre integrações.

• JIRA
  A v3 da integração do Zendesk com o JIRA é individual. Não é possível vincular várias integrações para o JIRA a uma conta do Zendesk Support.
  
  
• Integrações personalizadas
  Várias instâncias do Support exigem a configuração de cada integração personalizada. Por exemplo, a execução de exportações de dados ou a conexão a um banco de dados de usuário exigem desenvolvimento e configuração em ambos os lados para cada instância do Support.
  
  
• Aplicativos (ZAF)
  É preciso instalar e configurar aplicativos em cada instância do Support. Se as opções nativas não forem suficientemente granulares para suas necessidades, você pode programar um aplicativo personalizado para verificar o grupo de usuários e ocultar ou mostrar o aplicativo. É possível especificar o acesso aos aplicativos por grupo ou função personalizada nativamente. Consulte Restrição da visibilidade de um aplicativo por grupo.

Autenticação e acesso

Esta seção descreve as considerações sobre autenticação e acesso.

• Autenticação básica
  Com várias instâncias do Zendesk, os dados de acesso (nome de usuário e senhas) são exclusivos para cada instância. Os agentes e usuários finais precisariam gerenciar e registrar na mente dois conjuntos de credenciais de várias instâncias do Zendesk que usam a autenticação nativa do Zendesk.
  
  
• Acesso à API
  Os tokens da API são globais, ou seja, qualquer usuário com um token da API pode acessar todos os recursos e dados da conta.
  
  
• OAuth
  Os tokens OAuth podem ser definidos para acessar apenas determinados recursos. No entanto, os tokens não podem ser definidos para grupos de agentes.
  
  
• Single sign-on (SSO)
  • O SSO nativo se aplica à instância inteira, em configurações para agentes e usuários finais. Os agentes e usuários finais de todas as equipes precisam ser configurados no provedor de identidade de SSO.
  • Existem alternativas para que os usuários possam usar métodos de autenticação diferentes (autenticação do Zendesk e SSO), mas isso precisaria ser incorporado no lado do cliente. Consulte Hora do papo: estou pronto para uma opção de autenticação mais avançada?.

Gerenciamento de usuários finais

Esta seção descreve considerações sobre o gerenciamento de usuários.

• Campos de organização e do usuário
  Os campos de organização e do usuário são globais para a instância, ou seja, todos os agentes podem vê-los e possivelmente editá-los. Como no caso dos campos de ticket, um aplicativo personalizado pode ocultar ou mostrar determinados campos de organização ou usuário, dependendo do agente que está visualizando.
  
  
• Gerenciamento de organizações
  • As organizações são globais para a instância. Não é possível segmentar organizações ou permissões de visualização da organização por grupos de agentes.
  • No recurso de compartilhamento de ticket na organização, as permissões de acesso são globais para todos os tickets de uma organização. Se esta opção estiver ativada, ela afetará os tickets de todas as equipes que usam o Support e o Guide.
  • Cada organização deve ter um nome exclusivo. Embora seja possível que os usuários pertençam a várias organizações, não é possível ter duas organizações com o mesmo nome para acomodar várias equipes.
    
    
• Permissões e acesso de usuários finais
  • Todos os usuários finais são globais para toda a instância. Não é possível permitir que um usuário final envie solicitações a uma equipe em uma instância e não permitir solicitações a outra.
  • Nativamente apenas um método principal de autenticação de usuário final é aceito. Os usuários finais podem entrar em todas as instâncias da central de ajuda. Existem fluxos de trabalho que evitam esse comportamento, mas são altamente personalizados e exigem algum desenvolvimento no lado do cliente. 

Permissões do agente e acesso a tickets

• Permissões do agente para editar usuários finais
  Existem várias considerações, dependendo do tipo de plano:
  • Funções personalizadas de agentes: se seu tipo de plano inclui as funções personalizados, você pode permitir que um grupo de agentes edite perfis de usuários finais, porém não outros. Os agentes podem visualizar o perfil do usuário de todos os usuários finais. Existem configurações limítrofes a que um agente não tem acesso a um ticket em outro grupo, mas tem acesso para editar usuários finais. Isso inclui a assunção de usuário final, onde o agente pode ver TODOS os tickets que o usuário final solicitou.
  • Função do agente: em tipos de plano sem funções personalizadas do agente, apenas os agentes com acesso a todos os tickets podem adicionar, editar ou assumir usuários finais.
  • Casos de uso especiais nos quais os agentes de uma equipe são considerados usuários finais por outra equipe: Os agentes não podem enviar tickets usando a central de ajuda e, por isso, os formulários de usuário final não funcionarão para os agentes. Sejam quais forem as permissões do grupo, os agentes têm acesso aos tickets dos quais são os solicitantes, ou seja, podem acessar qualquer comunicação interna para o solicitante.
    
    
• Gerenciamento de grupos e acesso a tickets
  • As grupos são globais para toda a instância. É possível criar grupos para gerenciar várias equipes e restringir o acesso a tickets por grupo.
  • Nos planos Enterprise, você pode criar grupos privados de tickets. Os grupos privados de tickets fornecem um controle mais detalhado sobre a visibilidade e o acesso a tickets com base na atribuição do grupo, ocultando completamente os tickets privados de agentes que não têm permissão para visualizá-los.
  • Também nos planos Enterprise, é possível usar funções personalizadas de agentes para controlar o acesso dos agentes a grupos privados de tickets, incluindo a capacidade deles de atribuir tickets a grupos privados.

Relatórios

Esta seção descreve considerações sobre relatórios.

• Relatórios
  
  • Se estiver usando uma instância, os relatórios são centralizados. Todos os dados de tickets, de usuários e da organização estão disponíveis para todos os usuários com acesso aos relatórios.
  • Em planos diferentes, o acesso aos tickets controla o acesso aos relatórios. Os agentes precisam do acesso a todos os tickets para visualizar os relatórios.
  • Os painéis padrão de relatórios são globais para todos os dados do Support, ou seja, os relatórios separados por grupo ou outro atributo no nível de ticket (campo de ticket personalizado, marca do ticket etc.) precisam ser criados personalizadamente.
    
    
• Relatórios nativos
  Relatórios nativos (que não do Explore) de Visão geral, Tabela de classificação, Conhecimento, Comunidade, Pesquisa e Talk são análises globais para toda a instância.

Web Widget (clássico) e o widget de chat

Esta seção descreve considerações para o Web Widget (clássico) e o widget de Chat. Elas podem não se aplicar ao Web Widget de mensagens.

• As personalizações e a aparência (cor, posição, texto de botões) nativas são globais. É possível usar a API Widget para personalizar o widget por equipe, mas isso exige desenvolvimento personalizado.
• Os formulários de ticket precisam ter uma experiência de formulário/campo adaptada por equipe.
• A pesquisa na central de ajuda no widget pesquisa a base de conhecimento inteira e apenas uma base de conhecimento. Entretanto, com algum desenvolvimento personalizado, possivelmente você consegue possivelmente personalizar os resultados da pesquisa.
• O Chat pode estar ativado ou desativado para o widget, algo que pode ter implicações se apenas uma equipe usa o Chat. Talvez seja possível ignorar essa configuração com personalizações da API Widget e da API Chat.

Guide

Esta seção descreve considerações sobre o Guide.

• Permissões para agentes
  • Se várias equipes estiverem usando o Guide, será necessária uma estratégia colaborativa. Por exemplo, os agentes de uma equipe que são gerentes poderão gerenciar conteúdo e editar temas de outras equipes, mesmo se você estiver usando Multimarca.
  • As permissões para editar e criar artigos são uma mistura de configurações do Support e configurações no nível de seção do Guide. Por padrão, os administradores do Zendesk Support são gerentes do Guide.
  • Se você está em um tipo de plano com funções personalizadas, pode criar uma função personalizada e definir a permissão de gerente do Guide. Se você pertence a um plano diferente, pode controlar quem é um gerente do Guide ou um visualizador do Guide na página do perfil do agente. Consulte Noções básicas sobre funções e definições de permissões do Guide.
  • Os agentes podem ser definidos como visualizadores no Support, mas ainda podem criar e editar artigos em todas as seções definidas para gerentes e agentes em permissões no nível de seção.

• Experiência do usuário final
  • Se estiver usando um Zendesk, todos os usuários finais conseguirão entrar em todas as centrais de ajuda. Se houver usuários finais comuns quando várias equipes estiverem usando uma instância do Zendesk Support para sistema de tickets, os usuários finais terão um conjunto de credenciais de acesso em vez de várias se as equipes usarem instâncias separadas do Support.
  • Os usuários finais podem ver todos os tickets em um só lugar se estiverem usando uma instância do Support. No entanto, isso não é aplicável se os tickets estiverem em marcas diferentes.
  • Os segmentos de usuário e uma estratégia de permissão são necessários para gerenciar quem pode visualizar qual conteúdo de todas as centrais de ajuda associadas a uma instância do Support.
  • Por último, se os agentes de uma equipe forem usuários finais de outra equipe, eles terão uma experiência reduzida na central de ajuda. Eles serão redirecionados ao Support para enviar e visualizar solicitações.

Perguntas de escopo

Antes de tomar a decisão final, considere estas perguntas de escopo:

Todos os agentes devem ter acesso a todos os tickets?

Se você está usando uma instância do Support com várias equipes, aqui estão as considerações sobre permitir acesso a todos os tickets ou não permitir acesso a todos os tickets.

Permitir acesso a todos os tickets:

• Se os agentes puderem acessar todos os tickets, qual seria a complexidade/o dimensionamento para configurar e separar o encaminhamento de tickets usando as regras de negócios (visualizações, gatilhos, automações, SLAs, modelos de email) para cada equipe, já que as regras de negócios são globais para a instância inteira? 
• Por exemplo, se duas equipes (Suporte e Vendas) usam um Zendesk, é necessário um gatilho de encaminhamento para cada equipe (além de gatilhos separados para cada resposta automática ou atualização de comentário) para personalizar a experiência do usuário final de cada equipe. 
• Maior risco de um ticket ser encaminhado erroneamente em termos de SLAs.

Não permitir acesso a todos os tickets:

• A configuração de grupos ou funções personalizadas são necessárias para restringir o acesso.
• Um gerenciamento cuidadoso de encaminhamento de ticket é necessário para que os tickets não sejam encaminhados por acidente para um grupo que não deveria acessar o ticket.
• Limita a visibilidade dos agentes para as demais solicitações históricas ou atuais. A restrição de acesso a tickets também pode restringir o acesso do agente a relatórios.
• Dependendo da sua configuração, se os agentes restritos puderem assumir usuários finais, eles possivelmente poderão acessar tickets fora de seu grupo nas Minhas atividades na central de ajuda.

Existe uma estratégia de gerenciamento de usuários centralizada?

Os itens essenciais em relação a agentes e usuários finais incluem:

• Em termos de autenticação do Zendesk, os usuários que são agentes em ambas as instâncias teriam dois conjuntos de credenciais.
• Se você está usando SSO, o Zendesk precisa ser configurado como um provedor de serviços para ambas as instâncias. Se você está passando dados de usuário personalizados, precisa criar campos de usuário e organização em ambas as instâncias. Todos os campos de usuário personalizados, organizações e funções têm IDs únicas, o que exige a configuração de asserções de SAML/JWT únicas.

Os itens adicionais em relação a usuários finais incluem:

• Os usuários finais precisam ter acesso ao conteúdo da central de ajuda de ambas as equipes (por exemplo, se o RH e o Suporte usam uma instância)?
• Os usuários finais precisam ter acesso a todo o conteúdo de RH e de Suporte?  

Resumo

Esta é uma breve visão geral dos benefícios e das considerações de usar uma instância em oposição a várias instâncias:

Se você está usando uma instância do Zendesk Support, os benefícios incluem:

• Experiência do cliente unificada.
• Relatórios unificados.
• Custo do agente: agentes de ambas as equipes precisam apenas de uma licença.
• O escalonamento entre departamentos ou o controle de problemas são mais fáceis dentro de uma instância do Support.
• Gerenciamento e autenticação de usuário unificados:
• Fonte única de confiança para os usuários.
• Visão completa do cliente.

Os itens a considerar são:

• Em alguns tipos de plano, a restrição de acesso aos tickets é complexa.
• A experiência de agentes que são usuários finais de outras equipes é reduzida.
• Exige a definição de um processo e uma estratégia de gerenciamento de mudanças.
• Maior complexidade no encaminhamento de tickets e nas regras de negócios.
• Muitos recursos personalizáveis do Support são configurados globalmente (como autenticação, modelo de email, nome da conta ou emails de boas-vindas).

Se você está usando várias instâncias do Zendesk, os benefícios incluem: 

• A compartimentalização é mais fácil.
• Flexibilidade para fazer alterações que não tenham risco de afetar outras equipes.
• Fluxos de trabalho de nível 0/autoatendimento e conhecimento (KCS, Answer Bot, Publicação em equipe) independentes e totalmente personalizáveis.
• Experiência do usuário final totalmente personalizável e adaptada por equipe (experiência de usuário final apropriada para agentes que são usuários finais de outras equipes).
• Controle por equipe do acesso a ticket e segurança.

Os itens a considerar são:

• Despesa geral para configuração e análise de várias instâncias.

• Configuração de SSO, aplicativos e integrações necessária para todas as instâncias.

• Os usuários finais precisam acessar locais diferentes para enviar solicitações ou utilizar autoatendimento.

• A complexidade da colaboração entre agentes aumenta, devido à necessidade de usar o compartilhamento de ticket entre as instâncias dos Support.

• O recurso de colisão de agente não funciona entre duas instâncias do Support.

• Embora o Compartilhamento de ticket permita que duas equipes que usam o Zendesk colaborem, as atualizações de ticket seriam assíncronas do ticket de uma instância do Support em relação à outra.

• Em alguns tipos de planos, o controle de acesso e de segurança do ticket por equipe podem ser realizado em uma única instância, criando grupos privados de tickets.