Tempo Médio para Resolução (MTTR)

Fórmula do MTTR: MTTR = Soma de (Timestamp de Resolução - Timestamp de Criação para todos os tickets no período) / Número de Tickets Resolvidos no Período. A média bruta é altamente suscetível a distorções por um pequeno número de tickets de duração extremamente longa — um único bug não resolvido aberto por 90 dias pode distorcer a média dramaticamente, enquanto a mediana reflete a experiência típica do cliente com precisão. Support Ops deve relatar tanto a média quanto a mediana do MTTR, e também segmentar o MTTR por: prioridade do ticket (o MTTR de P1 deve ser de 2 a 4 horas para SaaS empresarial; o MTTR de P4 pode ser de mais de 10 dias úteis e é aceitável); tipo de ticket (tickets de faturamento fecham em horas; escalonamentos de engenharia podem levar semanas); canal (o MTTR de chat deve ser inferior a 15 minutos; o MTTR de e-mail é medido em horas); e nível do cliente (enterprise vs. SMB podem ter metas de MTTR muito diferentes). O MTTR relatado como um único número combinado confunde todas essas dimensões em um valor difícil de agir e fácil de manipular.

A redução do MTTR exige a identificação de onde o tempo é gasto — o processo de resolução tem fases distintas onde a melhoria é possível. Tempo de avaliação do agente (primeiro contato até o diagnóstico completo): reduzido por fluxos de trabalho de diagnóstico estruturados na base de conhecimento ("para [sintoma], verifique estas 5 coisas em ordem"), contexto da conta preenchido automaticamente a partir da integração com CRM e soluções sugeridas por IA com base no texto do ticket. Tempo de espera da engenharia (escalonamento de Nível 2 aguardando uma resposta da engenharia): reduzido pela definição de SLAs de escalonamento de Engenharia e monitoramento de conformidade; construção de ferramentas de diagnóstico de Nível 2 que permitem ao Nível 2 resolver problemas que antes exigiam engenharia; e construção de uma biblioteca de resolução para padrões comuns de escalonamento de engenharia. Tempo de espera do cliente (agente esperando que o cliente forneça informações adicionais): reduzido por agentes solicitando todas as informações necessárias em uma única mensagem, em vez de acompanhamentos sequenciais; reabertura automatizada baseada no status "aguardando cliente" para que os tickets não sejam marcados como resolvidos enquanto aguardam; e temporizadores de acompanhamento proativos (lembrete automatizado enviado ao cliente e ao agente se não houver resposta em 24 horas). Retenção pós-diagnóstico (solução conhecida, mas bloqueada por processo): reduzida pela autoridade claramente definida do agente para implementar correções comuns sem aprovação.

A relação MTTR-CSAT é não linear e contraintuitiva. Reduzir o MTTR geralmente melhora o CSAT — os clientes apreciam uma resolução mais rápida. Mas a redução do MTTR alcançada através de resoluções apressadas, fechamento prematuro de tickets ou correções superficiais danifica ativamente o CSAT: um ticket fechado em 2 horas sem realmente resolver o problema gerará uma pontuação CSAT muito baixa e provavelmente uma reabertura (medida como uma "taxa de recontato"). O ponto de tensão: quando a gerência incentiva a redução do MTTR como um KPI sem salvaguardas de CSAT, os agentes otimizam a velocidade de fechamento em detrimento da qualidade da resolução — tomando atalhos, marcando tickets como resolvidos antes de uma verificação completa e desviando problemas complexos para a base de conhecimento sem ajuda genuína. Support Ops mitiga isso ao: relatar o MTTR juntamente com o CSAT e a taxa de recontato em cada dashboard operacional (tornando a manipulação óbvia através do sinal de recontato); dizer explicitamente aos agentes que um MTTR longo em um problema complexo tratado com cuidado é mais valorizado do que um MTTR rápido alcançado por desvio; e definir metas de MTTR por tipo de ticket que reflitam prazos realistas de qualidade de resolução, em vez de metas de velocidade aspiracionais.