Rastreador de SLA: crie prazos, pausas e relatórios por equipe

Por que as equipes de operações de atendimento perdem o controle dos prazos de SLA

As equipes de operações de atendimento raramente perdem um SLA porque alguém ignora uma data. Os prazos mudam, os tickets passam de uma pessoa para outra e as respostas dos clientes podem interromper o trabalho por dias. Uma planilha com uma única coluna de prazo deixa de funcionar se alguém não a atualizar depois de cada mudança.

O primeiro problema é tratar toda meta de SLA como um único prazo. A meta de primeira resposta mede a rapidez com que um agente confirma uma nova solicitação. A meta de resolução mede quanto tempo a equipe tem para solucioná-la. Um ticket pode cumprir a meta de resposta em 15 minutos e ainda perder a meta de resolução três dias depois. Um único prazo não mostra qual compromisso foi descumprido.

A responsabilidade cria outro problema. Um agente pode responder, um especialista pode investigar e um gestor pode aprovar a solução. Se ninguém for responsável pelo cronômetro de SLA ativo, cada pessoa pode presumir que outra está acompanhando a situação. O ticket permanece na fila até o tempo acabar.

Considere um problema de acesso à conta registrado às 10h. O agente responde às 10h12, cumprindo uma meta de resposta de 30 minutos, e depois pede uma captura de tela às 10h20. O cliente responde na tarde do dia seguinte. Se o rastreador contar esse período de espera na meta de resolução, ele responsabilizará o suporte por um tempo que a equipe não podia usar. Se pausar o cronômetro, mas não o reiniciar, o resultado ficará errado na direção oposta.

Um rastreador deve oferecer a cada ticket um registro operacional compartilhado: responsável, equipe, prioridade, prazos de resposta e resolução, estado do cronômetro, motivo da pausa e histórico de alterações. Assim, os agentes podem se concentrar no trabalho próximo de uma violação, enquanto os gestores identificam atrasos causados por equipe insuficiente, transferências ou tempo de espera do cliente.

Planilhas manuais podem funcionar para uma fila pequena e estável. Quando os prazos dependem de prioridade, horário comercial, reatribuição e pausas, o rastreador precisa seguir regras consistentes.

Defina o que cada registro de SLA precisa ter

Todo ticket precisa de detalhes suficientes para explicar quem é o responsável, qual compromisso se aplica e se o cronômetro deve continuar. Comece pelo básico: cliente ou conta, prioridade, equipe atribuída, responsável pelo ticket e status atual.

Depois, adicione os campos que controlam o prazo:

• Política de SLA, como «Suporte padrão» ou «Suporte prioritário»
• Horário de início
• Prazo da primeira resposta e prazo de resolução
• Motivo da pausa e horário em que ela começou
• Horário de retomada ou duração total das pausas

Mantenha a primeira resposta e a resolução completa separadas. Uma equipe pode prometer uma primeira resposta em até quatro horas úteis, mas permitir dois dias úteis para a resolução. Um único prazo deixa uma confirmação rápida esconder um ticket ainda não resolvido.

Não peça aos agentes que selecionem «violado» manualmente. Calcule esse estado com base no horário atual, no prazo, no status do ticket e nas pausas válidas. Por exemplo, um ticket viola o SLA de resolução quando o prazo passa, ele continua aberto e o cronômetro está ativo.

O AppMaster pode manter essa lógica em um só lugar. O Data Designer permite modelar os campos dos tickets, enquanto um Business Process visual pode calcular prazos e o status de violação sempre que um agente criar ou atualizar um ticket.

Defina as regras de SLA antes de criar o rastreador

Regras claras tornam os resultados de SLA mais justos. Defina a meta para cada categoria de ticket antes de criar fórmulas ou relatórios. Caso contrário, dois agentes podem tratar a mesma solicitação de maneiras diferentes e a contagem de violações perde o sentido.

A maioria das equipes varia as metas de acordo com a prioridade, o plano do cliente e o tipo de solicitação. Mantenha a primeira versão pequena. Por exemplo, incidentes urgentes em produção podem exigir uma primeira resposta em até uma hora, problemas de acesso de planos pagos em até quatro horas úteis e dúvidas rotineiras em até dois dias úteis.

