Como a Resultados Digitais analisa dados do Suporte para melhorar o RD Station - Parte 1

Publicado por Luigi Cenatti Gianni no dia gestão

O Suporte - ou Atendimento ao Cliente - é uma mina de ouro de informações sobre o seu Produto. Mesmo assim, muitas empresas ignoram os dados que são gerados diariamente por meio dos tickets de clientes.

Aqui na Resultados Digitais, há pouco tempo passamos a analisar estes dados para retroalimentar a gestão do desenvolvimento do RD Station. Este post apresentará algumas análises que temos feito e desafios que encontramos ao longo do caminho.

Por que analisar os tickets de Suporte?

Os tickets de suporte são uma fonte preciosa de informações: eles revelam quais são as “dores” e obstáculos que nossos clientes enfrentam ao utilizar o RD Station. Métricas como engajamento nos dão uma visão de quais são as features mais utilizadas; e indicadores como leads gerados tentam decifrar se nossos clientes estão obtendo sucesso ou não com a nossa ferramenta; contudo, somente o Suporte é uma verdadeira e constante fonte de feedback sobre o que não está funcionando tão bem.

No caso da RD, algumas sugestões de melhoria do produto eventualmente chegam por meio de consultores (que estão em contato direto com os clientes). Mas o Suporte é o principal meio aonde os clientes recorrem para expor suas dificuldades com o RD Station.

Para uma empresa cujo um dos valores principais é ser Customer First, não poderíamos ignorar o Suporte como um dos principais inputs para a Gestão do Produto.

Como classificamos os tickets de Suporte

Hoje, qualquer ticket aberto por um cliente é classificado internamente (por meio da nossa plataforma de help desk Zendesk) dentro de duas dimensões:

1 - Com relação ao “tipo” do ticket

Se a ação que o cliente está tentando executar existe e não está funcionando, o ticket está relacionado a um Bug. Por outro lado, se a funcionalidade existe e funciona - porém o cliente não consegue realizá-la sozinho -, temos um problema de UX (User Experience).

Também é possível que o obstáculo encontrado pelo usuário esteja relacionado muito mais a dúvidas conceituais de Marketing Digital do que a problemas do software em si: neste caso, o ticket é classificado como “tipo” Educação.

E assim por diante! Hoje, agrupamos os tickets em pelo menos sete categorias diferentes dentro dessa dimensão.

2 - Com relação à “funcionalidade” que gerou o ticket

Neste ponto, é uma questão de dividir o produto (no nosso caso, o RD Station) em diversas funcionalidades. Por exemplo, problemas de Email Marketing ou Landing Pages são classificados em suas respectivas áreas.

Com base nestas duas dimensões, realizamos ao final de todo mês uma análise dos dados gerados pelo Suporte.

Como analisamos os tickets de Suporte

Antes de entrar no mérito das análises que realizamos, vale citar alguns disclaimers

  • Forget help desk metrics: Normalmente, quando se fala em análise de dados do Suporte - e realiza-se uma pesquisa no Google sobre o assunto - a preocupação é em estudar métricas como, por exemplo, tempo médio de primeira resposta, tempo médio de resolução de tickets, entre outros indicadores. Apesar de importantes, são números que não interessam diretamente à Gestão de Produto. As análises que detalhamos neste post são fundamentalmente diferentes.

  • Product > Software: Quando falamos em “Produto”, estamos tratando de toda a experiência que o nosso cliente tem com o RD Station - desde a usabilidade do software até o contato com um consultor da área de Customer Success. Consequentemente, se (por exemplo) estão sendo abertos muitos tickets do “tipo” Educação sobre a funcionalidade de Email Marketing, isso deve ser sim uma preocupação da área de Gestão do Produto!

  • Continuous improvement: Ainda estamos aprendendo sobre quais análises realmente agregam valor. Analisar dados simplesmente por analisar (i.e., gerar gráficos bonitos sem utilidade) vai completamente contra nossa cultura Lean e nosso entendimento do que é uma Gestão de Produto bem feita.

  • Garbage In, Garbage Out: Classificar tickets na prática é muito mais difícil do que parece (e, por incrível que pareça, valeria um post por si só). Ainda estamos aprendendo na marra sobre a melhor forma de classificá-los e, acima de tudo, como manter um padrão à medida que hoje mais de cem pessoas dentro da RD têm o poder de classificar um ticket. Tão importante quanto a análise que você faz é garantir que os inputs dela estão corretos.

  • There is no ‘One size fits all’: Como qualquer conversa sobre Gestão de Produto alerta, as análises que funcionam para nós hoje podem não fazer sentido para a sua empresa - ou para a própria RD daqui a um ano. Nosso approach tem sido continuamente iterar sobre MVPs dessa análise, retirando os dados que não agregam valor e mantendo os demais para a próxima iteração. Obviamente, alguém já cunhou o termo minimum viable analysis, mas a moral da história é: comece com análises simples e itere sobre elas.

