Como criar guias de suporte ao cliente com capturas de tela

Os melhores artigos de suporte começam como chamados. Quando a mesma dúvida chega três vezes em uma semana, um guia de capturas responde a quarta vez mais rápido do que uma resposta digitada e entrega a todos os agentes a mesma resposta para enviar.

Este post mostra como transformar um chamado resolvido em um guia, gerar as capturas em um Mac com o Temposhot e devolver o resultado para a equipe de suporte.

Escolha um problema resolvido do cliente

Escolha um chamado já resolvido e cuja correção você considera confiável. Escrever um guia enquanto a causa ainda não está clara espalha um palpite para todos os clientes que o lerem.

Bons candidatos têm três características:

• A correção é a mesma para a maioria dos clientes que perguntam.
• A correção tem mais de dois passos ou envolve um controle difícil de encontrar.
• Os agentes hoje explicam o procedimento em texto livre, cada um de um jeito.

Use as próprias palavras do cliente no título do guia. "Alterar o e-mail da minha conta" corresponde ao que as pessoas digitam na busca. "Gestão de e-mail da conta" não corresponde.

Pontue os chamados candidatos

Conte os chamados de cada candidato nos últimos 30 dias e conte os passos da correção. Volume e tamanho juntos definem a ordem. Um problema que chega 11 vezes por mês com uma correção de 4 passos economiza mais respostas do que um problema raro com uma correção de 12 passos.

A correção do e-mail de cobrança vence em volume e tem passos claros. A redefinição de dois fatores também aparece com frequência, mas depende de verificações de identidade que a política de suporte define. Escreva esse guia com o responsável pela política, para que ele leve o cliente pela política e não a pule.

Confirme a correção com o responsável pelo recurso

Uma correção de chamado pode ser um workaround. Antes de gravar, peça ao responsável pelo recurso que confirme que os passos são o caminho suportado. Escreva o nome de quem confirmou e a data no campo de responsável do guia. Se um workaround deixar de funcionar após uma release, há uma pessoa nomeada para quem reportar. Se o responsável não puder confirmar os passos, mantenha o chamado aberto com o líder de suporte e não publique o guia.

Defina quando o guia se aplica

Um guia que funciona para um plano e falha em outro gera novos chamados. Declare o escopo no topo, em uma ou duas linhas:

• Plano ou tipo de conta em que os passos são válidos.
• Plataforma: web, app de desktop ou app mobile.
• Papel necessário, como proprietário da conta ou administrador.
• O que o cliente deve ter em mãos, como um número de pedido.

Se os passos mudarem por plataforma, escreva dois guias em vez de um com ramificações em todas as páginas.

Escreva guias separados para web e mobile

O campo de e-mail de cobrança fica em Account no app web e em Profile no app mobile. Um guia único com os dois caminhos obriga o leitor a procurar ramificações em todas as páginas. Escreva dois guias com a mesma base de título, como "Change the billing email (web)" e "Change the billing email (mobile)".

Defina o bloco de escopo de cada guia com o nome da plataforma. Assim, o agente envia o guia certo já na primeira resposta, e o cliente não começa pelo caminho errado.

Escreva a linha de escopo como tabela

Uma linha de escopo dentro de uma frase passa despercebida com facilidade. Uma tabela curta no topo do guia torna cada condição visível. O exemplo abaixo cobre o guia de e-mail de cobrança. A última linha remove o uso errado mais comum do guia.

Cada linha responde a uma pergunta que o agente faria na primeira resposta. A linha "Não coberto" é a mais importante. Clientes que a leem param antes do primeiro passo, e o agente recebe um chamado com o tipo de conta correto já informado.

Recrie a solução com dados de teste

Capturas de uma conta de funcionário mostram menus que o cliente não tem. Capturas de uma conta real de cliente mostram os dados dele. Use uma conta de teste no mesmo plano, com nomes fictícios como "Sample Customer" e um domínio de e-mail de exemplo.