Escreva cada regra em linguagem simples. «Um problema de cobrança de alta prioridade para um cliente premium precisa de uma primeira resposta em até duas horas úteis» indica exatamente quais dados devem ser armazenados: prioridade, plano, tipo de solicitação, horário de criação e horário da primeira resposta.

Defina o calendário de trabalho

Decida se as metas funcionam o tempo todo ou apenas durante o horário de atendimento. Se o suporte funciona de segunda a sexta, das 9h às 17h, um ticket recebido na sexta-feira às 16h30 com uma meta de duas horas deve vencer na segunda-feira às 10h30, não na sexta à noite.

Documente os dias úteis, o horário de atendimento, o fuso horário, os feriados e qualquer calendário separado para incidentes 24 horas por dia, 7 dias por semana. Sempre que possível, use um calendário nomeado por política. Equipes com clientes em países diferentes podem precisar de calendários regionais, mas criar um calendário para cada cliente gera manutenção desnecessária.

Defina os pontos de início e a responsabilidade pelas políticas

Escolha exatamente quando o cronômetro começa. Tickets novos geralmente começam quando o sistema os recebe. Tickets reabertos precisam de uma regra separada: continuar o tempo restante, reiniciar o cronômetro original ou começar uma nova meta. Escolha um método e aplique-o de forma consistente.

Atribua as alterações de política a uma pessoa ou a um grupo pequeno. Os agentes podem corrigir dados do ticket, mas não devem alterar prazos para remover uma violação. Armazene a versão da política em cada registro e registre exceções aprovadas com o motivo e a data.

Um aplicativo do AppMaster pode manter as políticas em uma área administrativa e aplicar a regra correspondente quando um ticket entra no sistema. Isso substitui fórmulas separadas de planilhas por um único cronômetro consistente.

Mapeie os dados por trás do rastreador

Mantenha a primeira versão simples o suficiente para que um líder de operações possa consultar um ticket e entender por que seu prazo mudou.

Comece com uma tabela de tickets contendo ID, assunto, cliente, prioridade, status, horário de criação, horário da primeira resposta, horário de resolução, prazos, responsável atribuído e equipe responsável. Cada ticket deve ter um único responsável atual e uma única equipe, mesmo quando várias pessoas comentarem nele.

Crie registros separados para equipes e políticas de SLA. Um registro de equipe pode armazenar seu nome e o calendário de horário comercial. Cada política deve indicar quais tickets abrange, suas metas de resposta e resolução, o tipo de cronômetro e se o tempo de espera do cliente pausa o cronômetro.

Adicione um registro de feriados com a data, a equipe ou localidade relevante e uma descrição curta. Armazene todos os horários em um único fuso consistente, geralmente UTC, e mostre o horário local na interface quando necessário. Misturar fusos causa erros perto de fins de semana e mudanças de horário de verão.

Mantenha um histórico de status em vez de substituir o passado. Cada entrada deve registrar o ID do ticket, o status antigo e o novo, o horário do evento e a pessoa ou regra que fez a alteração. Registre eventos como «Aguardando cliente», «Cliente respondeu», «Atribuído» e «Resolvido».

Esse histórico explica as mudanças nos prazos. Se um prazo passar de terça-feira de manhã para terça-feira à tarde, um gestor poderá ver que a equipe pausou o SLA por três horas enquanto aguardava o cliente. O Data Designer visual do AppMaster pode modelar esses registros relacionados, e seu Business Process Editor pode atualizar os prazos depois das mudanças de status.

Calcule os prazos dos tickets

Inicie o cronômetro em um evento claro, como o momento em que o sistema recebe um ticket de suporte. Não o inicie quando alguém visualizar o ticket por acaso. Salve o horário de início para que todos os cálculos posteriores usem a mesma referência.

Depois, selecione a política de SLA correspondente com base no plano do cliente, tipo de ticket, prioridade ou região. Em seguida, calcule o prazo:

1. Leia a meta do ticket, como um tempo de resposta de quatro horas.
2. Adicione apenas o tempo de trabalho permitido pela política.
3. Ignore horários de fechamento, fins de semana e feriados quando a política os excluir.
4. Salve o prazo no ticket.
5. Recalcule se uma mudança de prioridade, plano ou categoria selecionar outra política.

