Às vezes – em meio a tantos reels que disparam dopamina infinita no meu cérebro – algumas histórias ou vídeos do Instagram trazem informações interessantes, e uma delas foi conhecer o efeito cobra.
Não sei se você já ouviu falar sobre esse efeito, mas ele vem de uma anedota histórica. Ou seja, não necessariamente ela é toda factual, mas a gente entende que parte dessa anedota tem história e outra parte também é um pouquinho de mito, um pouco de criação.
Segundo a anedota, na época em que o governo britânico tratava a Índia como um território colonial, o governo tinha uma preocupação com cobras venenosas. Então ele criou um programa onde pagava as pessoas que caçassem cobras venenosas e trouxessem até o governo, para que assim diminuísse o número de cobras venenosas naquela região.
No início o projeto foi um sucesso, porque de fato as pessoas começaram a caçar cobras, trazer ao governo e receber o seu dinheiro. Era uma relação de ganha-ganha, porque diminuía o número de cobras, que era um dos objetivos do governo, e as pessoas faziam um dinheirinho.
O ser humano é criativo e, obviamente, aprendeu a “jogar o jogo”. Algumas pessoas mais “empreendedoras” resolveram começar a criar cobras em cativeiro para que assim pudessem receber mais dinheiro do governo.
A quantidade de cobras voltou a aumentar, afinal estavam sendo criadas em cativeiro e as selvagens pararam de ser caçadas, o governo descobriu e cancelou o programa. Afinal, subsidiar a criação de cobras não era o objetivo da lei. Diminuir o número de cobras venenosas, era.
Isso, na minha opinião, se liga diretamente ao suporte técnico e suas métricas, porque quando criamos muitas vezes métricas visando incentivar um tipo de entrega, mas acaba criando outro problema. O ser humano vai sempre procurar uma maneira de se beneficiar daquela métrica e justificar que está trabalhando conforme ela pede, só que, ao mesmo tempo, pode estar criando novos “monstros”.
Quero falar aqui sobre cinco métricas que têm esse efeito cobra e como resolver cada uma delas.
1 – SLA de primeiro atendimento
Algumas ferramentas têm a opção de configurar SLAs distintos, um para primeiro atendimento e outro para resolução.
Ao basearmo-nos apenas em um SLA de primeiro atendimento, como métrica sozinha, pode ser perigoso, pois os analistas podem acabar enviando mensagens automáticas, ou à partir de modelos, marcando o chamado como “atendido” para ficar dentro da métrica quando, na verdade, não existiu um primeiro atendimento de verdade. Apenas uma resposta automática e nenhum retorno real entregue ao usuário.
O SLA fica em cem por cento, mas não existe de fato um atendimento acontecendo.
Uma maneira de resolver isso é diferenciar esse SLA de primeiro atendimento de uma atribuição real. Apenas no momento em que uma pessoa, de fato faz o primeiro estudo sobre o incidente, é que deve ser marcado como um primeiro atendimento.
Exemplo: se uma notificação é enviada dizendo que o chamado vai ser atendido, isso não deve ser considerado um atendimento, e sim uma etapa automática do sistema para confirmação do recebimento, ou a descrição de um processo dado ao usuário.
Apenas a atribuição de um responsável e uma mensagem escrita, de fato por uma pessoa deveria sinalizar o SLA de primeiro atendimento.
Outra opção é simplesmente não usar o SLA de primeiro atendimento para não gerar esse problema.
2 – FCR — First Call Resolution
Quando o FCR, ou resolução no primeiro atendimento, é analisado isoladamente, alguns problemas podem surgir.
Um técnico pode ficar numa sessão remota por horas mesmo sem saber como resolver, mandando mensagens e chamando pessoas para tentar ajudar – o que não é, necessariamente ruim, a não ser que o setor seja desenhado para funcionar dessa forma. Talvez ele resolva o incidente no primeiro atendimento, mas não vai refletir quantas pessoas trabalharam naquele chamado. Ou ainda pior, o time técnico começa a solucionar chamados com ações que não fazem sentido apenas para enriquecer a taxa de atendimentos resolvidos no primeiro contato.
Uma maneira de resolver isso é fazer uma interpretação conjunta entre o FCR e a reabertura de chamados.
Se aquele chamado foi resolvido no primeiro atendimento, mas foi reaberto, ele deveria ser anulado da lista de FCR. Ou então é preciso analisar quantos FCRs foram reabertos e quantos não foram, pois isso traz um número quantitativo de chamados de First Call Resolution e um número qualitativo de quantos destes FCR foram reabertos – isso permite ir até a raiz da qualidade dessas soluções.
Se o técnico resolveu no primeiro atendimento, ele precisa ter certeza de que o usuário lá na outra ponta valida e aprova aquela solução. Só assim temos, de fato, um atendimento resolvido no primeiro contato e com alta qualidade.
3 – Volume de chamados resolvidos
O volume de chamados resolvidos pode encorajar um comportamento destrutivo de times técnicos começarem a resolver apenas os chamados de menor complexidade, fazendo um “cherry picking”, escolhendo aquele chamado mais simples como reset de senha ou reconfigurar uma VPN, e deixando os chamados prioritários com impacto alto de lado para outras pessoas. O volume de soluções fica alto, mas o usuário lá na outra ponta não está feliz com o atendimento de seus chamados mais complexos e de igual ou maior importância para o negócio.
Para resolver isso existem duas opções.
A primeira seria atribuir chamados de forma automática, seja por categoria, descrição, complexidade ou por “round robin”, de forma aleatória, onde quem tiver com menos atendimentos vai receber os chamados.
A segunda seria gamificar o suporte, ou seja, definir uma regra de jogo onde chamados simples como reset de senha geram um ponto no volume total, e chamados que exijam análises mais aprofundadas ou que tenham complexidade maior gerem quinze pontos – são números aleatórios.
A tendência é que o time técnico olhe mais para os chamados complexos para bater a meta de volume baseada em pontuação.
4 – TMA — Tempo Médio de Atendimento
No tempo médio de atendimento, o time técnico sabe que tem uma janela definida, então o time vai tentar, ao máximo, encaixar o atendimento dentro daqueles dez minutos para manter a métrica verde – quantas vezes tua ligação com a operadora de telefonia móvel não caiu sozinha com o atendente te ligando em seguida para continuar o atendimento?
Olhar para o TMA e bonificar ou penalizar o técnico que não cumpre a média de forma isolada pode gerar um efeito negativo no suporte.
O TMA é melhor utilizado como uma ferramenta de “back office”, ou seja, para a liderança entender que tipo de time ou de técnico precisa de que tipo de treinamento, ou até para saber se é um momento de contratação.
Se a média exigida é de quinze minutos, mas todos os técnicos estão precisando de trinta, isso é um sinal.
O time técnico precisa saber que haverá auditorias aleatórias nas suas soluções para ser possível compreender a qualidade dos atendimentos.
O TMA deve servir para descobrir, por exemplo, se um técnico está demorando mais do que deveria para atender chamados de um tipo específico. O que pode indicar necessidade de treinamento ou de novas contratações.
5 – CSAT e pesquisa de satisfação
Quando o envio da pesquisa de satisfação é feito manualmente – operadoras de telefonia enviam só às vezes, por exemplo – ele pode gerar, também, o efeito cobra, porque os técnicos vão deixando de enviar a pesquisa de satisfação para as pessoas que eles sabem que talvez não estejam tão felizes com o atendimento.
A solução que proponho é de ativar o envio das pesquisas de satisfação de forma automática. Todos que abrem chamados, a partir do momento que são fechados, recebem a pesquisa. Ou pode-se usar uma taxa de setenta por cento, ou menos, dos chamados fechados receberem a pesquisa para não encher a caixa de e-mail das pessoas que pedem suporte, mas todos devem receber de forma automatizada.
Outra coisa importante é trazer perguntas um pouco mais abertas, além da nota de satisfação, como, por exemplo:
- o quão difícil foi resolver esse problema conosco?
- A sua requisição foi de fato resolvida? Você vai precisar entrar em contato de novo?
Esse tipo de pergunta traz mais insight sobre o atendimento.
Importante: não penalizar os técnicos unicamente por terem notas baixas. Estude e entenda o porquê daquela nota.
Às vezes pode ser uma intriga entre o usuário e o técnico, ou o usuário está avaliando algo que não reflete o esforço que o técnico teve em tentar trazer uma solução.
Um exemplo claro é quando o usuário não ficou satisfeito porque a TI não trocou uma lâmpada, algo que não é escopo do suporte. Quando se faz esse estudo, entende-se o porquê da nota e, a partir daí é possível até decidir se aquilo pode entrar ou não no catálogo de serviços.
Que outros tipos de métricas você entende que têm esse mesmo efeito cobra? Deixa nos comentários.
Deixe um comentário