Cuando interactúas con los usuarios a través de los agentes de Business Messages, ten en cuenta las siguientes prácticas recomendadas.
No proporciones ni solicites información sensible.
Evitar el contenido sensible durante los chats mantiene tu información y la de tus clientes. La información confidencial incluye, pero no se limita a lo siguiente:
- Números de tarjetas de crédito
- Números de seguridad social, pasaporte y otros números de identificación del gobierno
- Credenciales de acceso, como contraseñas
Responde a los usuarios rápidamente
Los tiempos de respuesta lentos o injustificados para los mensajes del usuario crean una mala experiencia para tus clientes. Asegúrate de diseñar tu infraestructura de respuesta para proporcionar respuestas oportunas a los mensajes de los usuarios de manera coherente.
Lo peor de todo es que una respuesta lenta no es una respuesta en absoluto. Asegúrate de que los usuarios siempre reciban respuestas a sus mensajes, sin importar la carga de mensajes. Por ejemplo, si el personal en vivo no está disponible, envía un mensaje automático para confirmar su recepción e incluye una estimación de cuándo podría esperar una respuesta completa.
Google mide el tiempo de respuesta (TTR) entre mensajes. Si el agente de una marca tarda en responder a los consumidores, Google quitará los botones de mensajes de la marca.
Cuando la automatización no pueda cumplir con las solicitudes, entrégale el trabajo a personas
Los usuarios se frustran cuando la automatización no responde de forma apropiada. Es por eso que todos los agentes que se inician desde los puntos de entrada administrados por Google (excepto el punto de entrada de Google Ads) deben tener representantes humanos que puedan manejar las conversaciones cuando no sea posible la automatización. Antes del lanzamiento, debes establecer tu tipo de interacción con el agente para incluir a los representantes humanos.
Cuando la automatización no puede cumplir con la solicitud de un usuario dos veces seguidas, es mejor enviar un mensaje con una sugerencia de solicitud de agente en vivo.
Cuando un usuario presiona esta sugerencia, tu agente recibe un evento en vivo que solicitó el agente. Tu agente debe responder transfiriendo la conversación a un representante humano, para que el usuario obtenga la ayuda que necesita.
No es necesario que las personas estén disponibles las 24 horas, todos los días. Configura la disponibilidad del agente para que los usuarios sepan cuándo pueden esperar una respuesta humana.
Autentica usuarios con OAuth
Para verificar las identidades de los usuarios y proporcionarles información personalizada, autentícate con sistemas de backend a través de OAuth. La autenticación con OAuth permite que los agentes accedan a los datos del usuario con rapidez y evita que los usuarios o agentes incluyan información sensible (como nombres de usuario o contraseñas) en la conversación. Consulta Autentica con OAuth.
Mide la satisfacción del cliente dentro de Business Messages
Business Messages mide las puntuaciones de satisfacción del cliente (CSAT) mediante encuestas directamente en las experiencias de mensajería. Para evitar que los usuarios reciban varias encuestas, utiliza la función de encuestas de Business Messages. No implementes tus propias técnicas de medición de Satisfacción del cliente (CSAT).
Concéntrate en el tema.
No envíe mensajes no deseados o irrelevantes a la conversación actual. Por ejemplo:
- Mensajes sobre un producto o servicio no relacionado con la solicitud original
- Mensajes repetidos sin respuesta del usuario
- Mensajes demasiado largos o uso excesivo de emojis y URL
Aprovecha el ID de lugar cuando esté disponible
Para los puntos de entrada basados en la ubicación, los mensajes pueden contener un placeId en la carga útil del contexto. Puedes aprovecharla para proporcionar información sobre la que el usuario solicita información, como el inventario en una ubicación específica. Un objeto placeId identifica de forma única un lugar en la base de datos de Google Places y en Google Maps Platform.
Incluso si solo lanzas puntos de entrada basados en la ubicación, asegúrate de implementar una estrategia en situaciones en las que no esté presente un placeId. Aunque no es común, hay circunstancias en las que un placeId, entre otros datos contextuales, no se pasa a tu webhook.
Implementa reintentos con retirada exponencial
Cuando se llama a cualquier API, es posible que la llamada falle debido a problemas de infraestructura, sobrecarga del servicio, límites de QPS y otros errores. Para realizar correctamente la recuperación ante llamadas a la API con errores, implementa los reintentos con retirada exponencial.
Mediante los reintentos con retirada exponencial, la infraestructura se configura automáticamente.
- Identifica una llamada de API fallida
- Establece la duración de la espera inicial y la cantidad máxima de reintentos.
- Pausas durante el tiempo de espera
- Reintenta la llamada a la API
Evalúa la respuesta a la llamada a la API:
- Si se realiza de forma correcta, se continúa con el paso siguiente del flujo de trabajo.
- Si falla, aumenta la duración de la espera y vuelve al paso 3.
- Si ocurre un error después de la cantidad máxima de reintentos, ingresa un estado de error.
Las duraciones de espera ideales y la cantidad máxima ideal de reintentos varían según el caso práctico. Determina estos números según los requisitos de latencia de tu infraestructura y flujos de trabajo.
Verifica si hay mensajes entrantes duplicados
Cuando revises y respondas los mensajes entrantes de los usuarios, revisa el messageId y verifica que aún no hayas recibido ni respondido el mensaje con anterioridad.
Con los sistemas distribuidos, hay dos formas de enviar mensajes: como máximo una vez y, al menos, una vez. Con los sistemas "como máximo una vez", el sistema envía un mensaje una vez, pero si hay errores de red o comunicación en el camino, es posible que el mensaje no se reciba. Con los sistemas "al menos una vez", el sistema puede enviar un mensaje varias veces, pero este puede recibirse incluso cuando hay errores de red o de comunicación.
Business Messages usa el sistema "al menos una vez". Si bien esto puede provocar mensajes duplicados de mensajes entrantes, es sencillo anular los mensajes duplicados mediante el seguimiento de las strings messageId. Si ya recibiste un mensaje, es seguro ignorar cualquier mensaje adicional que recibas con el mismo messageId.