O papel do designer na redução de chamados: a importância da análise de dados

Neste artigo, vou compartilhar como fizemos análise e categorização de chamados, mapa de jornada de atendimento por meio da técnica shadowing e como aplicamos as descobertas na criação de uma nova funcionalidade da Conta Azul.

Desafio

Como é de praxe no trabalho do designer na Conta Azul, nós frequentemente analisamos a quantidade e categoria de chamados abertos pelos nossos clientes.

No último semestre, realizamos uma série de atividades para entender as necessidades dos usuários e, como resultado, criamos novas funcionalidades para a Conta Azul. E é sobre este processo que vou falar agora.

Análise e categorização dos chamados

Para começar a análise dos chamados, decidimos investigar se havia algum ponto em comum entre eles.

Também queríamos saber se os top ofensores (chamados mais frequentes) estavam conectados a alguma destas hipóteses: problemas de usabilidade em novas funcionalidades, pedidos de atualização de funcionalidades antigas, ou algum outro desafio que precisávamos mapear.

Precisávamos enquadrar o problema. O enquadramento do problema é a primeira fase do Double Diamond, ou Duplo Diamante, que é a metodologia que usamos no time de Design.

#ParaTodosVerem: a imagem é uma ilustração com fundo e elementos azuis. No centro dela, há dois quadrados virados, lembrando dois losangos, um encostado do lado do outro, que vamos chamar de diamantes. Esta ilustração representa o Duplo Diamante mencionado no artigo. Há uma bolinha azul escura sobre a ponta mais à esquerda do diamante à esquerda, mostrando o ponto de partida, e dela sai uma seta reta em direção ao ponto mais alto deste diamante. Em cima, está escrito: “Divergir para descobrir o problema”.

Para realizar a nossa análise, estabelecemos uma “data de corte” de dados de três meses e usamos filtros na ferramenta em que acompanhamos os chamados.

As categorias que tínhamos para filtrar eram as áreas da Conta Azul, e as subcategorias eram temas específicos por chamado. Considerando que estas são informações internas, vamos trabalhar com categorias fictícias.

Vamos imaginar que os usuários quisessem cadastrar novos produtos e não estivessem encontrando isso na Conta Azul. Neste cenário, esses usuários abririam chamados pedindo aos atendentes para fazer isso por eles. Chamamos este tipo de chamado de “Dúvidas”.

A categoria dos chamados poderia ser “vendas e compras” e a subcategoria seria “cadastrar novo produto”.

Para visualizar melhor esses dados, exportamos todas as informações do filtro “vendas e compras” em uma planilha e montamos em forma de gráfico, separando os dados pelas subcategorias.

Adaptações nas categorias

Após ler os chamados um a um, fizemos adaptações das subcategorias e renomeamos de acordo com a dificuldade do usuário no produto.

Por exemplo, se um usuário abriu um chamado para tirar uma dúvida sobre “cadastrar novo produto” e também aproveitou para pedir ao atendente um favor que ele não conseguia fazer sozinho na Conta Azul, categorizamos este chamado como “falta de autonomia”.

Essas adaptações nos permitiram compreender do ponto de vista de produto quais eram os jobs to be done dos usuários.

Mas, só depois da categorização final e da priorização das demandas mais impactantes sobre o número de chamados, é que conseguiríamos definir o problema para atuarmos com objetividade.

#ParaTodosVerem: a imagem é uma continuação da imagem anterior. Agora, a bolinha que estava sobre a ponta mais à esquerda do diamante à esquerda, está desta vez em cima do ponto mais alto do diamante. Da bolinha, sai uma seta reta, em direção ao ponto mais à direita do diamante, que o une com o segundo diamante. Em cima, está escrito: “Convergir para definir o problema”.

Categorização final das demandas ofensoras (chamados mais frequentes)

Após essa lista, selecionamos as duas principais demandas ofensoras para nos aprofundar. Para poder trazer mais detalhes do processo a este artigo, criamos demandas fictícias:

Problema 1 (fictício)

Tipo de chamado
Dúvida

Demanda ofensora
Como cadastrar novo produto

Job to be done (JTBD)
O usuário da Conta Azul que já tivesse importado uma planilha com produtos durante o onboarding, agora teria comprado novos produtos e não saberia como cadastrá-los separadamente no ERP.

Problema 2 (fictício)

Tipo de chamado
Falta de autonomia

Demanda ofensora
Como adicionar variações ao produto

Job to be done (JTBD)
O usuário da Conta Azul teria comprado um mesmo produto com variações diferentes, mas não conseguiria adicionar essas variações sozinho, porque o ERP não teria essa funcionalidade.

Priorização da demanda para o time de produto

Das demandas selecionadas, a primeira já existia no ERP mas os usuários não estavam encontrando.

