Como reduzimos 50% dos tickets de suporte da Automação do RD Station Marketing - Sergio Schuler | Resultados Digitais
•Transferir como PPTX, PDF•
0 gostou•230 visualizações
O documento descreve como a empresa RD Station Marketing reduziu em 50% os tickets de suporte através da automação, com o objetivo de aumentar o NPS em 20%. A descoberta dos problemas específicos dos clientes foi feita através de entrevistas, pesquisas e protótipos, e as soluções implementadas resultaram em uma redução de 47% nos tickets e economia de R$132 mil.
Recomendados
Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (20)
Semelhante a Como reduzimos 50% dos tickets de suporte da Automação do RD Station Marketing - Sergio Schuler | Resultados Digitais
Semelhante a Como reduzimos 50% dos tickets de suporte da Automação do RD Station Marketing - Sergio Schuler | Resultados Digitais (20)
Mais de Product Camp Brasil
Mais de Product Camp Brasil (20)
Como reduzimos 50% dos tickets de suporte da Automação do RD Station Marketing - Sergio Schuler | Resultados Digitais
- 1. COMO REDUZIMOS 50% DOS TICKETS DE SUPORTE DA AUTOMAÇÃO DO RD STATION MARKETING @SergioSchuler
- 2. Senior Product Manager /SergioSchuler @SergioSchuler s@sergioschuler.com sergioschuler.com SÉRGIO SCHÜLER Feijão Com Arroz
- 3. COMO REDUZIMOS 50% DOS TICKETS DE SUPORTE DA AUTOMAÇÃO DO RD STATION MARKETING @SergioSchuler
- 4. POR QUÊ?
- 5. Aumentar NPS em 20%
- 6. Em uma escala de 0 a 10, o quanto você recomendaria o RD Station Marketing para um amigo ou colega?
- 7. NPS 50 NPS 60
- 8. 2 “Não falo sobre trabalho com meus amigos” 8 “automação poderia melhorar bastante” 3 “Ótimo! Nada a reclamar!” 9 “acompanhar a automação” Em uma escala de 0 a 10, o quanto você recomendaria o RD Station para um amigo?
- 9. # de tickets no suporte por feature
- 10. QUAIS SÃO AS ALAVANCAS?
- 14. CONTEXTO B2B (12K CLIENTES)
- 21. ● Entrevistas com usuário ● Pesquisas ● Protótipo em papel ● Protótipo navegável ● Gravação de interação na tela ● Etc DISCOVERY DE CADA PROBLEMA
- 29. Encontrar alavancas Descobrir e implementar soluções Medir impacto (e voltar ao passo 1) Feijão Com Arroz
Notas do Editor
- Tempo: 25+10 ou 30+5
- Sou o Sérgio, como NÃO sou PM na SpaceX, o que eu vou apresentar não é rocket science. É resultado de um discovery usando a framework FCA… ...Feijão Com Arroz. Agora falando sério. Eu sou o Sergião, trabalho na RD (Resultados Digitais) em um produto chamado RD Station Marketing O que eu vou falar foi sobre como...
- O objetivo da minha tribo era aumentar o NPS em cerca de 20%
- Pra quem não conhece, NPS é aquela métrica em que eu dou uma nota de 0 a 10. Vejo a porcentagem das notas 9 e 10 e reduzo pela porcentagem das notas 0 a 6. O resultado é o número NPS. O NPS é um número muito bacana, mas tem um problema. Ele nem sempre é muito acionável
- É um pouco como aquele meme do south park com os gnomos ladrões de cuecas. A fase 1 era roubar cuecas. A fase 2 eles não sabiam. A fase 3 era lucrar E aí, beleza, o NPS tem um campo aberto. Então dá pra olhar lá. Mas mesmo assim, dependendo da complexidade do produto, ele também não é muito acionável...
- Como a pergunta dizia se recomendaria para um amigo… Ótimo! nota 3 A automação poderia melhorar, com certeza. Mas como? “Acompanhar automação” é algo positivo? É um problema? O que significa? Então no caso de automação, decidimos usar um proxy...
- Então no caso de automação, decidimos usar um proxy...de número de tickets no suporte Essa linha azul grossa é a automação, as outras são outras partes do produto Claramente tinha algo errado com o aumento de tickets de automação Feature com mais tickets no suporte. Aqui entram dúvidas sobre como usar, sobre como fazer algo específico, pedidos de feature, bugs, etc Em um ano isso custava cerca de 250 mil só de suporte, sem contar o churn causado por problemas ao usar a feature
- Primeiro a gente foi tentar entender quais eram os principais problemas...
- Primeiro a gente foi tentar entender quais eram os principais problemas… ...porque não fazia sentido atacar esse problema abaixo, por exemplo, porque é muito menor que o problema de cima. Fazer isso já se provou um desafio...
- Fazer isso já se provou um desafio… porque as categorizações do suporte eram muito abertas Dava pra ter uma ideia, mas era preciso entender melhor Não rolava deixar mais granular, por 2 motivos: inviabilizaria a operação de suporte (muito tempo pra categorizar) e porque assim eles já erravam muitas categorizações, imagina com coisas mais granulares Talvez machine learning pudesse nos ajudar nessa categorização, mas nunca investimos nisso
- Eu poderia conversar com clientes, mas esse approach me pareceu limitado. Com certeza eu descobriria problemas na automação, mas seria difícil de quantitativamente estabelecer quais eram os maiores. Como os tickets são conversas completas, decidi que iria analisar ticket a ticket
- … claro que isso foi possível porque o RDSM é B2B e tem 12k clientes. Quando tem muito mais tickets, tipo milhões de clientes de uma típica B2C, aí tem que ser por amostragem mesmo.
- Importer em uma planilha uma amostra de tickets, tipo de uns 3 meses Comecei a ler ticket a ticket e categorizá-los A medida que eu ia lendo, ia adicionando, removendo e juntando algumas categorias até ter algo consistente. Com isso já ia percebendo os padrões Fiz assim com checkmarks porque...
- Fiz assim com checkmarks porque muitas vezes os tickets tem mais de uma categoria (porque o cliente pergunta de muitas coisas)
- Fazendo uma soma simples dessas categorias, vimos quais eram os principais ofensores em número de chamados no suporte Então, beleza, é só atacar o maior e pronto, certo? Não necessariamente. Além de avaliar o tamanho do problema, também conversei com o time pra entender o tamanho do esforço para a solução
- Conversando com o time, fomos plotando os resultados em uma matriz de esforço vs tickets Para facilitar a conversa com o time sobre estimativas (que estão sempre erradas) discutíamos primeiro ideias de solução e depois um chute se a coisa levava dias, semanas, meses, trimestres, semestres, anos… e também sempre comparávamos uma coisa com outra. Y leva mais ou menos que X?
- Uma vez escolhido o problema que vamos atacar, eu acho útil conversar com o time sobre o quanto estamos dispostos a usar de recursos de desenvolvimento para entregar a feature - ou seja, o nosso apetite para abocanhar a feature. Esse conceito surgiu num livro do pessoal do Basecamp, chamado Basecamp, e me ajudou muito a conversar com o time sobre que tipo de investimento era necessário. Sem fazer isso, eu acabava muitas vezes me frustrando como PM. Minha primeira aposta para reduzir tickets foi escolhida porque gerava muitas dúvidas no suporte e também era simples (era literalmente um warning que faltava) Só que para o volume de tickets que tinhámos daquilo, pra mim não fazia sentido levar mais de 1 semana naquilo. Acabamos levando 3, porque eu não conversei com o time sobre qual era o “apetite”. Se tivesse conversado, teríamos encontrado ou soluções alternativas ou partiríamos para outra solução mais promissora.
- Definido no que vamos trabalhar e mais ou menos o apetite. Entrava nosso processo de discovery normal
- E aí eu nem quero entrar muito em detalhes, mas pegávamos uma categoria que queríamos explorar e fazíamos um discover “normal”. Entrevistas com usuário, etc Mas aí alguém pode perguntar, ué, já não tava nos tickets o que o cliente queria?
- ...é que se considerar só o que o cliente fala, a gente cai naquele lance do Henry Ford: se eu perguntasse o que as pessoas queriam, elas teriam dito ‘cavalos mais rápidos’.
- Um exemplo disso foi um grupo de entrevistas baseadas em JTBD sobre um problema bem específico de distribuição de leads entre vendedores. Estávamos considerando um approach mais complexo que iria dar mais opções para o usuário na hora de distribuir os leads para seus vendedores.\ Isso provavelmente resolveria o problema dos tickets, mas também aumentaria a complexidade para desenvolver e para novos usuários entenderem Fizemos 5 entrevistas de 25 minutos cada e vimos que o que o cliente precisava era bem específico e que essa configuração extra era meio outlier. Então fizemos o básico, foi super rápido e olha o resultado
- ...Então fizemos o básico, foi super rápido e olha o resultado Zeramos os tickets daquela categoria
- No slide anterior, deu pra ver que a gente continuava rastreando o número de tickets, e isso foi essencial Diariamente eu categorizava os tickets do dia anterior, de modo que eu avaliava se o que estávamos fazendo estava surtindo efeito e quanto de efeito
- Aí montei um dashboard com a evolução das diferentes categorias (as pintadas são as que eu estava trabalhando ou tinha recém trabalhado aí queria acompanhar com mais atenção)
- Mas aí eu comecei a notar que do nada algumas coisas subiam ou desciam sem o time tocar… E aí olhando mais a fundo percebi que o problema era a quantidade de dias úteis no período Quando eu dividi o número de tickets por dias, aí o número ficou muito mais estável Mais uma vez, isso tem a ver com o contexto B2B do produto. Falando em sazonalidade, eu também não somava no número total os tickets de incidente, porque era algo pontual e iria poluir a métrica
- Esse processo relativamente trouxe alguns resultados bacanas
- No fim, realmente é o feijão com arroz, não é rocket science