• Lygia Canelas

UX Writing aplicado ao Suporte Técnico de uma Instituição de Ensino Superior


Quero compartilhar com vocês hoje parte de um projeto sobre como o UX Writing e a Gestão de Conhecimento foram responsáveis por tornar mais eficiente a experiência das pessoas usuárias em um serviço de suporte técnico.



Sobre este case


A Faculdade Horácia Resende é um nome fictício criado especialmente para exemplificar este case real que aconteceu em 2016. O nome da faculdade e os outros termos utilizados neste case foram alterados para preservar os dados originais. Criei até um logotipo novo pra ficar mais bacaninha de ler o case ; )


Na época, assinei um de Termo de Confidenciabilidade. Isso quer dizer que todos os conteúdos e informações do projeto pertencem exclusivamente à empresa, e que ela licencia o acesso apenas para consulta e uso de seus clientes, durante a vigência do Contrato.


Foram proibidas as alterações, reproduções, cópias etc.



Background


A Faculdade Horácia Rezende é uma instituição de Ensino Superior que sempre ofereceu cursos de graduação e pós-graduação na modalidade presencial.


Em determinado momento, a faculdade resolveu disponibilizar o conteúdo didático dos cursos por meio de uma plataforma digital e um aplicativo, a EduH.


Depois dessa mudança, o setor de suporte técnico passou a receber um volume muito alto de chamados. No Google Play e na Apple Store a avaliação do app era ruim e o produto recebia muitas mensagens negativas.


Toda semana a gestão solicitava relatórios do setor do suporte técnico, porém os relatórios referentes aos chamados eram inconsistentes: uma boa parte dos atendimentos era categorizado como "outros" e ficava impossível saber quais os problemas e questões dos usuários dessa categoria.



gif


Pois é! As demais categorias não eram suficientes, cada agente da equipe de suporte empregava um termo diferente para falar da mesma funcionalidade ou bug, não tinha padrão nas respostas e a gestão não conseguia obter dados consolidados o suficiente para tomar decisões.


Nessa época fui alocada para atuar nessas questões e ir em busca dos seguintes objetivos:

  • Oferecer transparência dos dados contidos nos relatórios de atendimento;

  • Compreender os problemas reais da plataforma (o que gerou o aumento no volume de chamados?);

  • Facilitar a gestão dos dados coletados;

  • Otimizar o processo de atendimento;

  • Aumentar o nível de satisfação da experiência com o serviço de suporte;

  • Criar e reforçar uma imagem positiva sobre a marca.

Então, a primeira coisa era ouvir as pessoas. Iniciei um processo de mapeamento dos chamados por email e telefone.


Também levantei quais eram as categorias utilizadas para classificar os atendimentos e comecei a tentar recategorizar cada uma delas observando a terminologia utilizada pelos agentes do suporte e pessoas usuárias.


Foi uma primeira organizada geral no rolê, entendeu?


Logo de cara deu para perceber que os relatórios confusos eram apenas a ponta do iceberg…


Levei o resultado do mapeamento para o meu gestor na época, e identificamos diversos pontos de atenção.


Resolvemos ir a fundo e avaliar todos os dados e informações que tínhamos em mão. Vou te mostrar como foi esse processo.



1. Coleta e mapeamento


A coleta e o mapeamento dos dados envolveu a leitura de inúmeros chamados e o acompanhamento das ligações telefônicas.


O gestor do suporte, da infra, o líder técnico do desenvolvimento, a equipe de UX e de marketing e eu fizemos diversas reuniões para avaliar os relatórios, os dados mapeados e ouvirmos as dores das pessoas envolvidas. Ou seja, as que atendiam os usuários, as que resolviam os problemas e bugs, e as pessoas usuárias do produto: estudantes, docentes, pessoas coordenadoras da faculdade, sistemas internos (softwares).


Durante essa pesquisa, descobrimos que a linguagem utilizada no atendimento era cheia de jargões técnicos, o que dificultava o entendimento das pessoas que usavam os produtos. Cada agente do suporte interagia e explicava o mesmo problema com um vocabulário particular.