O horário comercial torna isso menos óbvio do que parece. Se um SLA de quatro horas começa às 16h e o suporte funciona das 9h às 17h, resta uma hora naquele dia. O ticket vence ao meio-dia do próximo dia útil, não às 20h.

Quando um ticket mudar de prioridade, mantenha o horário de início original e aplique a regra de escalonamento documentada. Algumas equipes aplicam a meta urgente desde o início original; outras iniciam uma nova meta quando o ticket é escalado. As duas abordagens podem funcionar se todos seguirem a mesma regra.

Mostre o prazo exato e o tempo restante. Rótulos como «restam 2h 15min», «vence em 1 dia» e «atrasado em 35min» ajudam os agentes a examinar uma fila mais rapidamente do que simples horários. Use um estado neutro para tickets dentro do prazo, um aviso quando o prazo estiver próximo e um estado claro de violação depois que ele passar.

Pause os cronômetros para respostas dos clientes

Pause o cronômetro apenas quando a equipe não puder avançar com o ticket sem o cliente. Os motivos comuns incluem aguardar informações, confirmação, acesso, aprovação ou arquivos. Um atraso interno, como esperar um colega, não deve pausar o SLA.

Use um conjunto curto e claro de status:

• Aguardando informações do cliente
• Aguardando aprovação do cliente
• Aguardando acesso do cliente
• Aguardando arquivos enviados pelo cliente

Quando um agente selecionar um desses status, salve o horário exato e o motivo da pausa. Registre também a mensagem ou o evento que solicitou a resposta do cliente. Assim, os supervisores poderão verificar se a pausa foi justificada.

Quando o cliente responder, reinicie o cronômetro no horário da resposta. Adicione o período de espera ao total paused time e recalcule o tempo restante conforme as regras de horário comercial. Uma espera de 90 minutos pelo cliente adia o prazo em 90 minutos, respeitando os horários de fechamento.

Mostre o tempo pausado na visão do ticket. Os agentes precisam saber se um ticket esperou 15 minutos ou três dias, e os supervisores devem conseguir identificar tickets que retornam repetidamente ao status de espera.

Limite os motivos de pausa aos permitidos pela política de SLA. Exija um evento de solicitação ao cliente antes de aceitar uma pausa. No AppMaster, um Business Process pode verificar o novo status, salvar o horário de início da pausa e rejeitar alterações inválidas antes de atualizar o registro de SLA.

Um e-mail automático de «recebemos sua mensagem» não deve reiniciar o cronômetro. Use uma mensagem recebida do cliente ou uma resposta confirmada pelo agente e mantenha todo o histórico de pausas no ticket.

Percorra um exemplo de atendimento ao cliente

Um cliente envia uma dúvida de cobrança na terça-feira às 10h: «Por que minha fatura mostra duas cobranças?». O rastreador cria o ticket B-184, atribui-o ao Suporte e aplica o SLA de cobrança. A equipe tem quatro horas úteis para enviar uma primeira resposta útil e oito horas úteis para resolver o problema.

O suporte funciona das 9h às 17h, de segunda a sexta. Às 10h35, um agente confirma que a equipe está verificando a conta. O cronômetro da primeira resposta para depois de 35 minutos, deixando 3 horas e 25 minutos. O ticket cumpre sua meta de primeira resposta.

Às 11h, o agente precisa do número da fatura e marca o ticket como «Aguardando cliente». O cronômetro de resolução pausa depois de uma hora de trabalho ativo. O rastreador armazena o início e o motivo da pausa.

O cliente responde às 15h30. O rastreador adiciona as 4 horas e 30 minutos de pausa ao prazo. O prazo original de resolução era terça-feira às 18h, portanto o prazo ajustado passa a ser quarta-feira às 14h30, depois que o tempo restante é levado para o próximo dia útil.

Um agente resolve o problema na quarta-feira às 15h10. O ticket está 40 minutos atrasado. Ele conta como uma resolução fora do prazo para o Suporte, enquanto a primeira resposta continua dentro do prazo.

