Um guia rápido para organizar o gerenciamento dos chamados de suporte em centrais de atendimento a clientes
Ah escalonamentos, o equivalente a um pequeno ataque cardíaco na área de suporte ao usuário de TI . No entanto, assim como em doenças coronárias, há uma variedade de caminhos curtos e, na maioria das vezes fáceis, que podem ser tomados para evitar ou mesmo eliminar parcialmente o risco e, por sua vez, evitar clientes insatisfeitos, multas e até quem sabe cancelamentos.
A Base de Conhecimento Interna ou os artigos da FAQ (frequently asked questions ou perguntas mais frequentes) devem ser a primeira linha de defesa contra escalonamentos, na maioria das vezes os profissionais podem ser colocados em uma posição que os force a confiar diretamente na transferência de conhecimento sênior, também conhecido como “como faço isso?”.
Esta é uma ótima opção para equipes grandes, especialmente se o treinamento do usuário é escasso e onde um novo funcionário é encarregado de resolver ou despachar um grande número de tarefas, pense nas operações de Call Center ou no NOC (Network Operations Center).
As operações de autoatendimento podem ser beneficiadas imensamente dessa pequena dica. Clientes que lidam com um detalhado catálogo de serviços, projetado para cobrir serviços contratados diretamente de um portal pelo usuário ou cliente, sem recorrer ao contato com um agente, apreciarão ter um guia rápido caso surjam dúvidas.
Um FAQ bem construído também pode ser fornecido diretamente aos seus clientes, o que nos leva ao nosso próximo tópico:
Como lidar com incidentes antes mesmo deles serem abertos? Os bancos de dados de erros conhecidos permitem a automação de cenários de gerenciamento de incidentes, permitindo aos clientes o acesso antecipado a informações que poderiam potencialmente resolver o problema de destino sendo relatado, às vezes, até mesmo antes de ser aberto.
O OTRS, por exemplo, permite que as palavras-chave da FAQ sejam definidas para sugerir ativamente artigos publicados anteriormente no módulo de perguntas mais frequentes quando um novo ticket é aberto. No entanto, potencialmente, gostaria de afirmar que um cenário de retorno ainda deve ser disponibilizado caso o cliente não consiga resolver o problema.
Este passo soa mais fácil do que realmente é, notificar efetivamente os agentes de que uma tarefa deve ser tratada, requer planejamento e ferramentas que devem estar prontas para a tarefa.
Por exemplo, se os agentes estão sendo notificados exclusivamente por uma plataforma designada, eles estarão sendo notificados o suficiente?
Em vez de notificar os agentes somente quando um ticket ou solicitação é criado, por que não notificar agentes quando uma determinada porcentagem do contador de SLA é atendida? A configuração adequada de notificações por SMS e / ou por E-mail pode diminuir consideravelmente a chance de encaminhamento, garantindo que os profissionais sejam corretamente notificados no devido tempo.
Lembre-se de não sobrecarregar agentes com notificações, ou o contrário pode ocorrer. A ideia é reforçar as áreas e / ou serviços mais comumente afetados.
Quando tudo mais falhar, os SLAs ativos também podem ser revisitados. Eu não estou necessariamente argumentando no sentido de renegociar os contratos existentes, essa tarefa por si só seria mais do que suficiente para escrever páginas e páginas.
No entanto, com isso dito, leve em consideração que os SLAs não devem ser vistos como documentos estáticos e, na verdade, devem ter estruturas claramente definidas que permitam revisões durante o período de vigência do contrato.
Os SLAs devem ser sistematicamente revistos quando, por exemplo, o aumento da demanda pelos clientes resultar em maior demanda de infraestrutura e, portanto, em esforço técnico.
Por último, como bônus, fique atento aos principais indicadores de desempenho. O aumento de escalonamentos pode ser um sinal claro do aumento de demanda e crescimento, talvez seja hora de contratar.
*Matheus Assis Baeta é diretor da OTRS Brasil