1. Start Action Capture

   Pressione Command+3, selecione Start Action Capture e escolha Specific Window para o navegador ou app.

2. Comece onde o cliente começa

   Comece pela tela que o cliente vê depois de entrar, e não por um link direto que só a equipe interna conhece.

3. Execute a correção

   Clique em cada passo. Cada clique aceito salva a janela logo antes do clique.

4. Finalize a execução

   Selecione Finish capture na barra flutuante. O Document abre no editor com uma página por passo.

Com Parse clicked elements ativado em Configure, os títulos das páginas começam como Click "[[element-name]]" com o nome do controle preenchido. O guia do Action Capture lista as configurações.

Use o chamado como roteiro de teste

A conversa do chamado é o roteiro de teste. Copie a sequência de ações que o cliente descreveu, incluindo as tentativas que não funcionaram. Uma tentativa malsucedida que aparece no chamado geralmente marca o passo que precisa de um aviso. Adicione o aviso à página antes desse passo, e não depois, para que o leitor o veja antes do clique.

Prepare a conta de teste

A correção precisa funcionar no estado da conta que o chamado descreve. Uma mudança que depende de uma fatura pendente falha em uma conta nova, então prepare o estado antes de gravar. A checklist abaixo cobre as lacunas mais comuns.

Verifique o nível de zoom antes da primeira execução. Um guia gravado com zoom de 110% e lido com zoom de 100% tem os controles em lugares diferentes, e o leitor não consegue associar a captura à tela.

Grave o caminho do erro

Alguns chamados começam com um erro. Grave o erro uma vez na conta de teste, no momento em que o cliente o vê. Coloque o texto exato do erro na descrição dessa página e a correção na página seguinte. Um leitor que vê o mesmo erro consegue confirmar que está no guia certo antes de começar.

Mantenha a página de erro no guia mesmo quando a correção for curta. Agentes pesquisam pelo texto do erro, e uma página com o texto na descrição é mais fácil de encontrar do que uma página com apenas uma captura.

Registre os atalhos que importam

A própria gravação depende de algumas teclas. Os atalhos abaixo cobrem a gravação e a edição.

Decisões de captura e pontos de verificação

A maioria das correções de suporte inclui um momento em que o cliente precisa escolher: qual opção em um dropdown, qual aba nas configurações. Dê a esse momento uma página própria e nomeie a escolha na descrição.

Algumas telas aparecem sem clique, como um estado de carregamento ou um banner de confirmação. Pressione Shift+Command+2 (o atalho de captura manual) ou selecione Capture now para salvá-las. Um guia sem esses pontos de verificação deixa o cliente sem saber se o último clique funcionou.

Nomeie a escolha na página

Uma página de decisão precisa do nome da opção como aparece na tela, além da condição que torna essa a opção certa. A tabela abaixo lista problemas comuns de redação. As regras da coluna da esquerda valem para toda página de decisão.

Capture o estado de espera

Clientes param diante de um spinner ou de um rótulo "Processing" e clicam de novo. Capture o estado de espera como uma página própria, com uma descrição que diga quanto tempo a espera dura e o que não fazer. Por exemplo: "O processamento costuma terminar em menos de um minuto. Não selecione Save de novo enquanto este rótulo estiver visível."

Use a mesma regra para qualquer passo que envie um e-mail ou altere um valor em segundo plano. Informe o atraso esperado na descrição da página, para que o cliente saiba quando parar de esperar.

Trate listas longas em dropdowns

Um dropdown com mais de cerca de dez opções não cabe em uma captura em tamanho legível. Capture a lista aberta com a opção de destino visível e depois adicione uma página que mostre o campo após a escolha. Coloque o nome da opção no título da primeira página e o resultado no título da segunda.

Não conte com o leitor para rolar a lista. Se a opção estiver abaixo da área visível, use um recorte de Framing que mantenha a opção e cite-a na descrição, como "Role até Annual, a quarta opção a partir da parte de baixo".

Escreva cada passo em torno da próxima ação do cliente

