Esta página oferece práticas recomendadas para criar experiências eficazes e envolventes do RCS for Business, abrangendo a implementação técnica e o design conversacional.
Diretrizes técnicas
Verificar os recursos do dispositivo
Antes de iniciar uma conversa com um usuário, verifique se o dispositivo dele pode receber mensagens RCS. Para identificar os recursos do usuário, envie uma verificação de capacidade, e adapte as interações do agente de acordo com isso. Interaja apenas com os usuários de maneiras que os dispositivos deles ofereçam suporte. Se o dispositivo de um usuário não tiver o RCS ativado, configure um método de comunicação alternativo com outro canal, como SMS.
Respeitar o tamanho máximo da mensagem
Há limites para o tamanho máximo de uma mensagem do RCS for Business e o arquivo de mídia que ela pode conter. Consulte Tamanhos máximos de mensagens para mais detalhes.
Impedir o envio de mensagens duplicadas
Para evitar o envio de mensagens duplicadas aos usuários, seu sistema precisa confirmar que uma mensagem não foi entregue antes de tentar um fallback para SMS.
Siga estas práticas recomendadas para melhorar a confiabilidade do sistema e evitar mensagens duplicadas:
- Defina a vida útil do pool de conexões para corresponder ao tempo de vida (TTL) do DNS : use pools de conexões e objetos de cliente para reutilizar conexões e objetos de cliente atuais. Para evitar o uso de endereços IP desatualizados após atualizações de DNS, defina o tempo máximo que uma conexão ou objeto permanece no pool para corresponder ao tempo de vida do DNS da API.
- Não suponha que o tempo limite de conexão significa falha:não suponha que um tempo limite de conexão significa que a mensagem do RCS for Business não foi entregue. A mensagem ainda pode estar sendo processada no servidor.
- Verificar confirmações de entrega:sempre verifique as confirmações de entrega antes de acionar uma mensagem de fallback.
- Corresponder o TTL ao tempo limite de conexão:sempre que possível, defina o TTL da mensagem para corresponder ao tempo limite de conexão.
- Revogar mensagens antes do fallback: sempre tente revogar a mensagem original antes de enviar o SMS de fallback. Se a revogação falhar, processe a falha, já que isso pode indicar que a mensagem já foi entregue ao usuário.
- Tentar enviar mensagens novamente: se uma mensagem falhar devido a um erro repetível ou a um
tempo limite de conexão, tente a operação de envio novamente. Use o
messageIDinicial para evitarduplicações e implemente uma espera exponencial para espaçar as tentativas.
Verificar mensagens recebidas duplicadas
Ao verificar e responder a mensagens recebidas dos usuários, verifique o messageId e confirme se você já recebeu e respondeu à mensagem.
Com sistemas distribuídos, há duas maneiras de enviar mensagens:
- No máximo uma vez: o sistema envia uma mensagem uma vez, mas, se houver erros de rede ou comunicação ao longo do caminho, a mensagem poderá não ser recebida.
- 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 comunicação.
O Google Cloud Pub/Sub usa o sistema pelo menos uma vez. Embora isso possa levar a mensagens recebidas duplicadas, é simples remover a duplicação de mensagens rastreando strings messageId. Se você já recebeu uma mensagem, é seguro ignorar outras mensagens recebidas com o mesmo messageId.
Usar IDs exclusivos para todas as mensagens enviadas
Quando o agente envia uma mensagem ao usuário, o messageId incluído na chamada de API precisa ser exclusivo para cada mensagem.
Para mais informações sobre como receber mensagens, consulte Processar eventos recebidos.
Não usar endereços IP desatualizados
Seu sistema precisa sempre usar o endereço IP correto e atualizado ao se conectar à API RBM. Várias plataformas de programação usam tempos limite de cache de DNS padrão que podem ser significativamente mais longos do que a configuração de TTL do DNS do Google, o que pode fazer com que seu sistema tente se conectar a endereços IP expirados, levando a tempos limite. O TTL do cache de DNS do domínio RBM é de 300 segundos.
Para garantir que a lógica de conexão respeite nosso TTL de 300 segundos, siga estas etapas.
- Corresponda o tempo limite do pool de conexões ao TTL:se você usar um pool de conexões ou objetos de cliente, defina a vida útil máxima como 300 segundos (ou menos). Isso força seu sistema a buscar um novo endereço IP quando o objeto é atualizado.
- Garantir a atualização do DNS:confirme se a plataforma ou biblioteca de cliente HTTP está definida para atualizar o cache de DNS a cada 300 segundos ou menos.
- Verificar o TTL atual:recomendamos verificar programaticamente o TTL do domínio da API RBM para garantir que você esteja usando o valor máximo correto. É necessário verificar o domínio que corresponde à região de implantação:
dig +nocmd +noall +answer +ttlid A us-rcsbusinessmessaging.googleapis.com | sort
dig +nocmd +noall +answer +ttlid A asia-rcsbusinessmessaging.googleapis.com | sort
dig +nocmd +noall +answer +ttlid A europe-rcsbusinessmessaging.googleapis.com | sort
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 normalmente de chamadas de API com falha, implemente novas tentativas com espera exponencial.
Ao usar novas tentativas com espera exponencial, sua infraestrutura faz o seguinte 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 durante a duração da espera.
- Tenta novamente a chamada de API.
Avalia a resposta da chamada de API:
- Se for bem-sucedida, prossegue com a próxima etapa do fluxo de trabalho.
- Se houver falha, aumenta a duração da espera e retorna à etapa 3.
- Se houver falha após o número máximo de novas tentativas, entra em um estado de falha.
As durações de espera ideais e o número máximo de novas tentativas variam de acordo com o caso de uso. Determine esses números com base nos requisitos de latência da infraestrutura e do fluxo de trabalho.
Otimizar a performance da API com endpoints regionais
Para otimizar a performance da API e melhorar a latência:
Use os endpoints mais próximos da região do usuário.
A tabela a seguir oferece recomendações sobre quais endpoints regionais da RBM usar, dependendo do número de telefone do usuário.
Prefixo do número de telefone Endpoint recomendado Região geográfica +1 us-rcsbusinessmessaging.googleapis.com Américas +2 europe-rcsbusinessmessaging.googleapis.com Europa +3 europe-rcsbusinessmessaging.googleapis.com Europa +4 europe-rcsbusinessmessaging.googleapis.com Europa +5 us-rcsbusinessmessaging.googleapis.com Américas +6 asia-rcsbusinessmessaging.googleapis.com Ásia +7 europe-rcsbusinessmessaging.googleapis.com Europa +8 asia-rcsbusinessmessaging.googleapis.com Ásia +9 asia-rcsbusinessmessaging.googleapis.com Ásia Padrão us-rcsbusinessmessaging.googleapis.com Américas Considere localizar servidores perto do endpoint escolhido.
Consulte https://www.google.com/about/datacenters/locations/ para ver os data centers do Google.
Para mais informações sobre como identificar a região do agente, consulte a documentação Criar um agente.
Interface conversacional e experiência do usuário
Interface conversacional, não interface do app
Os agentes do RCS for Business são adequados para fornecer tarefas eficientes e específicas aos usuários em uma interface conversacional. Os agentes mais bem projetados mantêm as interações focadas, claras e estruturadas como uma conversa natural.
Os agentes não podem depender da interface visual de um app ou página da Web e não devem tentar imitá-la. Em vez disso, os agentes precisam depender de conversas cuidadosamente elaboradas que atendam às necessidades dos usuários, orientando-os com sugestões verbais, sugestões e bom tratamento de erros.
Os agentes também não devem imitar árvores telefônicas ou interfaces que dependem de usuários que respondem com um número que representa uma determinada ação. Os usuários precisam se comunicar com os agentes naturalmente, assim como se comunicariam com outra pessoa em uma conversa.
Iniciar uma conversa
O início de uma conversa define as expectativas do usuário sobre o que um agente pode fazer. Comece as conversas com uma nota forte: mostre a personalidade do seu agente, informações importantes para os usuários e compartilhe o que seu agente pode fazer. Ofereça aos usuários opções claras para interagir com seu agente e continuar a conversa.
Mostre a personalidade do seu agente: defina o tom cumprimentando o usuário e apresentando sua marca. Se você criar uma persona para o agente, como um assistente virtual ou concierge digital, deixe claro que é um chatbot e não uma pessoa real. Você pode definir o nome do agente para corresponder à persona. Um avatar é uma ótima maneira de reforçar sua imagem. Ele pode ser seu logotipo, mas um personagem gráfico no estilo de desenho animado também funciona bem.
Compartilhe o que seu agente pode fazer: uma boa mensagem de saudação deixa claro o que a conversa oferece. Ela explica os recursos do agente de forma geral. Ela também inclui respostas sugeridas e ações para orientar os usuários em caminhos específicos. Use essas sugestões para ajudar os usuários a navegar pela conversa e entender as tarefas que o agente pode ajudar.
Escrever mensagens claras e consistentes
Envie mensagens que sejam fáceis de entender e responder. Crie um texto de mensagem que solicite aos usuários que respondam. Mantenha um estilo, formato e ritmo consistentes para estabelecer confiança com os usuários.
Tenha em mente as seguintes práticas recomendadas adicionais ao criar o texto da mensagem:
Não crie becos sem saída. Cada mensagem precisa levar a uma próxima etapa significativa.
- Se a jornada do usuário tiver uma tarefa com várias etapas, use marcadores de discurso para orientar o usuário pelo processo.
Por exemplo, agora…, e…, entendi! Aqui está…
- Seja conciso, porque as respostas sugeridas e ações têm um máximo de 25 caracteres.
- Se a conversa incluir uma transferência, um reconhecimento rápido pode suavizar a transição.
Por exemplo, "Tudo bem. Seu gerente de contas vai assumir a partir daqui."
Por exemplo, "Perfeito! Acho que sei o que você está procurando." e forneça um link para seu site.
Reconheça a mensagem do usuário com uma palavra ou frase de reconhecimento.
Por exemplo, "Ótima escolha!", "OK", "Tudo bem" ou "Entendi".
Aborde o usuário diretamente usando o nome dele (se conhecido) ou o pronome "você". Evite se referir ao usuário como "eu" ou "mim", pois isso pode criar confusão.
Para títulos e rótulos, use letras minúsculas, não maiúsculas.
Por exemplo, "Extrato da conta", não "Extrato da Conta".
Use contrações, o que é apropriado mesmo para agentes com um tom sério ou elevado.
Por exemplo, "é" é mais conversacional do que "é".
Use pontos de exclamação com moderação.
Use a vírgula serial, ou seja, "A, B e C", não "A, B e C".
Escreva números como dígitos.
Por exemplo, "1, 2, 3", não "um, dois, três".
Ao usar emojis, verifique se um tom divertido se ajusta ao caso de uso.
Por exemplo, os usuários que estão reservando um caminhão de reboque ou procurando os resultados do teste de saúde podem não estar no clima.
Manter mensagens em ordem
Se você enviar várias mensagens em sequência, é importante que os usuários recebam essas mensagens em ordem. As mensagens com mídia levam mais tempo para serem processadas do que as mensagens somente de texto. Para garantir que os usuários recebam mensagens na ordem correta, aguarde até receber uma resposta 200 OK para uma mensagem antes de enviar a próxima na sequência.
Criar conversas envolventes com respostas e ações sugeridas
Respostas sugeridas e ações são ferramentas poderosas para orientar e melhorar as conversas do usuário. Elas podem seguir uma mensagem ou um Rich Card e oferecer opções para continuar ou mudar o tópico da conversa.
Respostas sugeridas: ajudam os usuários a responder rapidamente ao seu agente, oferecendo opções predefinidas. Use respostas sugeridas sempre que possível, especialmente quando respostas específicas forem esperadas.
Ações sugeridas: permitem que o agente se integre aos recursos do dispositivo, simplificando tarefas como ligar para o suporte ou encontrar locais.
Siga estas considerações importantes para criar conversas mais envolventes e eficientes:
- Relevância: verifique se as sugestões estão alinhadas com a conversa atual.
- Concisão: limite o número de sugestões para evitar sobrecarregar os usuários.
- Clareza: use uma linguagem clara e concisa para o texto da sugestão.
Ajudar o usuário
Seu agente precisa responder a mensagens de AJUDA dos usuários e informá-los sobre os recursos do agente. Uma lista de respostas sugeridas adaptadas aos recursos do agente pode transformar uma experiência ruim do usuário em uma útil.
Verificar se o logotipo e a imagem principal são exibidos corretamente
- Deixe espaço suficiente ao redor do logotipo para acomodar o corte e manter a integridade visual.
- Evite esticar ou distorcer o logotipo ou a imagem principal, pois isso pode afetar negativamente a percepção da marca.
- Teste o logotipo e a imagem principal nos modos claro e escuro para otimizar a visibilidade e a estética.
Para mais recursos que ajudem você a criar seu logotipo ou solucionar problemas, consulte as Diretrizes de design de logotipo.
Logotipo
- Crie com a renderização quadrada arredondada em mente. Os logotipos do RCS for Business são exibidos como "quadrados arredondados" na lista de conversas, na tela de conversa e nos detalhes da conversa para se alinhar aos padrões do Google e do setor.
- Centralize o logotipo na imagem para garantir que os elementos da marca permaneçam claros após o corte.
- Os agentes verificados vão apresentar automaticamente uma marca de seleção de verificação ao lado do nome do agente. Essa marca é protegida contra falsificação e não pode ser adicionada manualmente.
- Para logotipos com fundos transparentes, verifique se há contraste suficiente em fundos claros e escuros para acomodar o modo escuro. Se não tiver certeza, use um fundo branco sólido.
Imagem principal
- Use a proporção de 45:14 para evitar cortes indesejados.
Considere a sobreposição do logotipo ao criar a imagem principal para que os elementos principais não sejam obscurecidos.
Respeitar quando os usuários não querem mensagens
Manter a confiança do usuário significa respeitar as preferências de comunicação dele. Quando um usuário indica que gostaria de parar de receber mensagens, o agente precisa respeitar a escolha dele. Isso inclui entender e responder adequadamente a várias expressões de desativação, como "PARAR", em todos os idiomas relevantes.
Consulte a legislação e as práticas recomendadas do país em que você opera sobre como responder a "PARAR" e outros comandos obrigatórios.
Por exemplo, consulte as CTIA.
Processar eventos de cancelamento e inscrição
O Google Mensagens oferece recursos integrados de cancelamento e inscrição , permitindo que os usuários controlem as conversas. Quando um usuário escolhe cancelar a inscrição, o agente recebe um evento de webhook UNSUBSCRIBE. Um evento SUBSCRIBE indica a intenção de um usuário de se envolver novamente com o agente.
Para informações detalhadas sobre como processar eventos de cancelamento de inscrição e renovação de assinatura , incluindo detalhes de payload, regras de negócios e exemplos, consulte a documentação sobre eventos gerados pelo usuário.
Processar desativações
A plataforma RCS for Business não oferece uma maneira direta de gerenciar listas de desativação de usuários. Você é responsável por manter seu próprio banco de dados de usuários que optaram por parar de receber mensagens por cancelamento de inscrição ou outras formas de desativação.
Retomar conversas
Se um usuário excluir a conversa com o agente, ele precisará reiniciar o contato por outro canal, como a opção de ativação do site, o código curto de SMS ou outro mecanismo de consentimento. Essa nova interação sinaliza o interesse renovado em receber mensagens.