Exemplos de feedback de QA para equipas de atendimento ao cliente

Para que serve realmente o feedback de QA

A garantia de qualidade no suporte tem má reputação, e normalmente é merecida. Demasiados programas de QA resumem-se a um gestor a percorrer um punhado de tickets, a marcar caixas numa folha de cálculo e a deixar um veredito de uma palavra numa avaliação. O agente lê "tom: 3/5", sente-se julgado, não muda nada, e todo o exercício transforma-se num ritual do qual ninguém aprende.

O feedback de QA é orientação, não pontuação. O número no scorecard é apenas o ponto de entrada; é no comentário que está o valor. Uma pontuação diz a um agente onde ficou. Um bom comentário diz-lhe o que fazer de forma diferente no próximo ticket, que é a única coisa que realmente melhora o atendimento ao cliente. Se levar apenas uma ideia deste artigo, que seja esta: o objetivo é uma mudança de comportamento específica e repetível, não uma nota.

Trabalhando na fila de suporte todos os dias, já estive dos dois lados disto. O feedback que alguma vez me ajudou não foi "sê mais claro." Foi alguém a citar a frase exata que escrevi, a mostrar-me a versão de duas linhas que teria resolvido o ticket mais depressa, e a explicar porquê. É essa a fasquia que todos os exemplos abaixo tentam atingir.

A anatomia de um scorecard de QA

Antes do feedback vem o scorecard. A maioria dos programas de QA de suporte avalia cada ticket em relação a um punhado de critérios definidos, idealmente alinhados com os seus padrões de atendimento, e o truque está em manter a lista curta o suficiente para que dois revisores avaliem o mesmo ticket da mesma forma. Quando os seus critérios de scorecard são vagos, o seu feedback também é vago, e os agentes percebem.

Eis a estrutura de seis critérios em que a maioria das equipas acaba por assentar. Não precisa dos seis, mas esta é uma base sensata:

Se quiser a construção completa, escrevemos um passo a passo sobre a criação de scorecards e sobre o fluxo de trabalho de garantia de qualidade mais amplo à sua volta. O resto deste artigo assume que já tem algo semelhante a estes seis critérios.

A única fórmula por trás de todos os bons exemplos

Todo o feedback de QA forte, positivo ou construtivo, segue a mesma estrutura de três partes. Os gestores que escrevem bom feedback normalmente fazem isto sem lhe dar um nome: situação, comportamento, impacto (SBI, na sigla em inglês).

• Situação ancora o feedback a um momento real: "No ticket #4821, quando o cliente perguntou sobre a sua encomenda atrasada..." Nunca "em geral" ou "ultimamente."
• Comportamento descreve exatamente o que o agente fez, idealmente citando as suas próprias palavras: "...começaste com 'compreendo perfeitamente como uma encomenda atrasada é frustrante' e depois deste o link de rastreio."
• Impacto liga isso a um resultado: "...e foi por isso que o cliente te agradeceu e fechou o ticket numa só resposta."

A razão pela qual isto importa: um feedback sem situação é infalsificável ("sê mais empático" - quando? onde?), e um feedback sem impacto é apenas uma opinião. O SBI torna cada comentário suficientemente concreto para que o agente consiga imaginar o próximo ticket e repetir o comportamento, ou fazê-lo de forma diferente.

Mantenha esta estrutura em mente enquanto lê os exemplos abaixo. Repare como as versões fracas deixam de fora a situação ou o impacto, e as versões fortes mantêm as três partes.

Exemplos de feedback de QA por critério

Esta é a parte que veio procurar. Abaixo está uma biblioteca filtrável de comentários de exemplo, um cartão por critério de scorecard, cada um com um exemplo positivo (reforçar o que funcionou) e um exemplo construtivo (indicar o que mudar). Reutilize-os, adapte os detalhes aos seus tickets e mantenha a estrutura SBI.

Há algumas coisas a notar em todos eles. Todo o comentário construtivo cita o que o agente realmente fez, e depois entrega-lhe a frase ou regra exata para substituir. Nenhum deles fica pelo "faz melhor." E os comentários positivos são tão específicos quanto as correções, porque um "bom trabalho!" não ensina ninguém a repetir nada. Se quiser mais exemplos escritos em prosa, o nosso artigo de exemplos de feedback de atendimento ao cliente tem um conjunto mais extenso, e os exemplos de avaliação de desempenho cobrem a versão trimestral.

Positivo vs. construtivo: acertar na proporção

Um programa de QA que só assinala problemas ensina os agentes a temer a avaliação. As equipas cujos agentes realmente melhoram tendem a começar pelo que funcionou e a manter um equilíbrio aproximado, algo como três comentários de reforço para cada correção ao longo de um ciclo de avaliação. Isto não é sobre ser condescendente; um comportamento genuinamente bom que nunca é nomeado acaba silenciosamente por deixar de acontecer.

