Antes de lanzar un agente RCS, define qué inicia cada mensaje, quién atiende respuestas y cómo funciona la baja. Google permite documentar ciertos lanzamientos con transcripciones detalladas en lugar de vídeo, pero siguen existiendo verificaciones y requisitos por red. Comprueba disponibilidad, consentimiento y comportamiento real antes de presentar el nuevo canal como listo para clientes.
¿Qué problema resuelve RCS y qué no deberías esperar de él?
Una empresa puede comunicarse con sus clientes por correo, SMS, teléfono y aplicaciones de mensajería. Cada canal promete cercanía, pero cada uno añade reglas de identificación, consentimiento, atención y seguimiento. El problema aparece cuando se adopta uno más sin decidir qué mensajes enviará, quién responderá y dónde quedará el historial. El cliente recibe una notificación bonita, pero si contesta una pregunta nadie sabe quién debe atenderla.
RCS for Business ofrece capacidades de comunicación enriquecida y agentes asociados a una marca, con funciones que dependen del entorno compatible. Puede utilizarse para experiencias transaccionales o conversacionales según el caso. No debe presentarse como disponible para todos los teléfonos, operadores y países por igual. La documentación de Google distingue redes y procesos de lanzamiento; el alcance real debe comprobarse antes de diseñar una campaña.
La decisión empresarial empieza por el propósito. Un aviso de recogida, una confirmación de una gestión o una comunicación informativa tienen necesidades diferentes de una campaña promocional. No requieren el mismo tono, las mismas opciones ni la misma intervención humana. Antes de elegir canal, escribe qué debe entender el destinatario, qué acción puede realizar y qué ocurrirá si responde con una duda que el sistema no sabe resolver.
No es recomendable utilizar RCS como excusa para aumentar el volumen de mensajes. Una comunicación útil reduce incertidumbre; una repetitiva crea ruido. Si el negocio ya envía avisos claros por un canal que funciona, el nuevo sistema debe aportar una mejora concreta y verificable, no una promesa genérica de más conversiones. No hay datos propios de meiika que permitan atribuir resultados comerciales a una implantación de este tipo.
¿Qué cambió el 7 de octubre de 2026 en el lanzamiento de agentes?
Google actualizó sus notas de RCS for Business el 7 de octubre de 2026: para lanzamientos gestionados por Google, el vídeo de vista previa del agente dejó de ser obligatorio cuando se aporta una descripción exhaustiva de los flujos mediante transcripciones paso a paso. El formulario debe explicar qué desencadena cada mensaje, cómo se desarrolla la interacción y cómo funciona la baja. Los requisitos de redes gestionadas directamente por operadores pueden ser diferentes.
La novedad no elimina la necesidad de probar el agente ni de presentar la información de marca. La guía oficial de lanzamiento describe la verificación por una persona autorizada y la aprobación del agente en las redes seleccionadas. También establece que la experiencia debe estar lista para revisión, con una política de privacidad, términos de servicio y mecanismos de cancelación cuando proceda. No confundas una mejora documental con un permiso automático para enviar mensajes.
Una transcripción útil no es una lista de frases de marketing. Debe mostrar un recorrido real: qué evento inicia la comunicación, qué recibe el cliente, qué opciones tiene, qué ocurre si elige una y cómo se sale del flujo. Si hay intervención humana, debe quedar claro en qué momento se produce. Si la respuesta es desconocida, el agente no debería inventar una solución. La documentación ha de describir el comportamiento que realmente se ha implementado.
El proceso de lanzamiento también distingue entre redes gestionadas por Google y por operadores. La guía oficial señala requisitos adicionales en ciertos casos y condiciones de despliegue por país. Por eso no prometas una fecha de activación sin haber comprobado la red, los acuerdos necesarios y el estado de aprobación. Una herramienta puede estar terminada técnicamente y seguir sin poder operar en el entorno previsto.
¿Cómo diseñar un flujo que ayude al cliente y al equipo?
Empieza con un caso de uso estrecho. Por ejemplo, un aviso transaccional que informa de un cambio de estado y ofrece una vía clara para resolver dudas. Describe el dato que dispara el mensaje, de dónde procede y cómo se evita enviarlo dos veces. Si el estado cambia de nuevo, decide si se envía otra notificación o si la primera deja de ser pertinente. Esas reglas importan más que el aspecto visual de una tarjeta.
Diseña el mensaje para que pueda entenderse sin elementos decorativos. El destinatario debe reconocer quién escribe, por qué lo hace y qué acción se espera. Si se incluyen botones o respuestas sugeridas, prueba también qué sucede cuando la persona escribe algo distinto. Los recorridos reales rara vez siguen un guion perfecto. Un sistema que solo funciona con las respuestas previstas necesita una salida clara hacia soporte.
La integración con el negocio es otra pieza fundamental. Si un cliente responde sobre un pedido, el equipo debe saber dónde consultar la información y qué datos puede modificar. No copies indiscriminadamente conversaciones a múltiples herramientas. Define una fuente de verdad para el estado del caso y reglas de acceso según el trabajo de cada persona. Un canal nuevo no debería convertirse en una base de datos paralela que nadie mantiene.
Antes de enviar, valida las condiciones de contacto. La posibilidad técnica de alcanzar un número no equivale a tener autorización para cualquier finalidad. Diferencia comunicaciones necesarias para prestar un servicio de mensajes promocionales y consulta la normativa aplicable y las preferencias registradas. Si una persona se ha dado de baja, el sistema debe respetarlo en todos los puntos desde los que se pudiera activar un envío.
¿Por qué la baja y las respuestas imprevistas deben probarse primero?
Las buenas prácticas de Google y su guía de aprobación exigen una baja verificable con STOP y confirmación. No basta con añadir una frase al final del flujo. Debe existir un comportamiento comprobable: cuando el usuario solicita dejar de recibir comunicaciones, el sistema registra la preferencia y, tras la confirmación, el agente no envía más mensajes salvo que la persona vuelva a dar su consentimiento.
Prueba variaciones razonables de la solicitud de baja y asegúrate de que el equipo puede consultar el estado sin acceder a más datos de los necesarios. No anuncies que se ha cancelado una suscripción si el sistema todavía no ha confirmado el cambio. Tampoco conviertas una baja de mensajes promocionales en la cancelación automática de un servicio contratado. Son acciones diferentes que requieren reglas explícitas.
Las respuestas inesperadas merecen la misma atención. Si el usuario escribe una queja, envía un mensaje fuera de contexto o pide hablar con una persona, el agente debe reconocer sus límites. No prometas disponibilidad humana inmediata si no existe. Si el canal solo admite un caso transaccional, explica de manera clara qué vía alternativa puede utilizar. Un flujo responsable no trata de retener a alguien a toda costa dentro de la automatización.
Incluye escenarios de fallo: mensaje no entregado, estado de pedido desconocido, evento repetido y consulta fuera del horario de atención. Define qué se registra y cómo se evita generar comunicaciones contradictorias. Si una integración falla, una persona responsable debe poder identificar el problema sin revisar conversaciones una a una. La supervisión es parte del servicio, no una tarea opcional posterior al lanzamiento.
¿Qué comprobar antes de invertir en un nuevo canal de mensajería?
Verifica primero la disponibilidad del servicio en las redes y países que te interesan, la compatibilidad de dispositivos, el tipo de agente y las condiciones del proveedor. La documentación oficial es una referencia, pero las capacidades efectivas dependen del despliegue. No extrapoles un ejemplo de otro país a tu base de clientes en España. Tampoco presentes precios o ratios de apertura sin una propuesta y una medición propias.
Después, comprueba el proceso interno. ¿Quién prepara los mensajes? ¿Quién aprueba cambios de texto? ¿Dónde se conserva la preferencia de baja? ¿Qué ocurre cuando una persona responde? ¿Quién revisa los fallos? Si no puedes contestar estas preguntas, todavía no necesitas más automatización: necesitas definir responsabilidades.
Un piloto prudente puede centrarse en un flujo autorizado, con pruebas controladas y criterios de aceptación claros. Evalúa si los mensajes llegan, si se interpretan correctamente las respuestas y si soporte puede continuar la conversación cuando es necesario. No conviertas el piloto en una campaña comercial sin haber validado consentimiento, políticas y experiencia. Documenta las limitaciones detectadas antes de ampliar el alcance.
| Ensayo | Qué comprobar | Resultado insuficiente |
|---|---|---|
| Inicio | Evento autorizado y pertinente | El número existe |
| Respuesta libre | Salida clara hacia soporte | Solo admite botones |
| Baja | Confirmación y bloqueo de envíos | Solo cambia un texto |
| Error | Incidencia asignada | Nadie consulta el registro |
Cómo lo hemos abordado en meiika
En meiika estudiamos agentes de autogestión con límites, datos concretos y vías de intervención humana. Un canal nuevo necesita responsables y decisiones comprensibles antes de añadir automatización.
Los sistemas a medida pueden conectar estado del caso y preferencias sin crear otra base paralela. Aquí no presentamos un agente RCS lanzado ni resultados comerciales: describimos cómo estudiar un recorrido antes de proponerlo.
Este artículo ofrece información general, no asesoramiento jurídico/profesional. Las condiciones aplicables deben revisarse según el país, la organización y el uso previsto.