Casa de ferreiro, espeto de ferro

Kevin Couto
Tech at Quero
Published in
7 min readJul 17, 2019

Como gerar resultados exponenciais ao investir com afinco na sua ferramenta interna

Guia do aluno e líder de Relacionamento conversando

É comum nas empresas de tecnologia que o investimento nas ferramentas de uso interno sejam irrisórios, ganhando pouca atenção. A consequência pode não parecer óbvia, mas afeta diretamente o caixa da empresa.

Gustavo Reis, Product Manager do squad Relacionamento da Quero, voltou de um evento sobre produto me contando de uma palestra que assistiu sobre a ferramenta interna de uma empresa de tecnologia. O tema era:

“Casa de ferreiro, espeto de ferro”

Essa frase incrustou na minha missão ao lidar com o OPA (Painel do Guia do Aluno), nossa ferramenta interna utilizada pela central de atendimento para facilitar o acesso a dados e operações do Quero Bolsa. Hoje, o OPA é utilizado por cerca de duzentos colaboradores da Quero. Olhando essa quantidade de usuários parece que um alto investimento não faria sentido, certo? Errado.

Apesar de ser utilizado por duzentos colaboradores, eles são responsáveis direta ou indiretamente por vendas que representam cerca de 45% do faturamento da empresa. Estamos falando de milhões de reais em faturamento, ficando claro que nosso espeto precisa ser de ferro.

Recentemente fizemos um trabalho em uma parte da nossa ferramenta que se comunica com o aluno utilizando o WhatsApp. Chamamos essa seção de QueroWhats. Colocamos princípios e técnicas de UX e Design Thinking para entender melhor problemas e encontrar oportunidades de melhoria. A consequência do trabalho foram resultados expressivos.

Como utilizar técnicas de UX e de Design Thinking para entender e resolver problemas em nossa ferramenta

Estava ficando claro para o nosso time que a parte do OPA responsável por interagir com o aluno via WhatsApp estava deficitária. Sempre surgiam alguns problemas recorrentes, como:

  • O aluno tem entrado em contato e não tem recebido resposta (métrica de alunos perdidos)
  • O tempo de espera do aluno estava alto demais (análise do SLA)
  • A qualidade dos atendimentos estava muito baixa (análise do CSAT)
  • Os números para acompanhamento estratégico de atendimento não existiam (ausência de dashboard ou números de acompanhamento)

Priorizamos atacar um cenário que estava diretamente ligado com esses problemas. Recebi do Product Manager a missão de trabalhar na melhoria do fluxo de atendimento do QueroWhats.

Eu podia ter simplesmente aberto o Sketch (programa de criação de interfaces) e criado novas opções de organizar o atendimento do nosso usuário. Mas escolhi dar alguns passos para trás e, junto com o time, fomos buscar entender porque esses problemas estavam acontecendo focando esforços em realizar um processo de Product Discovery mais completo.

Atuamos não apenas como solucionadores, mas também como investigadores. E o grande segredo do sucesso desta tarefa está nesse ponto. Se você já ouviu falar no Double Diamond, significa dizer que fomos iterar em cima do diamante do problema. Fomos ao “Doing the right thing” antes de ir para o “Doing things right”.

Como nossos usuários utilizavam a ferramenta?

O primeiro passo foi adquirir uma visão holística do processo de atendimento do nosso usuário, o guia do aluno (colaborador responsável por fazer o atendimento de suporte ao aluno). Fomos até eles para entender primeiro quais eram seus objetivos e depois como utilizavam a ferramenta para atingí-los.

Descobrimos que o guia tinha alguns objetivos bem claros dentro da empresa:

  1. Atender o máximo de alunos com qualidade (internamente chamado de efetivas)
  2. Alguns desses alunos estavam realmente interessados em comprar. Então, o guia marcava esses alunos como prospectos (internamente chamado de comissionáveis)
  3. E, por último, parte desses alunos garantiam sua bolsa de estudo gerando venda e comissão para o guia

E para realizar esses objetivos, o guia utilizava o OPA para atender e acompanhar os alunos basicamente tomando as seguintes ações:

  • Adicionar tickets na sua caixa (cada ticket representava um aluno);
  • Atender os alunos da sua caixa pelo chat do OPA;
  • Marcar os alunos interessados nas bolsas de estudo como comissionável;
  • Acompanhar a quantidade de alunos atendidos e a conversão dos alunos comissionáveis.

Foi feito um storyboard, desenhado a mão, para deixar claro para todos do time como era o fluxo do guia na ferramenta.

Em seguida, fizemos uma dinâmica com representantes de produto, design, engenharia, além de líderes e analistas do time de Relacionamento para criar uma matriz de certezas, suposições e dúvidas.

Com a matriz, queríamos ter claro:

  1. O que já sabemos a respeito desses problemas identificados?
  2. Quais são as nossas hipóteses?
  3. Quais dúvidas temos?

E o resultado foi animador. Muitos insights que geraram insumos para prosseguir. Grifei em vermelho três suposições que nos chamaram bastante a atenção.