A segunda dependia totalmente do time de atendimento (também chamado de time de suporte) para ser solucionada. Por isso, fazia sentido eliminá-la o quanto antes.

Podemos usar o método RICE para confirmar nossa priorização. Funciona assim:

1. Você escreve o alcance que este problema tem (em números absolutos de usuários)
2. Qual o impacto do problema (de 0,25 a 3)
3. A confiança do time nesta solução para reduzir chamados (em porcentagem)
4. E o esforço do time para criar a solução (você decide a medida, nós usamos entre 1 e 4).
5. Depois, multiplicamos Alcance x Impacto x Confiança e dividimos tudo pelo Esforço.

Consideramos o alcance o número de usuários que abriram chamados sobre cada problema nos últimos três meses.

O impacto, quanto tempo o time de atendimento leva para resolver cada um dos chamados.

A confiança representa quanto achamos que a solução vai reduzir chamados.

E o esforço é quanto tempo necessário, contando o tempo total de times, levaria para construir uma solução.

Veja exemplos:

Problema 1 (dúvida)

• Reach (alcance): 100
• Impact (impacto): 1
• Confidence (confiança): 70%
• Effort (esforço): 2
• 3,5

Problema 2 (falta de autonomia)

• Reach (alcance): 200
• Impact (impacto): 3*
• Confidence (confiança): 70%
• Effort (esforço): 4
• Valor final: 10,5

Por que consideramos impacto máximo na segunda demanda?

Sem o recurso no produto, os clientes precisavam entrar em contato com o atendimento. Isso significa que o modelo de realização da tarefa era high touch (contato humano), o que traz muita personalização para o atendimento, mas baixa escalabilidade para a solução do problema.

O valor final do método RICE foi maior para o problema 2, por isso nós resolvemos seguir por ele.

Como nos aprofundamos na demanda

Nosso trabalho principal era entender como poderíamos dar essa autonomia para os usuários realizarem as ações na plataforma.

Se conseguíssemos reproduzir a tarefa executada pelo time de atendimento em um fluxo no produto, considerando as dificuldades do cliente, o modelo poderia se tornar mais sustentável.

Para isso, decidimos começar mapeando esta jornada do time de suporte: desde o início do chamado até a solução.

Isso tinha que ser feito nos mínimos detalhes, entendendo quais dados eram necessários, como e por onde os dados passavam até que o problema do cliente fosse resolvido.

Foi aí que decidimos usar a técnica de shadowing, em que o designer se torna a sombra do usuário.

Essa técnica nos permite ter informações mais detalhadas e confiáveis do passo a passo que o usuário está fazendo para resolver algum problema, ou fazer alguma tarefa.

No nosso caso, a única diferença é que íamos acompanhar o time de suporte, e não nossos clientes usuários.

Para aplicar esse método foi simples: como trabalhamos de maneira remota, combinamos de ficar em uma sala de bate-papo com o time de atendimento enquanto eles resolviam esses chamados.

Como funcionou na prática?

Primeiro, o time de atendimento fazia uma triagem para identificar este tipo de chamado (problema 2) e enviá-lo ao setor que o resolvia.

O que fizemos foi combinar com este setor que queríamos ser chamados sempre que eles fossem solicitados.

Assim, cada vez que recebiam solicitação para resolver o problema 2, eles nos enviavam um link para videoconferência. Quando entrávamos, eles compartilhavam a tela e faziam o processo de solução junto com a gente.

Assistimos ao time interagindo com a ferramenta interna da Conta Azul para resolver o problema. Anotamos todo o passo a passo e, no fim, criamos um modelo para reproduzir este mesmo fluxo dentro do ERP. Isso permitiria que nossos clientes conseguissem fazer a tarefa sozinhos.

Idear soluções

Com nosso mapa da jornada em mãos, ficou mais fácil de propor um fluxo que atendia todas as necessidades dos usuários e pôr a “mão na massa”, ou melhor, no Figma. No double diamond, nós entramos no segundo diamante:

#ParaTodosVerem: a imagem é uma continuação da imagem anterior. Agora, a bolinha que estava sobre o ponto mais alto do diamante, agora está em cima do ponto que une os dois diamantes. Dela, sai uma seta apontando pra cima, em direção ao ponto mais alto do segundo diamante. Em cima, está escrito: “Divergir para desenvolver/prototipar”.

Nessa fase do projeto desenhamos wireframes para validarmos protótipos de média fidelidade com os stakeholders (partes interessadas).

Estes wireframes seguiam a mesma lógica de como o atendimento resolvia o problema do cliente, a diferença é que trouxemos todos os fluxos e soluções para dentro do nosso produto.

