O nosso processo de formação do Suporte Técnico

Publicado por Gabi Brunazo e Bruno Ghisi no dia gestão

A RD tem uma cultura bastante voltada ao cliente. No nosso Culture Code, listamos tudo em que acreditamos, praticamos e valorizamos aqui na Resultados Digitais. Um dos nossos principais objetivos (Customer First) é ser reconhecidos pela excelência no atendimento. Fomos adaptando e mudando nossos processos internos focados no que era melhor para o cliente. Porém, devido ao crescimento acelerado da empresa, esse caminho tem sido desafiador e cheio de “altos e baixos”. Esse post pretende mostrar um pouco da evolução da área de suporte técnico durante os primeiros anos da RD.

A visão

Desde o início, buscamos uma forma de estruturar um processo que fizesse com que o time técnico, com desenvolvedores e designers, participassem do processo de atendimento e suporte.

Além da vantagem de conhecerem a fundo o produto e conseguirem resolver/investigar problemas técnicos, conceitualmente acreditamos que é preciso tirá-los da bolha, fazê-los interagir com clientes, entender suas dores, motivações e alegrias. Isso faz com que a equipe se preocupe com nossos usuários e corrijam eventuais problemas que geram.

O início

Em meados de 2013, o suporte era responsabilidade exclusiva da Área de Produto. A ferramenta que utilizávamos para a gestão de tickets era o email (uma conta específica no Gmail) e tínhamos por volta de 100 clientes. A demanda ainda não era alta e fazíamos um roteamento diário entre os desenvolvedores do time de produto - mas ainda não tínhamos ninguém dedicado full time ao suporte.

Nesta fase, não tínhamos um controle de métricas, mas sempre estimulamos o retorno rápido para o cliente e ele normalmente acontecia. Ainda pelo fato do time ser pequeno, todos estavam sempre alinhados.

Neste início, quando o suporte técnico ainda funcionava com roteamento diário, existia uma prática interessante. Todo chamado aberto tinha um dono, ou seja, um responsável “perpétuo” por atender o cliente. Se a solicitação não era resolvida naquele dia, o responsável continuava em contato com o cliente até que a solução final fosse dada.

Isso era bem interessante por duas razões principais:

  1. O cliente não ficava falando com uma pessoa diferente a cada dia;
  2. Não havia a necessidade de repassar a solicitação para uma nova pessoa e, com isso, evitávamos a perda de informações no processo. Consequentemente, o problema era resolvido mais rápido e com maior qualidade.

É claro que isso atrapalhava o planejamento de produto, pois era difícil focar na Sprint enquanto você tinha que resolver os problemas dos clientes, além de que não escalaria.

A necessidade de escalar

No início de 2014, já visualizávamos a necessidade de estruturar o suporte para permitir a escalada de clientes. Nesta época, chegamos a conclusão de que a responsabilidade do suporte deveria ser da Área de Customer Success por terem todas as metas relacionadas a felicidade do cliente. O time de Produto auxiliaria nas demandas técnicas.

Decidimos então que seria necessário investir em uma ferramenta para ir para o next level, ajudando a gerir melhor as solicitações recebidas, assim como nosso desempenho. Fizemos uma breve pesquisa de mercado para encontrar o software que mais se adequava à nossa necessidade. Durante esse estudo, traçamos alguns pontos que considerávamos essenciais:

  • entendíamos que a plataforma deveria ter uma Central de Ajuda (no estilo Wikipedia), que, no médio prazo, permitiria a diminuição de tickets, estimularia o compartilhamento de conhecimento dentro da RD e facilitaria o aprendizado e busca de dúvidas por parte dos clientes;
  • deveria possibilitar a criação de regras de negócio e macros para automatizar nosso processo;
  • deveria permitir que tivéssemos times de áreas distintas atendendo os tickets do Suporte;
  • deveria monitorar um SLA e trazer mais clareza do andamento do suporte (ex: relatórios).

