Política de múltiplos SLAs por ticket no Zendesk: Como configurar e otimizar

Se você está gerenciando uma equipe de suporte ocupada, provavelmente já se perguntou: posso aplicar diferentes SLAs ao mesmo ticket dependendo da situação? Talvez você queira um SLA mais rápido para clientes VIP, mas também precise de metas diferentes com base no canal que eles usaram. A resposta curta é que o Zendesk limita cada ticket a uma política de SLA padrão ativa e uma política de SLA de grupo ativa a qualquer momento. Mas isso não significa que você está sem opções. Você só precisa entender como o sistema funciona.

Este guia explica exatamente como funciona a arquitetura de políticas de SLA do Zendesk, por que existe a limitação de uma única política e estratégias comprovadas para organizar suas políticas para lidar com cenários de suporte complexos. Quer você esteja configurando SLAs pela primeira vez ou investigando por que a política errada continua sendo aplicada aos seus tickets, você encontrará respostas práticas aqui.

O que é o rastreamento de SLA do Zendesk?

Antes de mergulharmos em múltiplas políticas, vamos esclarecer com o que estamos trabalhando. Um SLA (Service Level Agreement ou Acordo de Nível de Serviço) no Zendesk é essencialmente um cronômetro atrelado a uma promessa. Ele especifica com que rapidez sua equipe se compromete a responder e resolver os problemas dos clientes.

O rastreamento de SLA do Zendesk oferece uma maneira estruturada de definir esses compromissos e medir se você os está cumprindo. A plataforma oferece várias métricas que você pode rastrear:

Cada métrica serve a um propósito diferente, e a maioria das equipes começa com o Tempo de Primeira Resposta e o Tempo Total de Resolução antes de adicionar complexidade.

Um ticket do Zendesk pode ter várias políticas de SLA?

Aqui está a resposta direta: não, um único ticket não pode ter várias políticas de SLA padrão ativas simultaneamente. Em qualquer momento, um ticket pode ter exatamente uma política de SLA padrão e, se você estiver em um plano Enterprise, uma política de SLA de grupo.

Isso não é um erro ou descuido. É uma escolha de design deliberada que evita metas conflitantes. Imagine se uma política dissesse "responder em 1 hora" e outra dissesse "responder em 4 horas" — qual delas o Zendesk deveria rastrear? Em vez de tentar conciliar requisitos concorrentes, o Zendesk aplica a primeira política correspondente e para ali.

A frase-chave é "a qualquer momento". A política de SLA de um ticket pode mudar durante seu ciclo de vida se as condições mudarem. Por exemplo, se a prioridade de um ticket for escalonada de Normal para Urgente, e suas políticas tiverem metas diferentes para cada prioridade, o ticket adotará as metas de Urgente a partir de então. Mas ele ainda não terá várias políticas ativas ao mesmo tempo.

É aqui que entender o sistema de ordenação de políticas do Zendesk se torna crítico.

Como o Zendesk determina qual política de SLA se aplica

Quando um ticket é criado ou atualizado, o Zendesk executa uma sequência específica:

1. Os gatilhos (triggers) são disparados primeiro - Quaisquer regras de automação que definam campos, atribuam tickets ou adicionem tags são executadas antes da avaliação do SLA.
2. As políticas de SLA são verificadas - Começando do topo da sua lista de políticas, o Zendesk procura a primeira política cujas condições correspondam ao ticket.
3. A primeira correspondência vence - Assim que uma política correspondente é encontrada, ela é aplicada e a busca para.
4. Os SLAs de grupo são avaliados separadamente - O mesmo processo ocorre para os SLAs de grupo se você estiver em um plano Enterprise.

Essa avaliação de cima para baixo é o motivo pelo qual a ordem das políticas importa imensamente. Um ticket pode tecnicamente corresponder a três políticas diferentes, mas apenas a de classificação mais alta será aplicada.

Vejamos um exemplo concreto. Digamos que você tenha estas políticas nesta ordem:

1. Clientes VIP - Primeira resposta em 1 hora
2. Clientes Enterprise - Primeira resposta em 4 horas
3. Suporte Padrão - Primeira resposta em 8 horas

Se um ticket chegar de um cliente que possui a tag "VIP" e pertence a uma organização "Enterprise", e as condições de ambas as políticas coincidirem, a política VIP vence porque está no topo. O cliente recebe a meta de 1 hora, não a de 4 horas.

Esse comportamento é, na verdade, uma funcionalidade, não uma limitação. Ele permite criar uma hierarquia de níveis de serviço onde seus clientes mais importantes sempre recebem os tempos de resposta mais rápidos, mesmo que possam se qualificar para várias políticas.

Melhores práticas para organizar configurações de múltiplas políticas de SLA no Zendesk