Um relatório de violações deve mostrar essa divisão com clareza: o Suporte recebeu um ticket de cobrança, cumpriu a meta de primeira resposta, perdeu a meta de resolução por 40 minutos e passou 4 horas e 30 minutos aguardando o cliente. A idade total do ticket contaria uma história errada.

Relate violações de SLA por equipe

Um ticket viola o SLA quando o prazo passa antes que a ação exigida aconteça. Use o prazo ajustado depois de pausas válidas por espera do cliente.

Mantenha os tickets abertos em atraso separados dos tickets resolvidos fora do prazo. Tickets abertos em atraso precisam de atenção imediata. Tickets resolvidos fora do prazo pertencem aos relatórios de desempenho. Combinar os dois grupos esconde o trabalho urgente e torna o relatório mais difícil de usar.

Em cada período, agrupe os resultados pela equipe que era responsável pelo ticket quando o prazo venceu. Filtre por política, prioridade e intervalo de datas. Uma equipe de cobrança com uma política de resposta de quatro horas não deve ser comparada diretamente a uma equipe de escalonamento técnico com uma política de resolução de dois dias úteis.

Use contagens junto com taxas:

• Total de tickets com um SLA ativo
• Tickets resolvidos dentro da meta
• Tickets abertos em atraso
• Tickets resolvidos depois do prazo
• Taxa de violações, calculada como tickets violados divididos pelo total de tickets com SLA

Uma taxa de violações de 50% significa algo diferente quando vem de um ticket atrasado em dois, em vez de 50 tickets atrasados em 100. Analise as tendências junto com os detalhes dos tickets. Violações frequentes em tickets de alta prioridade podem indicar problemas nas regras de escalonamento ou nas transferências, e não na carga de trabalho geral.

Um relatório útil permite que o gestor abra a lista de tickets atrasados, veja a política e a prioridade e verifique quem era o responsável no momento da violação. Ele deve apoiar uma análise prática do trabalho que precisa ser corrigido, em vez de recompensar equipes por fechar tickets cedo demais.

Crie visões para agentes e gestores

Os agentes precisam de uma lista de trabalho curta, não de um relatório cheio de tickets antigos. Cada ticket aberto deve mostrar responsável, equipe, prioridade, prazo, estado do cronômetro e tempo restante. Registre imediatamente as mudanças de responsável quando um ticket passar de uma equipe para outra.

Use rótulos simples para os cronômetros. «Ativo» significa que a equipe é responsável pela próxima ação. «Pausado - aguardando cliente» significa que o cronômetro está parado. Mostre o tempo ativo separado do tempo pausado para que os usuários entendam por que um ticket permanece aberto por vários dias.

Uma visão do agente pode incluir tickets que vencem nas próximas quatro horas, tickets atrasados, tickets aguardando respostas dos clientes e tickets reatribuídos hoje. Envie avisos antes do prazo. Uma meta de resposta de quatro horas exige alertas mais antecipados do que uma meta de resolução de três dias.

Os gestores precisam de outra visão. Um relatório semanal pode agrupar tickets atrasados por equipe e mostrar a quantidade de violações, a porcentagem cumprida, o tempo médio de atraso e os tickets que continuam abertos depois do prazo. Inclua o responsável e a última atualização de cada item atrasado.

Mantenha um registro de auditoria para alterações de políticas. Se a equipe de operações mudar uma meta de oito para 12 horas, registre quem fez a alteração, quando e quais novos tickets usarão a regra. Os resultados históricos devem manter a regra que se aplicava quando cada ticket começou.

O AppMaster permite criar visões web separadas para agentes e gestores, mantendo os mesmos dados de tickets e as mesmas regras de negócio por trás das duas visões.

Erros que distorcem os resultados de SLA

Gráficos bem organizados ainda podem contar a história errada quando as regras por trás deles estão incorretas.

Trate as regras de tempo corretamente

Não calcule usando horas do calendário quando o acordo promete horas úteis. Um ticket aberto às 16h30 de sexta-feira com uma meta de resposta de oito horas úteis não viola o SLA às 0h30 de sábado. Conte apenas as horas de trabalho e os feriados definidos na política.