Decidimos então contratar o plano básico da Zendesk, uma ferramenta de helpdesk internacional que atende mais de 45 mil clientes. Além de cumprir os requisitos, a Zendesk possuía um alinhamento cultural com a nossa visão. Inclusive acabamos criando um eBook sobre “O Ciclo do Cliente Satisfeito” em conjunto.

O novo processo

Isto durou até abril de 2014, quando já estávamos com quase 500 clientes e a quantidade de tickets já havia aumentado bastante. Decidimos então mudar e tínhamos duas opções:

  1. Criar um time de suporte dedicado;
  2. Continuar roteando o suporte no time de devs, porém semanalmente, dentro da Sprint (seguindo nosso processo de desenvolvimento ágil Scrum).

As vantagens da primeira opção (foco) são bastante claras:

  • É mais fácil gerir e cobrar metas de um time só;

  • É melhor para realizar mudanças e medir performance de um time;

  • É mais fácil treinar as pessoas pois o processo de aprendizagem é mais rápido. Ela estará lidando com os mesmos desafios e tarefas todos os dias.

A segunda opção - roteando semanalmente - ajudaria a gastar menos com o chaveamento de pessoas. O fato de manter o desenvolvedor no suporte e na produção continuaria a trazer benefícios como:

  • Melhorar a qualidade do software: os bugs seriam resolvidos por aqueles que os criara, além de melhorar a concepção do produto. A consequência direta dessa prática é um esforço maior nos processos de desenvolvimento para aprender a ter menos problemas futuros;
  • O contato com o cliente deixa claro as dificuldades e as necessidades latentes. Dessa forma, fica evidente o que deve ser prioridade no desenvolvimento e retroalimenta o backlog;

Ainda na segunda opção, teríamos algumas desvantagens também:

  • Treinamento mais exaustivo e demorado, além de ser mais difícil sempre formar uma pessoa especialista;
  • Com o time em crescimento, perde-se o alinhamento inicial de quando eram poucas pessoas.

Quando percebemos que uma apenas pessoa no Suporte Técnico (ST) não era mais suficiente, decidimos por utilizar o seguinte modelo:

  • Suporte Nível 1: Suporte não técnico. Realizado pelo time de Customer Success. Fazem a filtragem dos tickets e o primeiro contato com o cliente. Deveriam resolver rapidamente e manter a proximidade.

  • Suporte Nível 2: Suporte técnico. Realizado pelo time de Produto. Faz a primeira análise e resolução dos tickets. Geralmente são pessoas com perfil mais iniciante.

  • Suporte Nível 3: Suporte técnico. Também realizado pelo time de Produto. Resolve somente problemas muito difíceis e complexos quando o Nível 2 precisa de ajuda. Perfil mais avançado.

Esse processo funcionou bem até chegarmos em 1000 clientes no final de 2014. Os tickets estavam mantendo uma média de 500 por mês desde abril mas a complexidade/criticidade vinha aumentando.

As melhorias no processo

Neste meio tempo (entre abril e novembro de 2014), passamos a investir mais em métricas e indicadores. Como todo resto da empresa, o suporte também precisava ser Data Driven (outro valor presente no Culture Code). Precisávamos saber “como estávamos indo” e decidimos investir em análises avançadas. Contratamos uma pessoa para organizar e formar a área de suporte e fizemos um upgrade no nosso plano do Zendesk para ter melhores relatórios e insights.

Definimos o SLA (Service-Level Agreement) interno. Acordamos as seguintes metas:

  • Tempo de primeira resposta: 24 horas corridas;
  • Tempo de resolução: 72 horas corridas;
  • Percentual de Satisfação dos clientes: 90% - 100%.

A primeira mudança nesta nova etapa foi com relação ao treinamento. Percebemos que havia a necessidade de treinar melhor os novos colaboradores antes de incluí-los na escala de suporte (não fazíamos isso muito bem antes). Era preciso tanto treinamento sobre o uso da ferramenta de Suporte quanto treinamento sobre o próprio processo. Além disso, algumas habilidades do time também precisavam ser trabalhadas: a principal delas era comunicação escrita.