Dando a largada para as descobertas

Nas entrevistas, observações e reuniões que fizemos, descobrimos que os guias colocavam alto grau de importância na quantidade de alunos que atendiam, já que a quantidade de atendimentos influenciava em suas comissões.

Por outro lado, a ferramenta permitia que os guias colocassem até 100 tickets na sua caixa. Era normal que o guia adicionasse 100 tickets (ou perto disso) quando chegava logo pela manhã para garantir que ia atender muitos alunos muitos alunos durante o dia. Como resultado, alguns alunos que solicitaram um atendimento às 9h, algumas vezes, recebiam uma primeira resposta às 16h, por exemplo.

Um outro ponto crítico era uma limitação do próprio WhatsApp Enterprise. Ele permite que enviemos mensagens até 24 horas após a última resposta do aluno. Os guias não tinham um senso de urgência visual evidente para tomar melhores decisões quanto a essa limitação.

Por último, tínhamos muito forte a sensação que de que deveríamos atender primeiro quem estava esperando a menos tempo. Era um lead mais quente, que geralmente já estava online pronto para começar uma conversa.

Show me the numbers

Fomos investigar alguns números do QueroWhats. Descobrimos que as vendas que passavam exclusivamente pelos guias de WhatsApp representavam 15% do total das vendas. Era um número expressivo.

Também descobrimos que o tempo médio do guia dar a primeira resposta para o aluno no WhatsApp era de nove horas. Tempo suficiente para o muitos alunos simplesmente evadirem, procurarem a concorrência ou outro canal de atendimento.

O Product Manager junto com o time de Business Intelligence levantaram dados e confirmaram a tese de que atender quem estava esperando a menos tempo fazia sentido. A conversão de quem era atendido em até 1 hora era duas vezes maior. Para a experiência do aluno que ficaria esperando um pouco mais. Esperar 3 horas ao invés de 2 horas, por exemplo, já não fazia tanta diferença.

Agora tínhamos um objetivo claro

A tarefa estava desenhada: demorávamos muito para atender o aluno e queríamos melhorar isso. Definimos o problema e os objetivos de forma clara para que todos pudessem estar na mesma página:

O QueroWhats foi desenhado para ser uma opção protagonista no atendimento ao aluno, junto com o receptivo.

Observamos que, quando o QueroWhats não consegue atender de forma rápida e ágil os alunos, a taxa de conversão diminui (hipótese), afetando o faturamento da empresa.

Como nós poderíamos melhorar a estratégia de atendimento para aumentar o SLA de atendimentos realizados em até 1 hora de 37,8% para 80% e por consequencia aumentar a conversão?

Preparados para falar de solução

Depois de entender o problema e os principais eventos que o cercavam estávamos seguros do que deveríamos atacar, prontos para desenhar uma solução consistente.

E a solução foi mais simples do que cogitamos inicialmente. Fizemos apenas três alterações:

  1. Alteramos a ordem da fila. Começamos a atender primeiro quem estava esperando a menos tempo.
  2. As mensagens ficavam marcadas até o guia responder. Para dar senso de urgência para o guia, as mensagens que estavam sem resposta ficavam com um círculo amarelo até que o guia respondesse.
  3. O guia poderia ter até no máximo cinco tickets sem resposta na sua caixa. Ou seja, não haveria mais a possibilidade de puxar 100 tickets de uma vez e deixar o aluno esperando tanto tempo.

O resultado do projeto

Depois de desenhar a solução e colocar o projeto no ar, medimos os avanços. Pimba!

Os atendimentos ficaram muito mais ágeis. Os guias conseguiam ter conversas mais atenciosas com os alunos. As conversões aumentaram.

O faturamento exclusivo do QueroWhats dentro das vendas do time de Relacionamento subiu de 15% para 30%. Simplesmente dobrou! E o SLA subiu para 83% dos atendimentos em até 1 hora.

Colher esses bons números é bem prazeroso. Representa o sucesso da atividade, uma melhor experiência pro aluno e mais crescimento para a empresa. Mas os vejo também como consequencia de todo o trabalho de descoberta que realizamos. E aí destaco algumas decisões importantes que tomamos durante o processo:

  • Inserimos o usuário desde o início buscando mitigar riscos e empatizar com as dores deles
  • Fizemos um trabalho multidisciplinar. Product Manager, Engenharia, BI e Designer trabalhando juntos visando agregar valor com as suas competências de negócio, experiência do usuário e engenharia
  • Cocriamos uma solução munidos de uma ampla base de informações que nos permitiram tomar boas decisões

O período de Discovery serve para tornar a iniciativa mais assertiva. Ou seja, ele minimiza o risco de errar. Termino com a citação de Marty Cagan do livro Inspired:

Como se pode ver, um produto não é composto de apenas features, e, por isso o trabalho de um time de produto não é apenas trabalhar na implementação dessas.

Busque incansavelmente gerar valor a todas as partes envolvidas e sua chance de sucesso aumenta exponencialmente.

Kevin Couto @ Product Designer

--

--