Lifehacks da Haier: eles lançaram um processamento em alta velocidade de tickets do zero

Inicialmente, na Rússia, os eletrodomésticos Haier eram vendidos por meio de distribuidores. Desde 2017, a empresa lançou vendas online e lojas de marca.

Antes da pandemia de 2020, as vendas cresciam suavemente e o suporte era terceirizado e consistia em duas partes: suporte à loja online - pedidos, entrega; serviço pós-venda - solicitações de reparos, manutenção. Cada unidade teve curadores diferentes.

Mas, com o início da quarentena em 2020, as vendas na loja online cresceram significativamente, e atrás delas o call center começou a se desenvolver. Desde meados de 2020, começamos a transferir o suporte para a competência interna e a construir um call center dentro da empresa. Imediatamente criamos um sistema de suporte unificado adulto, contando com os padrões internacionais COPC da melhor experiência da indústria nos últimos anos.

Minha experiência com o Usedesk como o principal sistema de helpdesk começou na Haier. Antes disso, trabalhei com o concorrente deles, mas descobri que o Usedesk é uma alternativa agradável para uma solução estrangeira. Existem duas razões pelas quais escolhemos o Usedesk: é mais fácil de configurar e é mais barato. Seu concorrente tem uma lógica bastante complexa para definir as regras, e no Usedesk ela é implementada de uma forma mais ativa e moderna. Foi bom ver que eles deram um grande passo à frente nos últimos anos e adicionaram muitos recursos úteis.

Em minha experiência de 10 anos de trabalho em serviço de suporte, montei vários sistemas de helpdesk - formei requisitos de negócios e processos de negócios. Portanto, após ingressar na equipe da Haier e começar a reconstruir o call center interno, configurei conscientemente o sistema de helpdesk para reduzir o tempo de processamento de solicitações ao máximo.

Meu conselho, se você está apenas implementando um helpdesk, é começar com um canal:

• Configure um funil para chamadas recebidas.
  
• Conecte um sistema de resposta automática.
  
• Estabeleça padrões para os funcionários.
  
• Ative lembretes para eles.
  
• Configure análises e controle de qualidade.

E quando tudo estiver pronto, é mais fácil conectar os canais restantes de acordo com o mesmo princípio - não importa quantos sejam, cinco ou quinze.

O conceito é marcar os tickets recebidos sempre que possível por assunto e prioridade no nível do sistema. Em seguida, com base nessas regras, os tickets são colocados nas filas de filtro necessárias, com diferentes grupos de habilidades dos funcionários. Se, após a filtragem automática, um ticket foi parar no lugar errado, o agente o identifica manualmente, atribuindo o assunto desejado do ticket, e o ticket é incluído no filtro necessário. Suponha que tudo esteja configurado corretamente no sistema devido à distribuição correta de tickets pelos canais e ao trabalho competente com prioridades. Nesse caso, existem vários níveis de SLA dependendo da complexidade e da importância do ticket - o tempo de processamento das tarefas é bastante reduzido.

Temos vários grupos de habilidades em cada uma das duas direções parcialmente intercambiáveis. Ou seja, dentro da direção, os funcionários são especialistas universais, e agora somos todos agentes, pois com exceção dos iniciantes, os incluímos em todos os grupos de habilidades. Com nossas especificações, isso é mais conveniente - permite distribuir a carga de trabalho entre os funcionários da forma mais eficiente possível e responder rapidamente a um grande fluxo de tickets sobre algum tópico. Graças às estatísticas que o Usedesk coleta, vemos a situação com os tickets de entrada (onde os funcionários têm ou não têm tempo), e o SLA começa a "afundar" com base na rapidez com que a fila é montada e quanto tempo é gasto no processamento. Dependendo disso, reforçamos este ou aquele canal com os agentes.

Existem duas opções para o agente processar tickets:

