Certa vez, o departamento de suporte comercial do Social Discovery Group enfrentou o grande desafio de limpar um acúmulo de 1.500 tíquetes acumulados ao longo de quatro anos.  Gerenciar um volume tão alto de problemas era uma tarefa séria, e constantemente nos deparamos com dificuldades para acompanhar os KPIs.  Apesar de nossos melhores esforços, os tíquetes continuavam sendo embaralhados de um sprint para outro, deixando os clientes frustrados e nos sentindo sobrecarregados.  Neste artigo, gostaríamos de compartilhar nossa experiência ao enfrentar essa tarefa aparentemente impossível, lembrando-nos do lendário sexto trabalho de Hércules.  Vamos levá-lo através dos desafios que a equipe SDGroup enfrentou e as etapas que tomamos para reconstruir os processos de nosso departamento.  Adotamos a abordagem STATIK, que provou ser incrivelmente eficaz para nos ajudar a limpar o atraso e trazer o alívio tão necessário para nossa equipe.  Então, se você está procurando informações práticas sobre como lidar com um acúmulo de tíquetes, continue lendo!  Como acabamos com a fila de 1.500 ingressos  Como departamento de Suporte ao Negócio, somos responsáveis pelo tratamento de tickets que contenham reclamações e sugestões de clientes sobre nossos serviços.  Por exemplo, se um cliente tiver dificuldades com o sistema de pagamento em nosso site, ele pode apresentar um problema à equipe de suporte técnico da SDG.  Os colegas reúnem todas as informações relevantes, incluindo etapas de reprodução de problemas e capturas de tela, e criam um ticket no Jira, atribuindo-o ao nosso departamento.  Em seguida, executamos testes adicionais para garantir que o problema não seja uma falha temporária do cliente, mas um problema real da nossa parte. Se confirmado, criamos um relatório de bug, priorizamos e encaminhamos para a equipe de desenvolvimento para resolução.  Em média, recebíamos de 20 a 30 ingressos diariamente. Gastamos de 2 a 3 horas reproduzindo o problema, mas sempre que precisávamos de assistência de outros departamentos, como detalhes do caso, reinicializações de serviço, dados do banco de dados ou análises da equipe de desenvolvimento, nossas tarefas tendiam a travar.  Nossos colegas muitas vezes não conseguiam responder prontamente e não havia uma equipe separada de desenvolvedores designada para nossos relatórios de bugs. Além disso, nossos tickets de desenvolvimento tinham prioridade mais baixa em comparação com as tarefas de negócios.  Como resultado, mesmo os tickets de alta prioridade podem permanecer sem solução por alguns meses, enquanto as tarefas de menor prioridade permanecem no quadro por anos.   Como vocês podem ver, esse fluxo gerou muita incerteza no cumprimento de prazos, o que gerou insatisfação tanto para nós quanto para nossos clientes. A situação resultou em vários problemas:  Os clientes ficavam estressados e frustrados quando seus problemas não eram resolvidos com rapidez suficiente e não podíamos fornecer um cronograma claro.  Nossa equipe de suporte ficou frustrada, pois os clientes exigiam atualizações para problemas não resolvidos quase todos os dias.  A equipe de suporte nos escreveu e recebeu a mesma resposta: "O problema ainda não foi resolvido."  Nossa equipe estava sobrecarregada e incapaz de pegar tarefas antigas e vinculá-las como casos recorrentes.  Sentimos desespero ao olhar para o número assustador de 1.500 tarefas não resolvidas em nosso quadro. Sabíamos que precisávamos mudar nossa abordagem para fazer algum progresso.  Este é o ciclo de vida do ticket durante esse período.   Vamos dar uma olhada em alguns dos problemas que encontramos ao gerenciar o backlog de pendências:  A equipe de suporte carecia de scripts para documentar e filtrar prontamente os problemas.  Tarefas no status "Novo" muitas vezes ficavam paradas no limbo. Quando não tínhamos informações ou acesso suficientes para resolver o problema, ele passava para o status "Escalado" e buscávamos ajuda de colegas de outros departamentos. Infelizmente, pode levar semanas ou até meses para que eles respondam. E, às vezes, perdíamos comentários devido ao grande volume de tarefas recebidas.  Depois que verificamos o problema, mudamos para o status "Aguardando correção". Devido a uma escassez crônica de recursos de desenvolvimento, esses tickets podem permanecer sem solução por anos. Os clientes não fecharam os chamados, esperando que recebêssemos mais recursos no futuro.  O backlog substancial de tarefas resultou em duplicatas. Foi difícil mesclá-los e fechá-los, pois muitas vezes nos esforçávamos para lembrar quais tarefas haviam sido iniciadas em anos anteriores.  Essa abordagem mal organizada resultou em um acúmulo de   . 1.500 tickets não resolvidos em quatro anos  A Abordagem STATIK e o Sexto Trabalho de Hércules  Percebemos que nosso departamento estava muito focado no processamento de tíquetes, em vez de abordar o objetivo principal de resolver os problemas do cliente: melhorar sua fidelidade em relação aos produtos do Social Discovery Group e detectar vulnerabilidades em nossos serviços e sites.  Você pode se perguntar: "Por que não contratar mais funcionários se você não consegue lidar com a carga de trabalho?" No entanto, a experiência mostra que, ao estabelecer processos eficientes, podemos ir sem recursos extras.  Da mesma forma, Hércules completou seu trabalho sozinho, redirecionando o fluxo do rio para os estábulos de Auge, que os limparam em apenas um dia.  Para simplificar nosso quadro de tickets, consultamos o livro de Mike Burrows   e implementamos a abordagem STATIK, uma estratégia sistemática para executar o método Kanban. "Kanban from the Inside"  Ao implementar a abordagem STATIK, seguimos estas   : cinco etapas    e concluímos que os clientes precisam estar satisfeitos com o suporte fornecido. Para conseguir isso, precisamos garantir o seguinte: 1. Identificamos as expectativas dos clientes do nosso departamento de Suporte Comercial  A transparência em nosso trabalho na tarefa permite que os clientes entendam o que está acontecendo com suas solicitações a qualquer momento.  Agilidade de nosso trabalho nas tarefas, proporcionando um tempo definitivo para feedback em qualquer estado da questão.    A fonte interna é o que nos atrapalhou e causou frustração em nosso próprio trabalho. 2. Definimos as fontes internas e externas de insatisfação.  A fonte externa é o que causou frustração para nossos clientes e prejudicou sua experiência.     Examinamos os tickets enviados ao nosso departamento e os categorizamos de acordo com os departamentos de onde vieram, sua frequência e as expectativas dos clientes em relação aos tempos de resposta e soluções.  3. Analisamos as fontes e a natureza de nossa carga de trabalho.    Nesta fase, avaliamos a eficiência com que estávamos lidando com os tíquetes e determinamos quantas tarefas poderíamos gerenciar de forma realista em uma semana. 4. Avaliamos nossas capacidades atuais.  Além disso, calculamos o tempo médio que leva desde o início do ticket até a liberação da correção do bug na produção.   5. Reconstruímos o ciclo de vida do ticket e criamos um novo processo.     Nosso ciclo de vida inicial do ticket     Usando os insights obtidos, desenvolvemos um novo ciclo de vida da tarefa.   Em seguida, implementamos uma abordagem abrangente para resolver todos os problemas mencionados anteriormente. Demos os seguintes passos:  Criamos scripts para nossa equipe de suporte filtrar tarefas no nível inicial.  Introduzimos um status temporário "Voltar ao Reporter" para tarefas que exigiam informações do cliente para investigar o problema. Se as informações necessárias não fossem fornecidas em três dias, a tarefa seria encerrada automaticamente.  Removemos o status "Escalado" e o substituímos por um status mais específico de "Confirmação de problema".  Passamos mais de dois meses revisando e fechando tarefas duplicadas, deixando-nos com apenas 800 tíquetes únicos dos 1.500 com os quais começamos.  Implementamos Acordos de Nível de Serviço (SLAs) e definimos timers para cada status. O status "Confirmação do problema" tinha um cronômetro de 7 dias, enquanto o status "Desenvolvimento" tinha um cronômetro de 30 dias.  Ter tarefas no status "Confirmação de problema" nos motivou a enviar um ping para nossos colegas em busca de uma resposta. Mudamos nossa abordagem de comunicação, usando mensagens privadas ou tópicos do Slack em vez de comentar no Jira. Isso reduziu o tempo de resposta para um dia em comparação com as semanas anteriores.  Embora não tenhamos colocado um cronômetro no status "Aguardando correção", alocamos mais tempo para a comunicação e discussão com o cliente. Caso uma tarefa fosse considerada inviável, informamos o cliente e priorizamos as tarefas mais importantes. Isso levou a uma redução de 50% nas tarefas em espera. Além disso, passamos a organizar reuniões em que os clientes pudessem explicar a importância de uma tarefa, ajudando-nos a priorizar melhor nossa carga de trabalho.  Para o status "Desenvolvimento", definimos um cronômetro de 30 dias e limitamos o número de tarefas nesse status a quatro. Isso nos ajudou a focar na correção do bug dentro do prazo definido e evitar ser sobrecarregado com ruído visual desnecessário de 20 a 40 tarefas no status "Desenvolvimento" no quadro.  Para garantir que nossas práticas sejam sustentáveis, adotamos o princípio do percentil 90, o que significa que 90% das tarefas devem ser concluídas no prazo, conforme determinado pelos cronômetros de cada status. Monitoramos isso usando o gráfico de controle do Jira e o plug-in Jira-helper para criar o 90º percentil.  Finalmente, introduzimos motivação adicional para a equipe, prometendo um bônus se o princípio do percentil 90 fosse seguido, assim como Augeas prometeu a Hércules um décimo de seus cavalos como bônus.   Ao implementar essa nova abordagem e reconstruir os processos de nosso departamento, finalmente conseguimos resolver um problema que nos atormentava há quatro longos anos.  A solução não exigia tempo, esforço ou orçamento extra, mas reduzimos significativamente o número de tarefas acumuladas. Em apenas cinco meses, com uma equipe de apenas dois funcionários inteligentes, conseguimos reduzir a fila de 1.500 ingressos para apenas 150.  Essa experiência nos ensinou a importância de identificar a causa raiz de um problema para resolvê-lo com eficácia.  Também destacou a importância de ter processos bem projetados, pois processos ruins inevitavelmente levarão ao acúmulo de problemas, como descobrimos em primeira mão.   Escrito por Dimitri Andrews, engenheiro de teste de software do Social Discovery Group 


