Ao interagir com os usuários pelos agentes do Business Messages, lembre-se das práticas recomendadas a seguir.
Não forneça nem solicite informações confidenciais
Evitar conteúdo confidencial durante os chats protege você e seus clientes. Informações confidenciais incluem, mas não se limitam a
- Números de cartões de crédito
- passaporte, CPF ou outros números de identificação emitidos pelo governo;
- Credenciais de login, como senhas
Responda aos usuários rapidamente
Tempos de resposta lentos ou não razoáveis para as mensagens do usuário criam uma experiência ruim para os clientes. Projete sua infraestrutura de resposta para fornecer respostas consistentes às mensagens dos usuários.
Pior ainda é uma resposta lenta. Verifique se os usuários sempre recebem respostas às mensagens, independentemente do carregamento da mensagem. Por exemplo, se a equipe ativa não estiver disponível, envie uma mensagem automática reconhecendo o usuário e inclua uma estimativa de quando o usuário pode esperar uma resposta completa.
O Google mede o tempo de resposta (TTR, na sigla em inglês) entre as mensagens. Se o agente de uma marca demorar a responder aos consumidores, o Google vai remover os botões de mensagem.
Quando a automação não atender às solicitações, passe para os humanos
Os usuários ficam frustrados quando a automação não responde da maneira correta a eles. É por isso que todos os agentes lançados a partir de pontos de entrada gerenciados pelo Google (exceto o ponto de entrada do Google Ads) precisam ter representantes humanos que podem conduzir conversas quando a automação não pode. Antes do lançamento, você precisa definir o tipo de interação do agente para incluir representantes humanos.
Quando a automação não atender à solicitação de um usuário duas vezes seguidas, é melhor enviar uma mensagem com uma sugestão de solicitação de agente em tempo real.
Quando um usuário toca nessa sugestão, seu agente recebe um evento de pedido de ativação em tempo real. Seu agente precisa responder conversando com um representante humano para que o usuário receba a ajuda de que precisa.
Humanos não precisam estar disponíveis 24 horas. Defina a disponibilidade do seu agente para que os usuários saibam quando podem esperar uma resposta humana.
Autenticar usuários com o OAuth
Para verificar as identidades dos usuários e fornecer informações personalizadas a eles, autentique os usuários com sistemas de back-end por meio do OAuth. A autenticação com o OAuth permite que os agentes acessem os dados do usuário rapidamente e impede que eles incluam informações confidenciais na conversa, como nomes de usuários ou senhas. Consulte Autenticar com o OAuth.
Meça a satisfação dos clientes com o Business Messages
O Business Messages mede as pontuações de satisfação dos clientes (CSAT, na sigla em inglês) com pesquisas diretamente nas experiências de mensagens. Para evitar que os usuários recebam várias pesquisas, use a funcionalidade de pesquisa do Business Messages. Não implemente suas próprias técnicas de medição de SAT. CLIENTE.
Mantenha o foco
Não envie mensagens indesejadas ou irrelevantes para a conversa atual. Por exemplo:
- Mensagens sobre um produto ou serviço não relacionadas à solicitação original
- Mensagens repetidas sem resposta do usuário
- Mensagens muito longas ou uso excessivo de emojis e URLs
Usar o ID do lugar quando ele estiver disponível
Para pontos de entrada baseados em localização, as mensagens podem conter um placeId no
payload de contexto. É possível usá-lo para fornecer informações sobre as quais o usuário
pode estar se perguntando, como o inventário em um local específico. Um placeId identifica exclusivamente um lugar no banco de dados do Google Places e na Plataforma Google Maps.
Mesmo que você inicie apenas com pontos de entrada baseados em localização, implemente uma estratégia para situações em que um placeId não esteja presente. Embora
não seja comum, há circunstâncias em que um placeId, entre outros dados
contextuais, não é transmitido para o webhook.
Implementar novas tentativas com espera exponencial
Ao chamar qualquer API, é possível que uma chamada falhe devido a problemas de infraestrutura, sobrecarga de serviço, limites de QPS e outros erros. Para se recuperar de chamadas de API com falha, implemente novas tentativas com espera exponencial.
Usando novas tentativas com espera exponencial, sua infraestrutura automaticamente
- Identifica uma chamada de API com falha
- Define a duração inicial da espera e o número máximo de novas tentativas.
- Pausa para a duração da espera
- Tentar novamente a chamada da API
Avalia a resposta da chamada de API:
- Se for bem-sucedido, prosseguir para a próxima etapa no fluxo de trabalho
- Em caso de falha, aumenta a duração da espera e retorna à etapa 3.
- Se ocorrer uma falha após o número máximo de novas tentativas, entrará em um estado de falha.
As durações ideais de espera e o número máximo ideal de novas tentativas variam de acordo com o caso de uso. Determine esses números com base nos requisitos de latência da sua infraestrutura e dos fluxos de trabalho.
Verificar se há mensagens duplicadas
Ao conferir e responder às mensagens recebidas dos usuários, confira o
messageId e se você ainda não os recebeu e respondeu
anteriormente.
Com os sistemas distribuídos, há duas maneiras de enviar mensagens: no máximo uma vez e pelo menos uma vez. Com sistemas "no máximo uma vez", o sistema envia uma mensagem uma vez, mas, se houver erros de rede ou comunicação, a mensagem pode não ser recebida. Com sistemas "pelo menos uma vez", o sistema pode enviar uma mensagem várias vezes, mas a mensagem pode ser recebida mesmo quando houver erros de rede ou comunicação.
O Business Messages usa um sistema "pelo menos uma vez". Embora isso possa levar a
mensagens recebidas duplicadas, é fácil eliminar a duplicação de mensagens
rastreando strings messageId. Se você já recebeu uma mensagem, é seguro
ignorar outras mensagens recebidas com a mesma messageId.