• O agente se reveza no processamento de tickets da lista, que é formada por todas as filas de seus grupos de habilidades em ordem de prioridade por SLA.
• O agente vê os filtros por assunto e escolhe quais processar primeiro. Por exemplo, vemos que agora temos muitos tickets inseridos no filtro "entrega", então aumentamos operacionalmente a prioridade de seu processamento e adiamos os tickets restantes, em tópicos menos ativos, por várias horas.

Também estamos experimentando as configurações de filtros, tags e regras automáticas no Usedesk para escolher o esquema ideal, levando em consideração as peculiaridades do negócio e o perfil de distribuição do fluxo de entrada por tempo: dias, semanas, meses. Afinal, quanto menores os volumes, mais fácil de manobrar, menos eles precisam de processos de streaming e mais você pode usar uma abordagem individual para diferentes situações de cliente. Quanto maior a carga, mais importante é o agente trabalhar com os tickets e tópicos oferecidos pelo sistema sem pensar na escolha. Com uma carga alta, a distribuição dos agentes por grupos de habilidades e níveis torna-se mais relevante: a primeira, a segunda e a terceira linhas de suporte.

Por exemplo, digamos que você queira que vários agentes lidem constante e consistentemente apenas com entregas. Você cria um grupo de habilidades de entrega, adiciona os agentes necessários a ele e configura tags e filtros para que os participantes possam ver apenas uma lista de tickets de entrega. Como resultado, eles apenas respondem a perguntas sobre remessa e não assumem outras tarefas. Essa abordagem ajuda os agentes do grupo de habilidades a trabalharem com mais rapidez, pois economiza tempo e esforço intelectual por não terem que alternar entre questões diferentes.

Ao mesmo tempo, do ponto de vista de um conjunto de conhecimentos, os agentes podem ser universais e, de turno a turno, podem ser transferidos de um grupo de habilidades para outro. Por exemplo, hoje um agente está em um grupo de habilidades para entrega, amanhã para chamadas de garantia e assim por diante em um círculo. Isso permite uma distribuição muito flexível da carga de trabalho entre os funcionários, dependendo das mudanças no fluxo de chamadas recebidas e as torna intercambiáveis.

Imediatamente montamos um funil para o fluxo de mensagens de entrada e, no final, fizemos um trabalho muito bom: eles conseguiram processar tickets no dia-a-dia e cumprir bem o SLA. Conseguimos realizar o sonho antigo de todos os serviços de suporte - o cliente recebe a primeira resposta em uma hora. Dúvidas que requerem várias interações são resolvidas em média em um dia, e quase nunca mais que três dias - em situações em que são necessárias informações adicionais do cliente ou a participação de algum outro serviço.

Para evitar que os agentes monitorem o status dos tickets manualmente e "copiem e colem", configuramos três níveis de respostas automáticas para tickets recebidos: uma mensagem padrão sobre a aceitação de um aplicativo, um lembrete e um fechamento.

Dependendo do assunto dos tickets, entendemos quanto tempo leva em média para processá-los. Com base nisso, definimos o padrão. Por exemplo, se levar uma hora para responder a um tópico específico, o agente pode processar sete tickets desse tipo em um dia útil de oito horas. Se o processamento do pedido levar um minuto, o padrão, respectivamente, é diferente.

O mais interessante é como usar o sistema para configurar a distribuição de casos simples e complexos entre os agentes.

Existem duas opções:

• Para funcionários em geral - um padrão para todos; o sistema oferece ao agente tarefas de diferentes complexidades de forma equilibrada.
  
• Para funcionários com especialização restrita, existem padrões diferentes; alguns consideram apenas casos simples, e alguns apenas complexos.

Por exemplo, no momento não temos uma distribuição clara dos agentes por especialização - eles são universais em termos de conjunto de conhecimentos. Portanto, nesta fase, definimos padrões de desempenho com base no tempo médio de processamento do ticket. No futuro, quando os volumes crescerem, acho que mudaremos para um esquema diferente para distribuir a carga e avaliar a eficácia dos funcionários.