Walkthroughs, tutorials, guides, and tips. This story will teach you how to do something new or how to do something better.

See how we create Social Life 3.0 👉

Social Discovery Group Earns the Great Place To Work® Certification in the USA!

Swipe Away Loneliness: 2024 Dating Trends Forecast

Este áudio é produzido no idioma original da história!

Muito longo; Para ler

Boost your HackerNoon story @ $159.99! 🚀

Lidando com os estábulos áugianos do suporte ao cliente: nossa história de sucesso

About Author

COMENTARIOS

Rótulos

ESTE ARTIGO FOI APRESENTADO EM

Related Stories

Liberando o poder da IA. Uma revisão sistemática de técnicas de ponta: resumo e introdução

Toque para ganhar: Telegram pode integrar os próximos 10 bilhões de usuários criptográficos antes de Solana

Valhalla de Floki se junta como patrocinador associado da viagem da Índia ao Sri Lanka

Vazamento do prompt do sistema Claude Sonnet 3.5: uma análise forense

Liberando o poder da IA. Uma revisão sistemática de técnicas de ponta: resumo e introdução

Toque para ganhar: Telegram pode integrar os próximos 10 bilhões de usuários criptográficos antes de Solana

Valhalla de Floki se junta como patrocinador associado da viagem da Índia ao Sri Lanka

Vazamento do prompt do sistema Claude Sonnet 3.5: uma análise forense

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps