Como transformar reclamações nas redes sociais em tickets de suporte

Por que razão as reclamações nas redes sociais passam despercebidas

A maioria das equipas de suporte acompanha as redes sociais, mas apenas a parte que lhes é dirigida. Os serviços de apoio com integração com o X recolhem as menções diretas à sua conta oficial. Isso funciona quando as pessoas o identificam. Muitas não o fazem.

As pessoas escrevem "acme" em vez de "@acme". Perguntam no r/sysadmin se a sincronização de mais alguém falhou. Mencionam a sua marca a meio de um comentário no Hacker News sobre outro assunto. Nada disso chega a um feed de menções e nada disso chega a quem está de serviço.

O outro problema é a responsabilidade. Quando as reclamações nas redes são detetadas pelo marketing, tendem a ficar num canal de Slack de marketing até alguém as reencaminhar. Um ticket tem um responsável, um prazo e um estado. Uma mensagem do Slack não tem nada disso, pelo que a solução passa por transformar a reclamação num ticket o mais cedo possível.

Criar alertas que detetem reclamações

Antes de integrar o que quer que seja no seu suporte técnico, precisa de alertas que identifiquem problemas de suporte e não todas as menções à sua marca. Um alerta do KWatch exige que todas as palavras-chave da lista estejam presentes, pelo que as vírgulas funcionam como um E lógico. Isso permite associar o nome do seu produto às palavras que as pessoas usam quando algo não funciona.

Utilizando «acme» como representação do seu produto, um conjunto inicial seria assim:

1. acme, not working e acme, broken para avarias completas

2. acme, can't login e acme, logged out para problemas de conta

3. acme, refund e acme, charged para reclamações de faturação

4. acme, help para pessoas que perguntam como fazer algo

Cada linha constitui um alerta próprio. Se colocasse todas essas palavras num único alerta, uma publicação precisaria de conter cada uma delas para corresponder. Após uma semana, verifique quais os alertas que dispararam e como os seus utilizadores se expressam, fazendo depois os devidos ajustes. Experimente também o seu identificador oficial como palavra-chave, dado que algumas pessoas identificam-no em vez de escreverem o nome da marca.

Os filtros mantêm a fila limpa e aqui são mais importantes do que em qualquer outro lugar, porque cada falsa correspondência torna-se num ticket que alguém tem de fechar. Adicione as suas próprias contas de suporte e da marca como Utilizadores excluídos, para que as suas respostas não abram novos tickets. No Reddit e no Hacker News, ative Apenas palavras inteiras se o seu nome for curto, para que «acme» não corresponda a «acmeplex». Algumas palavras-chave excluídas podem eliminar ruído óbvio, como anúncios de emprego que o mencionam. Mantenha essa lista curta, porque uma publicação é descartada assim que qualquer uma das palavras-chave excluídas aparece. Analisámos cada filtro no nosso artigo sobre reduzir o ruído nos alertas de palavras-chave.

Com que rapidez uma reclamação chegará até si?

A velocidade depende da plataforma e convém sabê-lo antes de prometer um tempo de resposta a alguém. Estas são as frequências de atualização da nossa documentação:

Assim, uma reclamação no X pode demorar até uma hora a chegar à sua fila. Para a maioria das equipas de suporte, isso continua a ser muito mais rápido do que descobri-la manualmente na quarta-feira. No entanto, se cumprir um SLA rigoroso em @menções diretas, mantenha o canal nativo do X do seu serviço de apoio para essas situações e utilize alertas de palavras-chave para tudo o que ele não consegue ver, como publicações sem identificação, tópicos do Reddit e comentários do Hacker News. O KWatch também não consegue ler DMs, pelo que as mensagens privadas continuam nas suas ferramentas existentes.

Enviar cada reclamação para o seu suporte técnico

Assim que os alertas estiverem a disparar, o passo seguinte consiste em retirá-los do KWatch e transformá-los em tickets. A forma mais simples e direta é um webhook de API. Cada correspondência chega como um payload JSON e pode definir um webhook por alerta, para que os seus alertas de reclamações sigam para o suporte técnico enquanto os restantes alertas vão para outro sítio. Um webhook por alerta tem precedência sobre o configurado ao nível da conta.

Eis o exemplo de payload da nossa documentação:

{
  "platform": "reddit",
  "query": "Keywords: vllm",
  "datetime": "19 Jan 24 05:52 UTC",
  "link": "https://www.reddit.com/r/LocalLLaMA/comments/19934kd/sglang_new/kijvtk5/",
  "author": "lmzoo",
  "content": "sglang runtime has a different architecture on the higher-level part with vllm.",
  "sentiment": "neutral"
}

Todos os campos de que necessita para um ticket estão presentes. O campo content passa a ser a descrição, o link fica no topo para que o agente possa abrir o tópico, e a query indica-lhe qual o alerta que disparou. No X, o campo de autor inclui também o nome completo da pessoa e a contagem de seguidores, o que ajuda o agente a decidir o que responder primeiro.

No Zapier

1. Crie um Zap com o Webhooks by Zapier e o acionador Catch Hook e, em seguida, cole o URL do webhook no campo API Webhook URL dos seus alertas de reclamações.

2. Adicione uma etapa de Filter se pretender que apenas algumas correspondências se transformem em tickets. Uma regra comum consiste em deixar passar tudo em que o sentiment não seja positivo, o que exclui as publicações do tipo «o acme resolveu o meu problema em cinco minutos».

3. Adicione a ação de criação de ticket do seu suporte técnico. No Zendesk é Create Ticket. Mapeie o content para a descrição, componha o assunto a partir de platform e author, e adicione uma etiqueta como social para que seja fácil elaborar relatórios sobre estes tickets.

No n8n

O mesmo fluxo funciona com um nó Webhook, um nó IF em sentiment, e o nó do Zendesk ou Freshdesk configurado para criar um ticket. Se nunca tiver ligado o KWatch a nenhuma destas ferramentas, o nosso guia de Zapier e n8n explica a configuração dos webhooks passo a passo.

Uma nota sobre o filtro de sentimento: este é avaliado em relação à sua palavra-chave e o sarcasmo ainda o consegue enganar de vez em quando, pelo que recomendo utilizá-lo como um filtro permissivo nas primeiras semanas. Envie tudo, veja o que foi marcado como positivo e só depois permita que o filtro descarte tickets.

Responder a uma reclamação em público

Um ticket com origem no Reddit é um ticket invulgar, porque o cliente não lho enviou diretamente. O modo como responde determina se isso é útil.

Recomendo manter a primeira resposta curta, pública e específica. Diga quem é, confirme que viu o problema e forneça uma solução alternativa ou o passo seguinte. Se necessitar dos detalhes da conta, peça para lhe enviarem mensagem e nunca solicite dados pessoais no tópico. Quando o problema estiver resolvido, volte lá a dizê-lo. Essa última resposta será a que a próxima pessoa com o mesmo problema encontrará no Google.

Alguns tópicos serão sobre questões que não consegue resolver, como uma alteração de preços que não agradou aos utilizadores. Esses tópicos também merecem um responsável, mas geralmente é melhor etiquetá-los e encaminhá-los para a equipa de produto do que serem respondidos pelo suporte. E se uma reclamação se transformar em vinte numa hora, já não é um mero ticket de suporte. O nosso guia sobre como detetar uma crise de relações públicas nas redes sociais explica o que fazer quando isso acontece.

Se a sua equipa de suporte também gere uma lista restrita de contas estratégicas, o nosso produto irmão MultiFollow alerta-o quando utilizadores específicos do Linkedin e do X publicam, para que veja a publicação de um promotor frustrado mesmo que esta nunca refira o nome do seu produto.