Agora examinamos mais o número de interações do ticket - destacamos as tarefas que exigem mais interações. Isso é necessário para entender por que existem tantas interações e encontrar uma maneira de reduzir seu número. Se isso não for possível, tentamos automatizar algumas interações e acelerar ainda mais o processamento de tickets.

Por exemplo, tivemos uma situação em que um agente muitas vezes precisava lembrar a um colega de um departamento vizinho que estávamos esperando que ele respondesse uma tarefa. Vendo isso, configuramos o ping automático proativo baseado em SLA do ajustador. Agora, se um agente que trabalha com um ticket recebe informações adicionais de um subcontratado, ele usa o status "Em espera". Esse ticket pendente vai para um filtro separado, no qual uma regra é configurada: quando o prazo se aproxima, o subcontratado recebe um lembrete para resolver o problema.

Dependendo do tópico, o processo de negócios para lidar com tickets é um pouco diferente. Descrevemos todos os processos de negócios, portanto sabemos o tempo que leva em média para cada estágio e como otimizá-lo interativamente e gerenciar a distribuição dos intervalos entre os lembretes.

Suponha que queremos resolver um problema complexo do cliente em três dias. Nesse caso, organizamos os processos internamente para que todas as interações se enquadrem nesses três dias, incluindo a comunicação interna com os departamentos relacionados e a eventual necessidade de obter informações adicionais do cliente. Por exemplo, se precisarmos fazer três mensagens de lembretes no tópico X, alocamos no máximo 12 horas para cada uma. Ou seja, cada tópico possui regras que especificam o momento das respostas automáticas.

Vimos análises diárias, semanais e mensais, dependendo das tarefas de otimização dos processos que nós propusemos. Usamos estatísticas do Usedesk para controle operacional e trabalho analítico - são dois blocos separados. A tarefa do controle operacional é identificar e corrigir, em tempo hábil, problemas no trabalho dos operadores; a tarefa do trabalho analítico é detectar problemas sistêmicos no trabalho de suporte, se houver. O mais interessante é encontrar pontos de crescimento e áreas de melhoria.

Controle Operacional. Supervisores e líderes de equipe do departamento de QA fazem uma verificação de alto nível diariamente se os funcionários atendem ao SLA e olham o tempo entre as interações. Por exemplo, digamos que um agente tenha obtido o primeiro ticket às 10h e o segundo às 11h. O intervalo entre o status "concluído" do primeiro ticket e o status "em andamento" do segundo é de meia hora. Isso levanta a questão do que a pessoa fez durante meia hora.

No âmbito das verificações semanais e mensais, o Controle de Qualidade analisa detalhadamente o trabalho de suporte. Utilizamos uma das regras básicas do Usedesk, segundo a qual, após preencher um ticket, o cliente recebe uma mensagem automática com um ticket para compartilhar seu feedback sobre a qualidade e rapidez na resolução de seu problema. Os líderes de equipe revisam essas classificações diariamente e verificam individualmente os tickets com classificação ruim. Você pode ver todos os tickets com avaliações negativas e ver uma divisão por agente para ver qual agente tem as avaliações mais negativas.
O mesmo vale para os tópicos - você pode ver a divisão para entender quais deles são difíceis e causam avaliações negativas. Às vezes, esses pedidos são reabertos e os agentes os estão finalizando. Às vezes são baseados na opinião subjetiva do cliente, mas também ajuda muito a trabalhar o tom da comunicação e dos processos de negócios em geral.

Trabalho analítico. Os relatórios regulares mostram com muita clareza todas as quedas iminentes nos principais parâmetros de desempenho em tempo real, especialmente se você os personalizou para atender às suas necessidades e eles começam a "falar" com você. Isso permite que você aumente a potência prontamente ou faça outras alterações que ajudem os funcionários a se adaptarem de maneira flexível à mudança de carga do fluxo de tráfego de entrada.

No momento, conectamos apenas o e-mail e processos de depuração em todos os canais de e-mail. Seguindo o mesmo esquema, estamos nos preparando para conectar o chat no site e, em seguida, o chat no aplicativo.