Usamos o nosso Wiki no Github para ajudar a documentar as informações importantes e os treinamentos. Junto a isso, fizemos um seminário sobre como atender e responder bem um cliente - que deixamos gravado para futuros treinamentos.

A “cereja do bolo” foi disponibilizar um coach para treinar a pessoa nova no ST. Esse coach era um desenvolvedor que já tinha estado no suporte e que iria ensinar o “caminho das pedras” a quem estava iniciando. Também criamos um mini treinamento para ensinar como esse coach deve treinar seu pupilo. Tudo isso fez com que o tempo de aprendizado de cada novo colaborador no suporte fosse ficando mais curto e menos “doloroso”.

No estágio atual do Suporte Técnico fazemos pair programming com quem entra no suporte pela primeira vez - e isso vem dando bons resultados. Com mais de 1.700 clientes em março de 2015, e com média de 600 tickets/mês, temos alocados no suporte técnico de 2 a 3 desenvolvedores por semana, além de um designer eventual para auxiliar em tickets específicos.

Em alguns momentos, o suporte possui picos de solicitações e as pessoas que estão fixas não conseguem dar vazão a todos os tickets. Para conter esse tipo de cenário, implementamos um processo de suporte backup, ou seja, alguém que fica de prontidão para ajudar no atendimento técnico caso seja necessário. Hoje, o backup está alocado nos times técnicos - e não em pessoas. Dessa forma, o próprio time decide de que forma poderá ajudar o suporte: quantas pessoas serão alocadas no backup e por quanto tempo.

Para resumir, atualmente nosso processo funciona desta maneira:

  • Suporte Nível 1: continua igual: Realizado por um time não-técnico, fazendo a filtragem inicial dos tickets e dando vazão;

  • Suporte Nível 2: Faz a primeira análise do ticket. Resolve as solicitações mais rápidas e passa ao nível 3 os tickets que exigem mais investigação e tempo. Essa pessoa é responsável por dar vazão ao suporte e deixar o caminho da resolução do problema para o próximo nível. Agora, ao escalar para o próximo nível, o desenvolvedor alocado no Nível 2 sempre coloca o motivo e o andamento da investigação para que a passagem não fique tão arbitrária;

  • Suporte Nível 3: Responsável pela investigação de tickets mais demorados. Muitas vezes funciona com pair programming no intuito de resolver mais rápido questões mais complexas;

  • Suporte Backup: Time de desenvolvimento que se responsabiliza por ajudar no suporte técnico quando necessário;

  • O time de Suporte da semana faz Daily Meetings e Sprint Plannings da próxima semana acompanhando KPIs de como foi a semana que passou. Isto ajuda a entender o que está acontecendo e planejar melhorias.

Junto ao novo processo definimos metas ainda mais agressivas:

  • Tempo de primeira resposta: 4 horas úteis;
  • Tempo de resolução: 20 horas úteis;
  • Percentual de Satisfação dos clientes: 90% - 100%.

No momento, estamos cogitando a possibilidade de ter uma pessoa técnica full time no Suporte Técnico para ajudar a estruturar a área para a próxima fase, acompanhando números diretos, treinamento, problemas técnicos, etc. Como se fosse um Scrum Master do time técnico do Suporte.

Um dos principais aprendizados com essa grande quantidade de mudanças que já fizemos foi a importância de se ter claro qual é o papel e a responsabilidade de cada nível - e de cada pessoa. É imprescindível deixar exposto o que se espera de cada um em relação a números e resultados. Treinamento e feedback constante são extremamente relevantes para a motivação da equipe e ajudam a identificar melhorias internas.

Que venha a próxima fase!

Gabi Brunazo

Gabi Brunazo

Customer Support Coordinator

Bruno Ghisi

Bruno Ghisi

CTO

Comentários