Como você não pode aplicar várias políticas a um ticket, precisa projetar sua estrutura de políticas para que a política correta seja aplicada automaticamente. Veja como administradores experientes do Zendesk abordam isso.

Ordene as políticas da mais específica para a menos específica

A regra de ouro da organização de SLAs é colocar suas políticas mais restritivas e específicas no topo e suas políticas amplas e abrangentes (catch-all) na parte inferior. Pense nisso como um funil: os casos mais urgentes e importantes são capturados pelas políticas do topo, enquanto todo o resto flui para os seus padrões.

Aqui está uma estratégia de ordenação recomendada:

Use gatilhos para definir a prioridade antes da avaliação do SLA

Uma das técnicas mais eficazes para gerenciar cenários complexos de SLA é usar gatilhos para padronizar os campos do ticket antes que o sistema de SLA os avalie. Como as políticas de SLA não podem usar todos os campos do ticket como condições (notavelmente, não podem usar o status ou certos campos personalizados), converter sua lógica de negócios no campo de Prioridade (Priority) oferece mais controle.

Aqui está um fluxo de trabalho prático:

1. Crie gatilhos que avaliem os tickets recebidos - Verifique organizações VIP, palavras-chave específicas, indicadores de urgência.
2. Defina a Prioridade adequadamente - Use o gatilho para atribuir prioridade Urgente, Alta, Normal ou Baixa.
3. Construa políticas de SLA em torno da Prioridade - Suas políticas podem então usar a Prioridade como uma condição primária, com metas diferentes para cada nível.

Essa abordagem é especialmente valiosa ao trabalhar com SLAs de grupo, que possuem opções de condições mais limitadas do que os SLAs padrão.

Configure políticas específicas por canal

Diferentes canais de suporte têm diferentes expectativas dos clientes. Alguém que entra em contato via chat espera uma resposta imediata, enquanto clientes de e-mail podem ficar satisfeitos com algumas horas. Criar políticas separadas para cada canal permite atender a essas expectativas variadas sem sobrecarregar sua equipe.

Uma configuração comum se parece com esta:

A chave é usar a condição "Canal é/não é" para segmentar suas políticas. Muitos administradores colocam as políticas de mensagens no topo de sua lista, já que esses tickets são os mais sensíveis ao tempo.

Trabalhando com SLAs de grupo junto com políticas padrão

Se você estiver em um plano Zendesk Enterprise, terá acesso aos SLAs de grupo — às vezes chamados de Acordos de Nível Operacional ou OLAs (Operational Level Agreements). Estes são cronômetros voltados internamente que medem quanto tempo um ticket permanece atribuído a um grupo específico, em vez de rastrear os tempos de resposta voltados para o cliente.

O importante a entender é que os SLAs de grupo operam de forma independente dos SLAs padrão. Um ticket pode ter um de cada simultaneamente. Isso significa que você pode ter:

• Um SLA padrão rastreando que você responda a um cliente em até 4 horas.
• Um SLA de grupo rastreando que a equipe de Engenharia detenha o ticket por no máximo 8 horas.

Esse rastreamento duplo é particularmente útil para tickets que passam por vários departamentos. Você pode ver tanto o seu desempenho em relação aos compromissos com o cliente quanto a eficiência com que o trabalho está se movendo pelas suas equipes internas.

No entanto, os SLAs de grupo possuem limitações. Eles só podem usar a atribuição de grupo como uma condição obrigatória, além de condições adicionais opcionais. Eles não oferecem a gama completa de campos de condição disponíveis nos SLAs padrão. E, fundamentalmente, eles não conseguem distinguir entre um grupo que recebe um ticket como uma atribuição primária versus um que o recebe por meio de um escalonamento.

Cenários comuns para configurações de múltiplas políticas de SLA no Zendesk

Vamos percorrer alguns cenários do mundo real e como estruturar suas políticas para cada um.

Cenário 1: Clientes VIP precisam de tempos de resposta mais rápidos

Você tem uma mistura de clientes padrão e VIP, e os VIPs precisam de um serviço mais rápido, independentemente do canal ou tipo de problema.

Solução: Crie uma política VIP no topo da sua lista usando tags de organização ou campos de usuário para identificar os VIPs. Defina metas agressivas. Em seguida, tenha políticas padrão abaixo para todos os outros.

Cenário 2: Canais diferentes precisam de tempos de resposta diferentes

Sua equipe lida com chat (imediato) e e-mail (menos urgente), e você deseja metas apropriadas para cada um.

Solução: Crie políticas separadas para cada canal no topo da sua lista. Use as condições "Canal é Mensagens" e "Canal não é Mensagens". Certifique-se de que as políticas de mensagens estejam em uma posição superior na ordem, pois esses tickets são os mais sensíveis ao tempo.