Textos com erros de português, uso de pouca ou muita formalidade, etc.


Acabamos desconfiando também que uma boa parte das pessoas usuárias não estavam nada felizes em ter que acessar o material didático apenas em formato digital. No entanto, sem dados consolidados não era possível tomar nenhuma decisão.





No total, identificamos os seguintes problemas:

  • relatórios confusos;

  • aumento na demanda do suporte técnico;

  • falta de padronização na terminologia e roteiros de atendimento;

  • impossibilidade de tomar decisões por falta de dados;

  • pessoas usuárias insatisfeitas com a plataforma e o serviço do suporte;

  • categorias insuficientes para classificar os atendimentos;

  • incoerência nas orientações oferecidas pelos agentes para as mesmas categorias de problemas.


Recuperei alguns exemplos do mapeamento realizado. À esquerda estão os textos originais escritos pelas pessoas agentes e à direita estão sugestões iniciais de script, ou de roteiro padronizado. No centro uma puxada de orelha simpática para alertar sobre a necessidade de mudança.




2. Seleção


Os termos em rosa — que aparecem nas imagens anteriores — eram mapeados para um vocabulário controlado que traduz os termos da linguagem natural para as palavras adotadas a partir de um novo padrão na comunicação dos atendimentos.


O vocabulário controlado também padroniza os nomes e a descrição das funcionalidades do produto, dos erros, das soluções oferecidas, etc.


Nesse momento do projeto, definimos os objetivos específicos:

  • Desenvolver vocabulário controlado;

  • Adequar rótulos e descrições na plataforma de chamados (Request Tracker);

  • Otimizar o fluxo de atendimento;

  • Estruturar roteiros de atendimento para todos os contextos;

  • Criar uma Base de Conhecimento sobre os produtos;

  • Criar uma lista de FAQ (Frequently Questioned Answers) para diminuir a quantidade de dúvidas;

  • Desenvolver conteúdo de ajuda ou manuais para pessoas usuárias;

  • Oferecer treinamento para a equipe do suporte;

  • Retroalimentar roadmap de produto para evolução constante da plataforma.


Nosso escopo de atuação passou a ser:


a) Focamos nossos esforços no vocabulário controlado, na recategorização dos chamados e na base de conhecimento interna.
b) Depois, passamos para os roteiros e fluxos de atendimento.
c) Por fim, estruturamos manuais e uma FAQ para as pessoas usuárias, além de dar treinamento para a equipe do suporte.

3. Processo


3.1 Vocabulário controlado


Em uma coluna foram inseridos os termos que as pessoas usuárias utilizavam para se referir a um problema, ou seja, em linguagem natural. Cada um com seu vocabulário particular. (coloquei esses termos na coluna "Não usar")


Na coluna "Usar" (em verdinho) o mesmo problema foi traduzido para um termo adotado, ou seja, um vocabulário controlado, um vocabulário padronizado.



O vocabulário nos ajudou a nomear os assuntos encontrados naquela categoria do relatório que comentei, chamada “Outros”. Lembra?


Essa categoria antiga “outros” escondia muita coisa. Com as mudanças, cada nova categoria especificava melhor o assunto tratado no atendimento. Isso permitiu mais transparência nas informações para os nossos relatórios tão necessários.



Observamos que a plataforma não oferecia fácil acesso ao suporte técnico e nem para conteúdos de ajuda sobre o uso do produto. Os clientes entravam em contato com suporte com muitas dúvidas. Veja que a quantidade de atendimentos sobre dúvidas era bem significativa.



gif


As pessoas tinham que ir às redes sociais e as lojas dos apps para reclamar publicamente. É claro que isso gerava uma enorme exposição negativa.



3.2 Scripts e fluxos de atendimento


Mapear era com a gente mesmo rs. Mapeamos todo o fluxo de atendimento do suporte para tentar compreender a experiência do atendimento como um todo.