Reescreva cada título interpretado para dizer ao cliente o que fazer, começando com um verbo.

Título interpretado	Título reescrito
Click "Settings"	Abra Settings
Click "Email"	Selecione o campo Email
Click here	Escolha o seu novo plano

Use Framing (F) com Focus on action para dar zoom no controle. Balanced ou Close normalmente mantêm contexto suficiente para um leitor em um notebook. Exclua as páginas criadas por cliques acidentais no painel Pages.

Nomeie o resultado, não o rótulo

Títulos interpretados copiam o rótulo do controle. Um rótulo como "OK" ou "Submit" não diz nada sobre o resultado. Reescreva o título para nomear o que o clique faz: "Selecione Save para aplicar o novo e-mail". Assim, o cliente sabe o que muda antes de clicar.

Confira cada título contra a tela que vem depois. Se o título nomear um resultado que a página seguinte não mostra, o passo está sem um ponto de verificação.

Mantenha uma ação por passo

Um passo que diz "Abra Account, selecione Email e digite o endereço" esconde duas decisões. Um leitor que falha na segunda ação não tem uma página para apontar. Divida o passo em três: abrir Account, selecionar Email e digitar o endereço. Cada passo então tem uma captura e um título que corresponde a ela.

Há uma exceção. Duas ações que a tela trata como uma unidade, como digitar um endereço e pressionar Return, podem ficar no mesmo passo quando o resultado é uma única página. Nomeie as duas ações no título, como "Digite o endereço e pressione Return".

Adicione uma verificação clara de sucesso

Termine o guia com o que o cliente vê quando a correção funcionou: um banner, um valor atualizado, um e-mail de confirmação. Capture essa tela e titule-a como um resultado, como "Seu novo e-mail aparece em Account".

Sem uma verificação de sucesso, clientes costumam repetir os passos ou abrir um chamado para confirmar.

A ordem das páginas de um guia finalizado

O fluxo abaixo mostra a ordem das páginas do guia de e-mail de cobrança. Cada caixa é uma página do Document, e as setas indicam a ordem que o leitor segue.

A verificação de sucesso é a última página antes da página de escalonamento. Um cliente que vê o banner para ali. Um cliente que não o vê chega à página de escalonamento com a tela em que parou.

Adicione condições de escalonamento e evidências

Informe quando o guia deixa de resolver e o cliente deve contatar o suporte. Descreva condições observáveis: uma mensagem de erro, um botão ausente, uma cobrança que não mudou.

Diga ao cliente o que enviar para que o agente não precise perguntar: o texto do erro, o horário e uma captura da tela em que o problema parou. Peça que ele remova senhas e números de cartão antes de enviar.

Escreva o bloco de escalonamento

O agente que recebe um escalonamento precisa de cinco dados sem perguntar: o identificador da conta, o plano, a plataforma, o texto exato do erro e o horário com o fuso horário. Coloque esses dados em um bloco fixo no fim do guia. O cliente copia o bloco para a mensagem, e a primeira resposta do agente pode tratar o problema diretamente.

Meça o efeito do guia

Conte os chamados sobre o mesmo problema durante duas semanas após a publicação do guia. O exemplo abaixo vem de um guia de e-mail de cobrança que substituiu uma resposta em texto livre.

O chamado restante com erro foi para a página de escalonamento, o que deixou a resposta curta. Sem o texto do erro, o agente teria pedido o texto, o que adiciona uma resposta à conversa. Conte os escalonamentos separadamente, porque eles mostram lacunas no guia e não lacunas no produto. Revise cada escalonamento em até uma semana após o chamado. Uma resposta que o guia poderia ter dado é uma página a reescrever, e uma resposta que o guia não consegue dar é uma nova linha de escopo.

Redija antes da publicação do guia

A redação é a última edição antes de o guia chegar à central de ajuda. Use a ordem abaixo, para que a verificação aconteça no tamanho exportado de cada página e não na visualização do editor.

Teste o guia com um leitor novo

