Ao interagir com os usuários por meio de agentes do Business Messages, siga as práticas recomendadas abaixo.
Não forneça ou solicite informações sensíveis
Ao evitar conteúdo sensível durante os chats, você mantém suas informações e as dos clientes em segurança. Informações sensíveis incluem, entre outros:
- 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
Responder aos usuários rapidamente
Tempos de resposta lentos ou inadequados às mensagens dos usuários criam uma experiência ruim para os clientes. Projete sua infraestrutura de resposta para responder às mensagens dos usuários de forma consistente.
Pior do que uma resposta lenta é não receber nenhuma resposta. Verifique se os usuários sempre recebem respostas, independentemente da carga de mensagens. Por exemplo, se a equipe não estiver disponível, envie uma mensagem automática confirmando o usuário e incluindo uma estimativa de quando ele pode esperar uma resposta completa.
O Google mede o tempo de resposta (TTR) entre as mensagens. Se o agente de uma marca demorar para responder aos consumidores, o Google vai remover os botões de mensagens dela.
Quando a automação não puder atender às solicitações, transfira para humanos
Os usuários ficam frustrados quando a automação não responde corretamente a eles. Por isso, todos os agentes que são iniciados em pontos de entrada gerenciados pelo Google (exceto o ponto de entrada do Google Ads) precisam ter representantes humanos que possam lidar com conversas quando a automação não puder. Antes do lançamento, é necessário definir o tipo de interação do agente para incluir representantes humanos.
Quando a automação não consegue atender a 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, o agente recebe um evento solicitado pelo agente ativo. O agente precisa responder transferindo a conversa para um representante humano, para que o usuário receba a ajuda necessária.
As pessoas não precisam estar disponíveis 24 horas. Defina a disponibilidade do seu agente para que os usuários saibam quando 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 usando o OAuth. A autenticação com OAuth dá aos agentes acesso rápido aos dados do usuário e impede que usuários ou agentes incluam informações sensíveis (como nomes de usuário ou senhas) na conversa. Consulte Autenticar com o OAuth.
Medir a CSAT nas Mensagens comerciais
O Business Messages mede as pontuações de satisfação do cliente (CSAT, na sigla em inglês) com pesquisas diretamente nas experiências de troca de mensagens. Para evitar que os usuários recebam várias pesquisas, use a funcionalidade de pesquisa das Mensagens comerciais. Não implemente suas próprias técnicas de medição de CSAT.
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 relacionado à solicitação original
- Enviar várias mensagens sem resposta do usuário
- mensagens longas demais ou uso excessivo de emojis e URLs.
Use o ID de local quando ele estiver disponível
Para pontos de entrada com base na localização, as mensagens podem conter um placeId no
payload de contexto. Você pode usá-lo para fornecer informações que o
usuário pode estar perguntando, como o inventário em um local específico. Um placeId identifica de forma exclusiva um lugar no banco de dados do Google Places e na Plataforma Google Maps.
Mesmo que você só lance com pontos de entrada baseados em local, implemente uma estratégia para situações em que um placeId não está presente. Embora
não seja comum, há circunstâncias em que um placeId, entre outros dados
contextuais, não é transmitido para o webhook.
Implementar repetições 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.
Ao usar repetições com espera exponencial, sua infraestrutura automaticamente
- Identifica uma chamada de API com falha
- Define a duração inicial de espera e o número máximo de novas tentativas
- Pausa durante o tempo de espera
- Tenta novamente a chamada de API
Avalia a resposta da chamada de API:
- Se for bem-sucedido, prossiga para a próxima etapa no fluxo de trabalho
- Se houver uma falha, aumente a duração da espera e volte para a etapa 3.
- Se uma falha ocorrer após o número máximo de novas tentativas, o estado será "falha".
Os períodos de espera ideais e o número máximo de novas tentativas ideais 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 recebidas duplicadas
Ao verificar e responder a mensagens recebidas de usuários, verifique o
messageId e confirme se você já não recebeu e respondeu à
mensagem anteriormente.
Com sistemas distribuídos, há duas maneiras de enviar mensagens: pelo menos 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 de comunicação, a mensagem poderá 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 há erros de rede ou de comunicação.
As Mensagens comerciais usam um sistema "pelo menos uma vez". Embora isso possa levar a
mensagens duplicadas, é fácil remover a duplicação delas
rastreando strings messageId. Se você já recebeu uma mensagem, pode
desconsiderar qualquer outra mensagem recebida com o mesmo messageId.