Fazendo isso foi possível identificar a necessidade de implementação de uma triagem por meio de um formulário na plataforma de chamados, uma forma de coletar dados iniciais que ajudassem o agente a tomar decisões com maior embasamento. A ideia era reduzir


A ideia era reduzir a quantidade de interações com o usuário para ir coletando informações que precisava para realizar o atendimento. Tipo um bate e volta de perguntas e respostas, um joguinho de tênis. Mais ou menos isso:





Basicamente o fluxo passou a seguir as seguintes etapas:


A pessoa usuária informa o problema no chamado em sua linguagem natural;
A pessoa agente do suporte realiza triagem solicitando o preenchimento de um formulário conciso e coleta informações necessárias para entender ou reproduzir o problema relatado;
Só então o problema é traduzido e encaminhado para a tratativa interna;
A pessoa usuária é informada sobre cada etapa do atendimento (status) até a sua finalização.


O fluxo completo, com um pouco mais de detalhes está aqui pra quem tiver interesse:


Nesse link dá para navegar pela imagem aumentada.


Com o fluxo em mãos, fizemos alguns ajustes e depois de um tempo pude estruturar um roteiro de atendimento com textos padronizados a partir do vocabulário controlado. Os textos desse roteiro estavam alinhados com o vocabulário controlado, a forma e o jeito da marca de falar ; )


Nesse ponto, tivemos auxílio do setor jurídico e comercial para ajustar esse tom da voz. Mas ainda não tínhamos um Guia de Voz de Marca. Na época eu nem sabia que isso existia.



gif


Bom, continuando rs.


Tenho aqui alguns exemplos do Guia de Atendimento (ou seja, o roteiro que comentei) contendo o problema, a resposta inicial, os links para as ações que os agentes de suporte deveriam aplicar e a resposta final.


O Guia seria útil em um primeiro momento do projeto, a ideia era evitar usar sempre respostas tão prontas (o que poderia deixar o atendimento meio robotizado) e treinar a equipe posteriormente para que pudesse "redigir" os próprios textos a partir de novas orientações nesse memo guia.

Hoje eu teria modificado vários elementos nesse documento, com o tempo fui aprendendo muito mais coisas, mas na época foi um documento fundamental para o projeto.


; )


Vou mostrar um exemplo do termo autenticação:



Ao clicar em ação, o agente seguia direto para esse trecho do documento:


Depois de tudo resolvido, era só finalizar com esse texto:



Bem, pra encerrar esse relato queria dizer que a atuação de uma UX Writer em conjunto com as demais equipes permitiu que ouvíssemos o cliente, os agentes do suporte e suas dores.


Detectamos falhas não somente na experiência textual, mas na experiência como um todo e também na gestão de conhecimento da empresa.


“O texto pode ser mínimo, mas é muito valioso”. TORREY PODMAJERSKY — Redação Estratégica para UX.

Esse projeto foi um daqueles que nunca esqueci e que adorei fazer parte. Eu já atuava com vocabulário controlado para outro produto da empresa e adorei encarar esse novo desafio.


Na época eu era uma bibliotecária e estudante da Pós-Graduação em Gestão de Informação Digital na FESPSP e já sonhava estudar Arquitetura da Informação. De alguma forma, esse projeto me deixou feliz porque era uma bibliotecária aplicando seus conhecimentos em conjunto com profissionais de UX e de Desenvolvimento.


Eu, que sempre amei escrever e que adorava as aulas de taxonomia, tesauros, indexação, rss, senti naquela época que o bibliotecário tinha muito campo de trabalho. Vislumbrar isso me deixou satisfeita.


Amo a minha formação, não a trocaria por nada. Ela me permitiu e ainda me permite caminhar por muitos espaços de atuação e de aprendizado.

Esse texto foi publicado originalmente no perfil do medium da Lygia Canelas ; )

221 visualizações0 comentário

Posts Relacionados

Ver tudo