Hoje, nós realizamos três análises diferentes sobre os dados de Suporte:

1) Tendência por “tipo” e “funcionalidade”

A primeira análise que realizamos é sobre dados agregados ao longo do tempo. Por exemplo, qual a média de tickets do “tipo” Educação abertos por cliente ao longo das últimas semanas? Essa curva apresenta tendência crescente, decrescente ou constante?

Tendência do número de tickets ao longo das semanas

Este tipo de análise é importante quando a média de tickets abertos de determinado “tipo” (por exemplo, Educação) é alta e estão sendo realizadas ações para reduzí-la. Normalmente, quando existe uma tendência decrescente (ou crescente) nessa curva, nós realizamos o drill-down dela por funcionalidade - ou seja, repetimos o mesmo gráfico porém focando em apenas uma funcionalidade. Com isso, tentamos descobrir em quais funcionalidades melhoramos (ou pioramos) a educação dos nossos clientes.

Por outro lado, quando notamos que a curva está constante há semanas, é um sinal de alerta de que não estamos agindo ou que as medidas tomadas não surtiram efeito.

A mesma análise é repetida para todas as funcionalidades. Quando alguma funcionalidade apresenta tendência crescente de tickets, por exemplo, também realizamos um drill-down da curva para descobrir os problemas com essa funcionalidade (Bugs? UX? Educação?) e priorizar medidas para o próximo mês.

2) Uso da funcionalidade vs. Problemas com a funcionalidade

Métricas de engajamento contam apenas metade da história. É “fácil” descobrir quais as funcionalidades mais utilizadas do seu produto, porém em quais funcionalidades o usuário encontra mais dificuldades? Existem funcionalidades pouco utilizadas que geram muitos tickets? E qual o “tipo” desses tickets?

Para realizar esta análise, nós utilizamos um gráfico similar ao esquema abaixo:

Uso da funcionalidade vs. média semanal de tickets

O dado de uso de cada funcionalidade é obtido por meio do Evergage, ferramenta que utilizamos para monitorar o engajamento dos clientes com o nosso produto. Tecnicamente, o “uso” é medido pela porcentagem de contas que realizaram determinada ação dentro da funcionalidade em um período semanal. Esta informação, combinada com os dados que vêm do Zendesk, resultam no gráfico acima.

Hoje, prestamos atenção principalmente em dois quadrantes. O quadrante II é um exemplo de features em estado “normal”, ou seja, com utilização alta - consequentemente, com um número alto de tickets por semana. Funcionalidades neste quadrante tem maior peso na hora de priorizar melhorias, quick wins e bugs.

Já o quarto quadrante deveria estar sempre vazio: indica funcionalidades “problemáticas” que, apesar do baixo uso, geram muitos tickets. Temos hoje uma funcionalidade importante neste quadrante e já priorizamos ações de produto (e.g. enhancements) e educação (e.g. artigos na Central de Ajuda) para “empurrar” essa feature para a esquerda e para cima.

3) Lançamento de novas funcionalidades

O lançamento de uma nova funcionalidade - ou uma melhoria de funcionalidade existente - vai muito além de colocar essa feature no ar. Junto com o rollout, deve existir um esforço sincronizado de educação da base e de comunicação da novidade.

Junto com o engajamento dos clientes com essa nova funcionalidade, um dos Critérios de Sucesso que levamos em conta para determinar se um lançamento foi bem-sucedido ou não é o impacto que ele teve sobre o suporte.

O gráfico a seguir exemplifica a evolução ao longo do tempo do número de tickets - dividido pelo número de clientes - de uma funcionalidade impactada por um lançamento. Resumidamente, o gráfico abaixo representa um bom lançamento:

Lançamento bom: impacto positivo sobre o número de tickets

E o gráfico abaixo demonstra o que acontece quando um lançamento não é tão bem executado:

Lançamento ruim: impacto negativo sobre o número de tickets

O principal objetivo dessa análise é melhorar nosso processo atual. Se realmente houve um impacto negativo no Suporte, o mínimo que temos que fazer é entender o porquê e realizar modificações no nosso processo para que isso não aconteça de novo.

Por que você deveria analisar seus tickets de Suporte?

O Suporte diz muito mais sobre o seu Produto e as dificuldades dos seus clientes do que você imagina. Se você ainda não analisa os tickets abertos pelos seus clientes, comece hoje! Crie análises simples e itere sobre elas. Por mais triviais que essas análises sejam (e elas realmente são), já tiramos diversos insights importantes que permitirão levar o nosso produto ao next level.

Mas, não vamos parar por aqui. Queremos ir um pouco além das análises que realizamos hoje. Queremos alcançar um nível que possibilite tirarmos insights estratégicos para o desenvolvimento do RD Station. Para isso, estamos experimentando com novas análises dos tickets de Suporte; este será o assunto tratado na segunda parte deste post.

Até lá!

Luigi Cenatti Gianni

Luigi Cenatti Gianni

Product Manager

Comentários