Estes Ajustes tratam do que deve ser levado em conta ao criar seu fluxo de trabalho, incluindo:
Além disso, confira a 1ª parte da discussão sobre Ajustes.
Para encontrar mais artigos sobre Ajustes, consulte Recursos de ajustes.
Parte 1: Gatilhos e automações
Meu último Ajustes: passo a passo abordou os itens básicos necessários para criar sua instância do Zendesk ideal e como você pode configurá-la para atender às suas necessidades específicas. Desta vez, vou mergulhar nos passos restantes para ajudar você a desenvolver seu fluxo de trabalho ideal.
Gatilhos
Os gatilhos são maravilhosos. Eles são ações do sistema baseadas em eventos, ativados pela criação ou atualização de tickets. Há muitas maneiras de usar os gatilhos no Zendesk, mas todas podem ser resumidas a essas categorias:
- Atribuir tickets para um agente específico ou grupo de agentes.
- Alterar os valores do campo de ticket ou adicionar/remover tags.
- Notificar usuários (ou alvos) dos tickets criados ou atualizados.
- Alterar valores do campo do usuário ou organização (somente com a atualização do ticket)
Possíveis armadilhas:
O Zendesk tem alguns gatilhos padrão que você pode desativar ou alterar. Se você não verificar sua lista de gatilhos antes de ativá-los, pode acabar com uma caixa de entrada repleta de notificações indesejadas.
O gatilho padrão Notificar solicitante sobre atualização de comentários é o mais importante na sua conta. Esse é o gatilho que envia seus comentários nos tickets para seus usuários finais. Se você o alterar ou apagar, saiba que isso pode afetar sua habilidade de se comunicar com seus clientes.
Não tente criar supergatilhos. Quanto mais complicado forem seus gatilhos, mais difícil será resolver problemas e fazer a manutenção deles.
Se você tem uma instância aberta do Zendesk Support em que qualquer pessoa pode enviar tickets sem precisar se registrar, os gatilhos de primeira resposta (que são acionados na criação do ticket) que usam qualquer um dos placeholders a seguir podem ser alvos para retransmissão de spam.
- {{ticket.title}}
- {{ticket.requester.first_name}}
- {{ticket.requester.last_name}}
- {{ticket.requester.name}}
A retransmissão de spam ocorre quando o e-mail é enviado a um destino por meio de um serviço de terceiro (neste caso, o Zendesk) para ocultar a origem do endereço de e-mail a fim de se passar pelo terceiro. Estes placeholders são alvos para retransmissão de spam porque usam um ponto de extremidade anônimo que permite que qualquer pessoa insira qualquer texto ou link que quiser.
Para evitar esse risco de sua conta virar um alvo para retransmissão de spam, configure a sua instância para ser fechada ou restrita, conforme discutido em Configuração do acesso de usuários finais. Do contrário, em uma instância aberta do Zendesk Support, não utilize os placeholders indicados a seguir no assunto nem no corpo dos seus gatilhos de primeira resposta; em vez disso, use texto estático. Isso garante que a notificação por e-mail enviada quando um ticket é criado, por exemplo, não substitua uma saudação que deveria ser "Olá, Amanda Smith" por "Olá, www.spam.com". Usar estes placeholders em outros gatilhos (após a primeira resposta) é aceitável, pois já foi estabelecido que a interação é genuína.
Práticas recomendadas:
Use uma convenção de nomenclatura e se atenha a ela. O ideal é que você consiga identificar a função de um gatilho com base em seu nome. Você poupará muito tempo se não tiver de clicar em cada gatilho para saber qual é a sua função. Eis alguns exemplos:
Definir prioridade - normal
Definir programação - América do Norte
Atribuir para grupo - nível 1
Notificar solicitante sobre atualização de comentário
Se sua lista de gatilhos se estender por mais de uma página, a convenção de nomenclatura será muito importante. Você pode pesquisar gatilhos com base em seu título.
A ordem dos gatilhos é importante. O sistema verificará cada gatilho sempre que um ticket for criado ou atualizado. Minha sugestão é ordenar seus gatilhos da seguinte maneira:
- Alterar/atualizar valores do ticket - os gatilhos que alteram valores de tickets como prioridades, status ou qualquer outro valor de campo, ou que adicionam tickets, devem estar no começo da lista. Isso porque esses gatilhos podem afetar as atribuições e notificações dos tickets.
- Atribuição de tickets - os gatilhos que podem atribuir tickets para grupos ou agentes individuais devem ser listados depois dos tickets que atualizam qualquer outro valor do ticket.
- Notificações - os gatilhos que enviam notificações aos usuários ou alvos devem ser listados por último. Isso porque você quer que o sistema faça todas as alterações necessárias antes que os emails de notificação sejam enviados.
Dentro de cada uma das categorias listadas acima, é melhor ordenar seus gatilhos das condições específicas às gerais. Isso evitará que seus gatilhos genéricos sejam disparados antes de seus gatilhos mais específicos.
Quando possível, mantenha seus gatilhos simples e deliberados. Quanto mais simples seus gatilhos, mais fácil será mantê-los conforme você aumentar ou alterar a administração.
Perguntas que você deve se fazer:
- Seus agentes passam o dia todo no Zendesk ou em seus emails?
- Quais de seus agentes precisam de notificações por email?
- Quando eles precisam ser notificados?
- Quando seus usuários finais precisam ser notificados?
- Quais itens de seu fluxo de trabalho podem ser automatizados?
- Quais itens de seu fluxo de trabalho precisam ser automatizados?
- Como seus gatilhos de notificação devem ser formulados?
Saiba mais sobre como criar e gerenciar gatilhos aqui,
Automações
As automações são ações do sistema baseadas em tempo. Elas são executadas de hora em hora e geralmente têm condições baseadas em tempo. Você pode usar as automações para fazer o seguinte:
- Atribuir tickets para um agente específico ou grupo de agentes.
- Alterar os valores do campo de ticket ou adicionar/remover tags.
- Notificar usuários (ou alvos) dos tickets criados ou atualizados.
- Alterar os valores dos campos do usuário ou organização.
Você também pode ter notado que as ações que podem ser realizadas por automações são as mesmas que podem ser realizadas por gatilhos. A diferença entre eles não é quais ações eles podem executar, mas quais condições podem ativá-los. As automações permitem que você execute ações do sistema após x horas terem se passado de ou ao faltar x horas para um evento.
Possíveis armadilhas:
As automações são executadas uma vez por hora no máximo. Por isso, é difícil contar com elas para atualizações de alta prioridade. Se um ticket for recebido um minuto depois de a automação ser executada, você ainda verá o ticket como 0 horas desde a criação uma hora depois, quando for executado de novo.
Ao definir uma condição baseada em hora arredondada (como horas desde a criação é X) em vez de uma condição baseada em hora exata (como horas desde a criação é maior do que X), suas automações podem não ser executadas durante a hora em que seu ticket se qualifica. Assim, você corre o risco de perder notificações ou atualizações de tickets importantes.
Práticas recomendadas:
Antes de criar uma automação, reflita se é melhor usar um gatilho ou automação para obter os resultados desejados. Em muitas situações, os gatilhos são mais eficazes porque podem ser disparados instantaneamente.
Quando possível, use as condições maior que/menor que em vez de condições é ao criar automações baseadas em tempo. Isso impede que seu ticket seja ignorado sem disparar a automação. Observe que, ao fazer isso, você terá que adicionar uma condição e ação anuladora para evitar um loop (o sistema avisará se isso for necessário).
Para que funcione, basta fazer suas condições verificarem algo (como uma tag ou valor de campo) que o ticket não deva ter antes de a automação ser executada e então garantir que a automação faça uma alteração que desqualifique o ticket da próxima vez que a automação for executada. Assim, a automação não será executada diversas vezes.
Você pode usar as automações para criar um fluxo de trabalho impactar e solucionar automatizado. Isso garante que seus tickets não sejam esquecidos se o solicitante não responder e também impede que esses tickets obstruam suas visualizações desnecessariamente.
Perguntas que você deve se fazer:
- Isso deveria ser um gatilho ou automação?
- Você precisa que o sistema mande uma notificação ou entre em ação quando um ticket for esquecido?
- Por quanto tempo um ticket deve ficar com status "resolvido" antes de ser fechado?
- Como seus emails de notificação devem ser redigidos?
Saiba mais sobre como criar e gerenciar automações aqui.
Parte 2: programações e SLAs
Programações
As programações podem não ter tanto destaque quanto os gatilhos ou automações, mas podem ter uma função essencial em seu fluxo de trabalho mesmo assim. Ao definir as programações, você poderá:
- Executar ações do sistema com gatilhos e automações dentro ou fora do horário de operação.
- Especificar horas no horário de operação (em vez de horas corridas) com automações e SLAs.
- Fornecer metas de serviço precisas com SLAs.
Possíveis armadilhas:
A primeira programação é sua programação padrão e será aplicada a todos os tickets novos. Você não pode reorganizar suas programações, o que significa que você não pode definir uma programação nova ou antiga como sua programação padrão. Você terá que apagar todas as programações acima dela (ou alterar seu nome e propriedades) para definir uma nova programação como padrão.
Você pode adicionar feriados à sua programação, mas eles não são transmitidos de um ano para outro. Isso significa que você terá que inseri-los a cada ano manualmente.
Os feriados são datas que serão retiradas da sua programação. Isso significa que, se você trabalhar somente por meio período, seus SLAs baseados no horário de operação serão pausados o dia todo. (Isso pode ser bom, dependendo da sua perspectiva).
Você não pode clonar programações. Isso significa que você terá que inserir seus feriados manualmente a cada ano de sua programação.
Não se esqueça de definir seu fuso-horário! Sua programação só funcionará se estiver no fuso-horário correto. Em alguns tipos de plano, você pode definir o fuso-horário em cada programação individual. Em outros tipos de plano, você pode definir a programação aqui.
Práticas recomendadas:
Faça um plano antes de começar a mexer nas programações. Insira sua programação padrão (se você tiver uma) primeiro. Essa programação será aplicada a todos os tickets novos por padrão, o que significa que todos os SLAs aplicados ao ticket que usem o horário de operação seguirão essa programação.
Se você usa diversas programações, use os gatilhos para atribuir programações aos tickets. Você pode criar um gatilho que, quando um ticket é atribuído a um grupo x, o atribui a uma programação, por exemplo. Se você fizer isso para todas as programações, não importará qual das suas programações é definida como padrão.
Você não pode clonar programações, mas pode clonar feriados, sim! Você terá que inseri-los manualmente mesmo assim, mas poderá cloná-los e alterar as datas. Esse é o melhor modo de inserir seus feriados recorrentes.
Ao criar feriados, você não pode definir horários reduzidos. Todo o dia é dispensado de sua programação. Use esses dias para tirar o atraso, pois geralmente eles têm um volume menor.
Perguntas que você deve se fazer:
- Você dá suporte aos seus usuários finais 24 horas por dia, 7 dias por semana, 365 dias por ano?
- Alguma de suas equipes está disponível somente durante horários ou dias específicos?
- Você tem algum feriado com horários reduzidos?
- Quantas programações diferentes você deve criar?
As programações de operação não estão disponíveis nos planos Team. Saiba mais sobre como criar e gerenciar programações aqui.
Políticas de SLA
Muitas empresas têm um compromisso com seus clientes que determina a duração esperada de determinados eventos.
Os contratos de nível de serviço do Zendesk permitem que você dê prioridade aos seus tickets adicionando metas de serviço a eles. As metas disponíveis incluem:
- Tempo da primeira resposta (o tempo entre a criação do ticket e o primeiro comentário público de um agente).
- Tempo de espera do solicitante (o tempo total que um ticket passa nos status Novo, Aberto e Em espera).
- Tempo de trabalho do agente (o tempo total que um ticket passa nos status Novo e Aberto).
- Tempo até a próxima resposta (o tempo entre o comentário do usuário final e o próximo comentário público do agente).
- Atualização periódica (o tempo entre o comentário público de um agente e o próximo comentário público de um agente).
- Atualização com pausa (o tempo entre cada comentário público dos agentes quando os tickets estão nos estados Novo, Aberto e Em espera. Ele é pausado quando o ticket é colocado no status Pendente).
Possíveis armadilhas:
Os SLAs da Zendesk exigem que você use o campo de prioridade do sistema. Se um ticket não receber uma prioridade, suas políticas de SLA não serão aplicadas a ele.
Se os seus SLAs forem baseados no horário de operação e você tiver diversas programações, terá que garantir que cada ticket tenha a programação apropriada aplicada. Se não for especificado, cada ticket usará a programação de operação padrão.
A meta de tempo da primeira resposta será satisfeita instantaneamente quando um agente criar um ticket (mesmo se definir o solicitante como usuário final). Isso ocorre porque a descrição do ticket será contada como o primeiro comentário público de um agente. Já que essa meta será atendida instantaneamente, parecerá que o ticket já foi resolvido.
A meta de tempo da próxima resposta não funcionará para tickets internos. A meta mede o tempo entre o comentário de um usuário final e o próximo comentário público do agente, então essa meta vai ignorar qualquer ticket solicitado por um agente.
Evite usar todas as metas em uma política. Decida entre o tempo de espera do solicitante, tempo de trabalho do agente ou nenhum dos dois. Usar essas duas metas na mesma política é desnecessário e complicaria demais as coisas.
As violações de SLA não estão disponíveis como eventos qualificadores para serem usados em gatilhos. Isso significa que não há uma maneira de criar um gatilho imediato de notificação de violação.
Práticas recomendadas:
Há seis tipos de metas diferentes disponibilizadas para você. Você não precisa (e nem deve) usar todas em uma política.
As metas de tempo da primeira resposta são uma maneira ótima de garantir que todos os tickets novos sejam gerenciados dentro de um período satisfatório. As metas de tempo da próxima resposta são tão importantes quanto pelo mesmo motivo. Geralmente, recomendamos criar as metas de tempo de próxima resposta para que sejam muito semelhantes ou totalmente iguais às metas de tempo da primeira resposta dentro da mesma política.
Escolha um ou nenhum dos dois entre tempo de trabalho do agente e tempo de espera do solicitante, pois ambos medem o tempo que demora para solucionar um ticket. O tempo de trabalho do agente é medido da perspectiva do agente, então, ele é pausado quando os tickets estão em espera e/ou pendentes. O tempo de espera do respondente é medido da perspectiva do solicitante, então, só é pausado quando um ticket está pendente.
Escolha um ou nenhum entre atualização periódica e atualização com pausa, pois ambas medem o tempo entre comentários públicos feitos por agentes.
Perguntas que você deve se fazer:
- Você tem obrigação contratual de cumprir metas de serviço específicas?
- Você tem metas de serviço internas?
- Você precisa de diversas políticas ou de uma política geral?
- Como você prioriza seus tickets?
- Você tem uma meta de serviço para o tempo de resolução de um ticket?
Se sim, ela deve ser medida da perspectiva do solicitante ou do agente? - Você fornece suporte 24 horas por dia, 7 dias por semana, 365 dias por ano?
Você quer verificar suas metas em comparação a horas corridas ou à sua programação no horário de operação?
As políticas de SLA não estão disponíveis nos planos Team. Saiba mais sobre como criar e gerenciar SLAs aqui.
Parte 3: macros e visualizações
Macros
Macros são scripts ativados por agentes que podem executar diversas ações em um ticket de uma só vez. É importante saber que uma macro só pode fazer o que um agente pode fazer e que as alterações do ticket só serão salvas depois que o agente o atualizar.
Usar macros pode aumentar a produtividade de seus agentes reduzindo seu número de cliques.
As macros podem:
- Adicionar texto de comentário
- Atualizar campos de ticket (apenas de lista suspensa e caixas de seleção)
- Adicionar ou remover tags do ticket
- Adicionar CCs
- Alterar o atribuído
- Definir o assunto do ticket (título)
- Adicionar anexos aos comentários do ticket
Possíveis armadilhas:
As macros são basicamente atalhos para agentes. A macro só pode fazer o que o usuário atual pode fazer. Por exemplo, se um agente não tiver permissão para editar tags de ticket, a macro não adicionará nem removerá tags quando esse agente executar a macro.
As macros não atualizam os campos de texto, texto multilinha, data, numéricos ou de expressão regular do ticket.
Práticas recomendadas:
Assim como os campos de lista suspensa, você pode aninhar macros. O aninhamento das macros é uma maneira ótima de organizá-las e deixá-las limpas.
Você pode executar diversas macros em uma atualização de ticket. Isso significa que você não precisa criar uma macro para todas as situações possíveis. Mantenha a simplicidade.
Use placeholders! Começar seus comentários com {{requester.first_name}} fará com que até suas respostas mais genéricas pareçam personalizadas. Você também pode usar placeholders quando definir o assunto do ticket.
Você pode atribuir macros para todos os agentes ou para grupos específicos. Se uma macro só deve ser vista por alguns de seus agentes, não se esqueça de restringir a marco para esses agentes para reduzir os excessos.
Você pode pesquisar as macros. Comece a digitar o título da macro quando estiver no menu de macros dentro de um ticket para filtrá-las no menu.
Para ser fácil de pesquisar pelas macros, crie uma convenção de nomenclatura e se atenha a ela.
Use as macros para atualizar vários tickets de uma só vez. Você pode fazer isso em sua tela de visualizações marcando as caixas ao lado de diversos tickets e pressionando o botão Editar tickets no canto superior direito. Quando estiver lá, aplique uma macro e envie.
Você pode usar gatilhos e automações junto com as macros. Você pode ter uma macro que adiciona uma tag que ativa um gatilho imediatamente, por exemplo. Imagine só quantas possibilidades!
Perguntas que você deve se fazer:
- Quais são os motivos mais comuns para o envio de tickets por usuários finais?
- O que o texto de seu comentário deve dizer?
- Sua macro deve deixar um comentário público ou privado?
- Quais agentes devem ter acesso a quais macros?
As macros estão disponíveis em todos os planos. Saiba mais sobre como criar e gerenciar macros aqui.
Visualizações
Guardei o melhor para o final. As visualizações são muito provavelmente a parte mais importante de seu fluxo de trabalho. Elas determinam quais ticket são visíveis de imediato por seus agentes e a ordem em que devem ser trabalhados.
As visualizações NÃO são pastas. Elas são pesquisas salvas ou bancos de dados com filtros. Imagine que elas são como listas de reprodução inteligentes do iTunes.
Possíveis armadilhas:
Não crie visualizações complicadas demais. Quanto mais condições suas visualizações tiverem, mais filtrados seus resultados serão. Isso pode ser bom, mas também pode ser desastroso. Se você tiver condições demais, pode acabar perdendo tickets.
Se você tiver visualizações demais, seus agentes podem não priorizar seus tickets como você gostaria. Isso pode ser evitado reduzindo suas visualizações para apenas o necessário.
Se você deixar seu navegador aberto em uma visualização, ela não será atualizada automaticamente. Ela será atualizada toda vez que você clicar na visualização (ou atualizar a página).
As visualizações podem mostrar apenas 30 tickets por página. Se suas visualizações não estiverem ordenadas corretamente, tickets importantes podem ser perdidos.
Práticas recomendadas:
Assim como as macros, as visualizações podem ser atribuídas para todos os agentes ou para grupos específicos. Em muitos casos, faz sentido criar visualizações personalizadas para cada um dos seus grupos. Isso garantirá que cada agente veja apenas informações relevantes.
Se você estiver usando SLAs, faz sentido ordenar suas visualizações por Próxima violação de SLA. Isso fará com que todos os tickets acabem sendo filtrados para o topo.
Use o botão Play! Ele fica no canto superior direito da sua página de visualizações e coloca você direto no próximo ticket disponível em sua visualização.
Perguntas que você deve se fazer:
- Como os tickets devem ser priorizados?
- Quais tickets cada grupo deve ver?
- Como você classifica seus tickets?
Saiba mais sobre como criar e gerenciar visualizações aqui.