O objetivo de validar com as partes interessadas era irmos fazendo ajustes até chegarmos na solução ideal, que iria para teste.

Testar

#ParaTodosVerem: a imagem é uma continuação da imagem anterior. Agora, a bolinha que estava sobre a ponta que une os dois diamantes, está desta vez em cima do ponto mais alto do segundo diamante. Da bolinha, sai uma seta reta, em direção ao ponto mais à direita deste diamante. Em cima, está escrito: “Convergir para testar/entregar”. E esta é a fase final do Duplo Diamante.

Após validarmos o fluxo tecnicamente, era hora de testar com nossos usuários. Para isso, tornamos nosso protótipo navegável e utilizamos uma ferramenta de teste de usabilidade.

Para o teste, descrevemos nosso objetivo, nossas perguntas e hipóteses. Também definimos o que seria sucesso e o que seria considerado ponto de atenção.

Nós separamos a entrega do teste em duas fases: a primeira teria como público os nossos colaboradores, e a segunda, usuários da Conta Azul.

Por que fizemos testes com colaboradores?

Começar testando com o time nos permite manter a confidencialidade, recrutar mais rápido, ser mais econômico e obter os primeiros insights com muito mais agilidade. Assim, o protótipo pode ser refinado antes de testarmos entre clientes externos.

Escolhemos fazer os testes de forma remota (assim como toda a nossa discovery) e não moderada. O teste envolve a interação dos usuários com um protótipo navegável e clicável, e a ferramenta de teste grava todas as interações, erros e acertos.

O teste não moderado, ou seja, sem a supervisão do pesquisador, nos permitiu receber os resultados de forma assíncrona e analisar tudo muito mais rápido.

Dividimos o teste em 5 etapas:

1. Texto breve de apresentação do teste ao usuário
2. Tarefa para o usuário concluir dentro do protótipo
3. Uma pergunta em formato SUS (System Usability Scale), em que o usuário deveria responder:
   “Em uma escala de 1 a 5, quão fácil foi realizar a tarefa?”
4. Uma pergunta aberta:
   “Comparando o cenário apresentado com seu dia a dia, ele atende a sua necessidade?”
5. E, por fim, deixamos espaço para comentários

Nós consideramos que os testes tiveram sucesso quando a maioria dos usuários conseguiram completar a tarefa.

Este teste com colaboradores nos trouxe feedbacks abrangentes sobre a estrutura e os textos do fluxo. Com isso, nós fizemos os ajustes necessários e repetimos o mesmo formato e roteiro do teste para usuários da Conta Azul.

Por que fizemos testes com usuários da Conta Azul, mesmo após os testes internos?

O usuário final traz insights sobre a usabilidade que podemos ter deixado passar. Além disso, ao falar com uma pessoa de fora da companhia, evitamos reproduzir vícios dos times (como regras conhecidas por todos os colaboradores, jargões e possíveis enviesamentos dos setores da Conta Azul)

Análise

Nós cruzamos os resultados da parte 1 do teste (com colaboradores) e da parte 2 (com usuários da Conta Azul) para entender em quais partes do fluxo os grupos divergem.

Quando se trata do conteúdo que compõe a informação do produto, precisamos levar em consideração os riscos apontados pelos colaboradores em seus feedbacks.

Mas, quando se trata da usabilidade, analisamos com cuidado as escolhas dos usuários da Conta Azul. Se for o caso, mudamos o produto para facilitar o uso para os clientes, e adicionamos estas atualizações aos treinamentos dos colaboradores.

Entrega

Com este faseamento e a evolução constante dos fluxos desenhados, ficou muito mais seguro e rápido liberar o protótipo em produção para todos os usuários da Conta Azul.

E, desde que a nova funcionalidade foi liberada, continuamos coletando feedbacks constantemente.

Aprendizados e resultado

Aprendemos que existem vários meios de descobrir as dores dos clientes. Por entrevista ou por pesquisa de uso das funcionalidades, por exemplo, dificilmente encontraríamos o problema aqui discutido.

Apesar de ser um trabalho minucioso, a análise de chamados deve ser feita com frequência pelos designers para encontrarem gaps de usabilidade no produto.

Para os usuários, era rotineiro abrir um chamado para resolver esses problemas, e nosso papel enquanto product designers é dar autonomia a eles.

Como resultado, a criação desta funcionalidade reduziu significativamente os chamados sobre o tema.

Os números indicam que o usuário está resolvendo seu problema com autonomia, sem precisar entrar em contato com o suporte.

A funcionalidade também reduziu a carga de trabalho do time de suporte — que passa a atuar de forma mais consultiva, em atendimentos que realmente precisam de contato humano.

E você, o que achou das técnicas utilizadas nesta discovery? Escreva nos comentários. Até uma próxima 😃