Tenha o mesmo cuidado com as pausas. Um status «aguardando cliente» só deve pausar um SLA quando a equipe enviou uma solicitação clara e não pode continuar sem resposta. Pausar todo ticket com esse rótulo esconde atrasos que pertencem à equipe.

Mantenha as datas que explicam cada resultado: prazo original, política usada, horário de início e fim de cada pausa, motivo da pausa, prazo ajustado, horário de resolução e pessoa que fechou o ticket. Sem esse histórico, ninguém consegue verificar por que um ticket apareceu como dentro do prazo.

Conte a responsabilidade uma única vez

Use uma única regra de responsabilidade nos relatórios por equipe. Se o Suporte transferir um ticket para Cobrança, não conte a mesma violação para as duas equipes. Você pode atribuir o resultado à equipe que era responsável quando o prazo venceu e relatar as transferências separadamente.

Exija um horário de resolução antes de fechar um ticket. Um status fechado não prova quando o trabalho terminou. Por exemplo, se um ticket passar do Suporte para a Cobrança às 14h e violar o SLA às 15h, a Cobrança será responsável pela violação sob uma regra de responsabilidade no momento da violação. O relatório ainda pode mostrar a transferência anterior do Suporte sem adicionar uma segunda violação.

Verifique o rastreador antes do lançamento

Revise todas as políticas de SLA antes que os agentes dependam do rastreador. Cada política precisa de uma meta clara, como uma primeira resposta em quatro horas ou uma resolução em dois dias úteis, além do calendário aplicável. Defina uma política padrão para tickets que não correspondam a uma regra de cliente, plano ou prioridade.

Teste horários problemáticos, não apenas casos comuns:

• Crie um ticket pouco antes do fim do expediente e confirme que o tempo restante passa para o próximo dia útil.
• Crie um ticket antes de um fim de semana ou feriado e confirme que o prazo ignora o período fechado.
• Pause um ticket para aguardar uma resposta do cliente, adicione a resposta e confirme que o cronômetro retoma corretamente.
• Transfira um ticket entre equipes e verifique qual equipe será responsável por uma violação posterior.
• Feche um ticket depois do prazo e confirme que o rastreador registra a violação.

Compare os totais do painel com a lista de tickets por trás deles. Se um relatório disser que a Equipe A tem 12 violações, filtre os registros e conte-os. Isso identifica tickets duplicados, equipes ausentes e tickets reabertos contados duas vezes.

Defina as regras de acesso antes do lançamento. Os agentes devem atualizar os tickets que atendem, os gestores precisam de relatórios das equipes e os administradores devem controlar as configurações das políticas. No AppMaster, teste cada função com uma conta separada para que um gestor não precise de acesso de administrador para consultar os relatórios de violações de SLA.

Comece pequeno e melhore o fluxo de trabalho

Comece com um tipo de ticket e uma política de SLA. Uma equipe de suporte pode começar com solicitações padrão por e-mail e uma meta de primeira resposta em 24 horas. Isso basta para testar prazos, pausas aprovadas e registros de violações.

Peça a alguns profissionais de operações de atendimento que executem tickets reais no fluxo de trabalho, incluindo um caso normal, um caso de espera pelo cliente e um prazo perdido. Colete feedback específico. Os agentes podem precisar de status separados para aguardar um cliente e aguardar outra equipe. Os gestores podem descobrir que um rótulo genérico de «pausado» esconde informações importantes.

Quando uma planilha limitar o processo, crie o rastreador como um aplicativo sem código no AppMaster. Você pode criar formulários de tickets, definir a lógica dos cronômetros no Business Process Editor visual e oferecer painéis separados para agentes e gestores. O AppMaster pode gerar o backend, o aplicativo web e o aplicativo móvel nativo quando o rastreador precisar funcionar além de uma tabela compartilhada.

Mantenha os relatórios modestos no início: tickets abertos, tickets próximos de uma violação, tickets pausados e violações por equipe. Compare alguns prazos com verificações manuais, analise os tickets violados e seus períodos de pausa e altere uma regra de cada vez antes de testá-la novamente. Quando a equipe confiar nos cálculos, adicione outro tipo de ticket ou política de prioridade e repita as mesmas verificações.