Cenário 3: Tickets escalonados precisam de rastreamento interno

Tickets que vão do Suporte para a Engenharia precisam de metas de propriedade interna separadas dos SLAs voltados para o cliente.

Solução: Use SLAs padrão para compromissos com clientes. Crie SLAs de grupo para cada equipe interna com metas de tempo de propriedade. Lembre-se apenas de que os SLAs de grupo não conseguem diferenciar entre um ticket atribuído diretamente à Engenharia versus um escalonado do Suporte — ambos dispararão o mesmo cronômetro de propriedade.

Cenário 4: Lidando com escalonamentos externos

Às vezes, você precisa escalonar tickets para fornecedores ou parceiros que trabalham em ferramentas fora do Zendesk (como Jira ou via Slack).

Limitação: Os SLAs de grupo não podem medir o tempo gasto com equipes externas, pois essas equipes não são grupos do Zendesk.

Solução alternativa: Alguns administradores criam grupos "reservados" (placeholders) para escalonamentos externos. O ticket é atribuído ao grupo externo enquanto aguarda, o que pausa o SLA de grupo interno. Quando a equipe externa responde, o ticket é reatribuído à equipe interna e o SLA de grupo é retomado.

Otimizando o desempenho do SLA com IA

Cumprir metas agressivas de SLA de forma consistente é um desafio, especialmente à medida que o volume de tickets aumenta. É aqui que as ferramentas de IA podem ajudar.

Cumprir as metas de Tempo de Primeira Resposta costuma ser o maior desafio. Para perguntas comuns, como redefinições de senha, consultas de status de pedidos ou solução de problemas básicos, o Tempo de Primeira Resposta ideal é efetivamente instantâneo. Os agentes de IA podem fornecer respostas imediatas e precisas a essas consultas rotineiras, satisfazendo seu SLA antes mesmo que um agente humano veja o ticket.

Para problemas mais complexos que exigem perícia humana, os copilotos de IA podem reduzir o tempo que os agentes gastam redigindo respostas. Ao extrair informações da sua base de conhecimento e sugerir respostas com base em resoluções anteriores, os agentes podem responder mais rápido sem sacrificar a qualidade. Isso ajuda a melhorar tanto as métricas de Tempo de Próxima Resposta quanto o Tempo de Resolução geral.

No eesel AI, construímos nossa plataforma para se integrar diretamente ao Zendesk e enfrentar exatamente esses desafios. Nosso Agente de IA pode lidar com tickets comuns de forma autônoma, cumprindo instantaneamente suas metas de Tempo de Primeira Resposta para consultas rotineiras. Para problemas complexos que exigem julgamento humano, nosso Copiloto de IA redige respostas precisas e personalizadas aprendendo com seus tickets anteriores, macros e conteúdo da central de ajuda. Isso reduz o tempo que os agentes gastam procurando informações e os ajuda a responder dentro das janelas de SLA.

O que torna isso particularmente valioso para o gerenciamento de SLA é a capacidade de simulação. Antes de implantar qualquer automação de IA, você pode testá-la contra seus tickets históricos para ver exatamente como ela teria se saído em relação aos seus SLAs existentes. Isso permite que você ajuste sua configuração com confiança.

Comece a otimizar suas políticas de SLA do Zendesk hoje mesmo

A limitação de uma política por ticket do Zendesk não é uma restrição que você precisa contornar — é uma estrutura para criar níveis de serviço claros e hierárquicos. Ao ordenar suas políticas da mais específica para a menos específica e usar gatilhos para padronizar os campos do ticket antes da avaliação do SLA, você pode lidar com praticamente qualquer cenário de suporte.

Aqui está um rápido checklist para revisar sua configuração atual:

• Suas políticas de clientes mais importantes estão no topo da lista?
• Você tem uma política abrangente (catch-all) na parte inferior para garantir que cada ticket tenha um SLA?
• Você está usando gatilhos para definir a prioridade de forma consistente antes da avaliação do SLA?
• Você configurou o horário de atendimento para que os SLAs não contem o tempo em que sua equipe está offline?
• Seus agentes estão treinados para entender o que significam os selos de SLA e como priorizar seu trabalho?

Se você deseja melhorar seu desempenho de SLA além de apenas rastrear métricas, considere como a IA pode ajudar. Automatizar respostas a perguntas comuns, auxiliar agentes com rascunhos de respostas e fornecer acesso instantâneo ao conhecimento relevante pode ajudar você a atingir suas metas de forma mais consistente. Você pode conectar sua conta do Zendesk ao eesel AI e testar a configuração em relação aos seus tickets históricos para ver o impacto potencial no seu desempenho de SLA.