Entregue o guia exportado a alguém que não o escreveu, de preferência um agente novo, e peça que conclua a correção em uma conta de teste sem ajuda. Cada pergunta que ele fizer marca uma página a reescrever.

Depois, publique. O Temposhot não tem página hospedada nem embed, então exporte de acordo com o destino: páginas PNG ou WebP para um artigo da central de ajuda, Export PDF para um anexo de e-mail. O guia de exportação de Documents lista os formatos. Para escolher entre os dois, veja guia em PDF ou base de conhecimento online.

Cronometre o teste com o leitor

Registre o teste com o leitor da mesma forma que uma sessão de cliente. Anote o horário em cada parada, porque uma pausa longa em uma página aponta para um título ou uma decisão que precisa de ajuste.

Reescreva primeiro a página de decisão. No exemplo, a pergunta era se o novo e-mail substitui o antigo imediatamente. A resposta foi para a descrição da página de decisão, e o leitor seguinte não parou ali.

Defina as condições do leitor

Dê ao leitor o mesmo zoom do navegador, o mesmo tamanho de janela e o mesmo estado de conta que o guia pressupõe. Um leitor com uma janela menor vê outro layout e não consegue associar a primeira captura, então o teste falha por um motivo que o guia pode corrigir. Escreva o tamanho da janela no bloco de escopo quando o layout depender dele.

Organize os guias para a central de ajuda

Guarde cada guia em uma pasta com o nome nas palavras do próprio cliente, para que o nome da pasta corresponda ao que o leitor digita na busca. Mantenha as páginas PNG junto com o PDF de origem, para que o par seja fácil de substituir em conjunto.

Use números de passo nos nomes dos arquivos PNG, para que as páginas sejam ordenadas na ordem de leitura quando a pasta for aberta no Finder.

Perguntas frequentes

Quantos passos um guia de suporte deve ter?

Quantos a correção exigir, com uma ação por passo. Se um guia passar de cerca de dez passos, verifique se ele cobre dois problemas.

Os guias de suporte devem usar capturas de clientes reais?

Não. Recrie a correção com uma conta de teste. Capturas de clientes reais contêm dados pessoais e podem mostrar configurações exclusivas daquele cliente.

Como manter os guias de suporte atualizados?

Dê a cada guia um responsável e uma data da última verificação, e revise-o sempre que uma release alterar essas telas. Veja como manter a documentação com capturas de tela atualizada.

O guia substitui a resposta do chamado?

Não. O guia substitui a parte repetida da resposta. O agente ainda confirma o estado da conta e acrescenta os detalhes que o guia não cobre, como a decisão sobre um reembolso.

Como saber se um guia ainda corresponde ao produto?

Revise o guia quando uma release alterar as telas dele e refaça o teste com o leitor após qualquer mudança em uma página de decisão. Alterar o rótulo de um botão ou a posição de um menu conta como uma mudança no guia.

Quem é responsável pelo guia depois da publicação?

A pessoa indicada no campo de responsável do guia. Ela responde ao feedback dos leitores, reescreve as páginas que causaram escalonamentos e aposenta o guia quando o recurso muda. Uma pasta compartilhada da central de ajuda não atribui um responsável por si só.

Para onde os leitores devem enviar feedback?

Informe o canal de suporte na última linha do guia. As capturas não recebem respostas, então um leitor com dúvida precisa de um caminho que chegue a uma pessoa.

Quando um guia deve ser aposentado?

Aposente um guia quando o recurso que ele descreve mudar, ou quando a contagem de chamados ficar em zero por três meses enquanto o recurso ainda existir. Remova o guia da central de ajuda e guarde os arquivos exportados em uma pasta de arquivo com a data. Um guia aposentado que continua pesquisável leva leitores a passos que não existem mais.

Transforme seus cliques em um guia passo a passo claro

Action Capture registra a correção uma vez e gera um guia ordenado para editar e exportar. Baixe o Temposhot e transforme seu chamado mais repetido em um guia.