Os exemplos positivos na biblioteca acima fazem um trabalho real. "Reconheceste a frustração específica antes da solução" diz a um agente exatamente que gesto deve manter. Isso é um comportamento repetível e ensinável, que é todo o propósito de o registar por escrito em vez de simplesmente pensar "boa resposta" e seguir em frente. Ligar esses comportamentos aos objetivos de atendimento ao cliente torna óbvia a ligação entre os tickets do dia a dia e o ciclo de avaliação, e o mesmo fio conduz às avaliações de foco no cliente.

Os erros que fazem o feedback de QA sair pela culatra

Mesmo com um bom scorecard, o feedback pode falhar de formas previsíveis. Estes são os erros que mais vejo:

• Avaliar o cliente, não o agente. "Cliente difícil, geriu bem" não é feedback. A QA avalia o comportamento controlável do agente, não a forma como o cliente se apresentou.
• Feedback sem exemplo. "Melhora o teu tom" não dá ao agente nada em que trabalhar. Cita sempre a frase.
• Corrigir sem oferecer alternativa. Dizer a alguém o que fez de errado sem dizer o que fazer em vez disso só o deixa ansioso. Toda a correção precisa da alternativa.
• Morte por mil pormenores. Se um comentário lista oito pequenos problemas, o agente não corrige nenhum. Escolha o um ou dois que mais importam neste ticket.
• Rever uma amostra enviesada. Se só selecionar tickets com uma pontuação de CSAT má, o seu feedback fica enviesado para os desastres e perde os padrões silenciosos e corrigíveis dos tickets normais. É exatamente aqui que a amostragem o prejudica, e onde rever mais tickets muda o panorama.
• Ignorar o momento do escalonamento. Um ticket que foi bem resolvido, mas que ficou parado tempo demais antes de subir, continua a ser um momento de orientação. Avalie quando foi escalado, não só se foi.
• Avaliadores inconsistentes. Se dois revisores pontuarem o mesmo ticket de forma diferente, os agentes deixam de confiar em todo o programa. Critérios de scorecard bem definidos e sessões de calibração são a solução.

O ponto da amostra enviesada é o mais importante, e é onde a forma de fazer QA está a mudar mais depressa.

Escalar o feedback de QA para além de uma amostra de 2%

Eis a verdade incómoda sobre a QA tradicional: um revisor humano só consegue ler um número limitado de tickets, por isso a maioria dos programas analisa uma amostra de cerca de 1-2% do seu volume. Está a orientar toda a sua equipa com base num punhado aleatório de conversas, na esperança de que seja representativo. Normalmente não é.

A IA muda a matemática. Um assistente de IA para QA pode avaliar 100% dos seus tickets em relação ao mesmo scorecard, revelar os padrões que uma amostra de 2% deixaria escapar, e sinalizar os tickets específicos que um gestor deveria realmente ler. Em vez de um revisor passar o dia a procurar tickets que valham a pena para orientação, passa-o a orientar, sobre os que o sistema já revelou. Já escrevemos mais sobre avaliar o desempenho dos agentes com dados de QA e sobre como o feedback de QA voltado para o agente se encaixa no fluxo de trabalho diário.

Este é também o momento de alargar o enquadramento. A QA já não diz respeito apenas aos seus agentes humanos. Se um agente de IA está a responder a tickets ao lado da sua equipa, precisa exatamente do mesmo escrutínio, e, sinceramente, de um mais rigoroso, porque nunca se cansa, mas também nunca fica envergonhado por dar uma resposta errada com confiança. A mesma qualidade de contenção e escalonamento que acompanharia para o bot pertence ao mesmo scorecard.

Aprendi isto da pior maneira. Numa implementação com uma equipa B2B de telemática automóvel a lidar com algumas centenas de tickets por mês no Zendesk, a IA dizia alegremente aos clientes "sim, suportamos o modelo do seu veículo" para modelos que não estavam na base de dados, porque a central de ajuda dizia "suportamos todos os modelos" e o bot levou isso à letra. Nenhum humano teria cometido esse erro duas vezes. A IA precisava de feedback de QA tal como um novo colaborador, e é por isso que agora simulamos cada implementação com os tickets históricos de uma equipa antes de ela responder a alguém ao vivo. Os mesmos sinais de sentimento e qualidade que usaria para avaliar uma pessoa são o que mantém um agente de IA honesto.

Experimente o eesel para QA com 100% de cobertura

Se está a escrever feedback de QA à mão a partir de uma amostra minúscula, o eesel AI fecha duas lacunas de uma só vez. Reporta o desempenho de cada resposta, para que avalie a partir de toda a fila e não de uma dúzia sortuda, e permite fazer QA ao próprio agente de IA: corra-o em simulação com milhares dos seus tickets passados, veja exatamente como teria respondido a cada um, e corrija as lacunas antes de um único cliente ser afetado.

Liga-se ao Zendesk, ao Freshdesk e ao resto da sua pilha de helpdesk em minutos, aprende com a sua central de ajuda existente e com os tickets passados, e é gratuito para experimentar. Pense nele menos como um painel de QA e mais como um colega de equipa que já leu todos os tickets que você nunca teria tempo de ler.