# Enviar mensajes Cómo funciona el paso Enviar mensaje: canal, remitente, la política de consentimiento que exige cada mensaje y qué pasa cuando no se puede enviar. **Language:** es **Audience:** platform **TLDR:** El paso Enviar mensaje envía un SMS, o un RCS con fallback a SMS, y el flow continúa al instante. Cada mensaje tiene su propia política de consentimiento: por defecto Basic (o la del proyecto para el canal), que llega a todos los contactos dados de alta aunque hayan rechazado el marketing; para respetar ese rechazo, selecciona Sin opt-out u Opt-in, o añade un paso Según consentimiento. Si un mensaje no se puede enviar, la ejecución se detiene ahí salvo que desactives esa opción. **Translation key:** platform.automations.flows.sending-messages **Search keywords:** enviar SMS, enviar RCS, fallback, SMS Fallback, remitente, Basic, Sin opt-out, Opt-in, consentimiento de marketing, le llegó aunque dijo que no, recibió publicidad sin aceptarla, detener la ejecución, mensaje no enviado, variables, variables del evento, personalización, horario silencioso, flujo, respondió STOP durante el flow **Related pages:** /platform/en/automations/flows/sending-messages, /platform/es/automations/flows, /platform/es/automations/flows/waits, /platform/es/automations/flows/branches, /platform/es/campaigns/compliance-policies, /platform/es/channels/rcs/sms-fallback, /platform/es/consent **Docs index (every page):** https://staging-instasent-docs-nextjs.oscar-284.workers.dev/llms.txt **This zone's index:** https://staging-instasent-docs-nextjs.oscar-284.workers.dev/platform/es/llms.txt **This page:** https://staging-instasent-docs-nextjs.oscar-284.workers.dev/platform/es/automations/flows/sending-messages/ (HTML) · https://staging-instasent-docs-nextjs.oscar-284.workers.dev/platform/es/automations/flows/sending-messages.md (Markdown) **Other language (en):** https://staging-instasent-docs-nextjs.oscar-284.workers.dev/platform/en/automations/flows/sending-messages.md El paso **Enviar mensaje** es el momento en que un flow se comunica con el contacto: cuando un contacto llega a él, se le envía un mensaje —un SMS, o un RCS con fallback a SMS— y el contacto pasa directamente al paso siguiente. El paso no espera a saber si el mensaje se entregó, se leyó o recibió un clic, y no tiene salidas de «éxito» ni de «fallo». Para que el flow reaccione a lo que ha pasado se añade una espera detrás: una **Espera de entrega** bifurca según si el mensaje llegó, y una **Espera de actividad** espera un clic, un toque o una respuesta (ver [Esperas](/platform/es/automations/flows/waits)). Cada paso Enviar mensaje reúne todo lo que tiene que ver con su mensaje: el canal, el remitente, el texto en cada idioma y dos ajustes que deciden **quién lo recibe de verdad** y **qué le pasa al contacto cuando no se le puede enviar**. Esos dos ajustes son lo que más sorprende de un flow, así que cada uno tiene su propia sección más abajo. ## Añadir un mensaje Los mensajes se añaden desde la paleta de pasos, que se abre desde cualquier **+** del lienzo (ver [Crear un flow](/platform/es/automations/flows/building-a-flow)). El grupo **Enviar** ofrece dos opciones: - **Enviar SMS** — un mensaje de texto. Lo recibe cualquier teléfono. - **Enviar RCS** — un mensaje con tu marca, con envío alternativo por SMS si no se puede entregar. Solo aparece cuando RCS está disponible en tu proyecto; consulta [Qué es RCS](/platform/es/channels/rcs/what-is-rcs). En el lienzo, las dos se convierten en un paso **Enviar mensaje**, que muestra su canal y el comienzo del texto. El canal queda fijado al añadir el paso: para convertir un SMS en un RCS, o al revés, es necesario eliminar el paso y añadir el otro en su lugar. Al pulsar el paso, su mensaje se abre en **Editar mensaje**; la flecha junto a ese título te devuelve al editor de flows. Encima y debajo del mensaje, unas etiquetas atenuadas nombran los pasos que lo rodean, y **Fin de la rama** marca dónde termina su rama. En el centro está el mensaje, con una tarjeta por canal: un paso RCS muestra su tarjeta de RCS y, debajo, la del SMS fallback. A la derecha, una pestaña de vista previa por canal muestra el mensaje en un teléfono, y la pestaña **Avanzado** reúne los ajustes del paso. ![El editor de mensaje de un paso Enviar mensaje con remitente, texto y vista previa](/platform/es/automations/flows/images/sending-messages--1-message-editor.png) *El mensaje del paso se edita en su propio editor.* ### Remitente Cada tarjeta de canal empieza por su propio selector de **remitente**. En un flow, el remitente pertenece al paso —y a cada canal del paso—, no al flow entero, así que dos mensajes del mismo flow pueden enviarse desde remitentes distintos. La primera vez que se abre un paso, el remitente ya viene seleccionado: el que usan los demás mensajes del flow en ese canal o, si no hay ninguno, el remitente por defecto del proyecto para el canal. Conviene revisarlo antes de publicar. Si el proyecto todavía no tiene ningún remitente de ese canal, el selector queda vacío y permite crear uno. ### Texto, idiomas y variables El mensaje se redacta en el editor de mensajes: el texto, atributos como el nombre, enlaces, el enlace de baja, emojis, herramientas de redacción con IA y, en RCS, acciones rápidas. Puedes añadir una versión del texto por **idioma**: cada contacto recibe la de su idioma y el resto recibe el texto por defecto. Las herramientas del editor se describen con más detalle en [Crear una campaña › Mensaje](/platform/es/campaigns/creating-a-campaign#2-mensaje). Hay algo propio de los flows: las **variables del evento**. Como un contacto entra en un flow cuando ocurre un evento, el mensaje puede citar los datos de ese evento. La barra del editor muestra un botón con el nombre del evento disparador (por ejemplo **Pedido creado**) que inserta sus parámetros, como `{{_event.order-id}}` para el número de pedido. El mensaje de cada contacto se rellena con los datos del evento que inició *su* ejecución, así que dos contactos que entraron con pedidos distintos reciben cada uno su número de pedido. > **Warning**: Si el evento disparador llega sin un parámetro que usa una variable, la variable sale > vacía y el mensaje se envía igualmente, con un hueco donde iba el dato. Para evitarlo, > pon a la variable un **Valor por defecto** en sus opciones: se usa siempre que el > parámetro del evento venga vacío. ### Vista previa y prueba La pestaña de vista previa de cada canal muestra el mensaje en un teléfono Android o iOS, para el país que selecciones, con el coste estimado de un mensaje. Desde ahí puedes enviarte una prueba para revisar el texto, la personalización y los enlaces en un dispositivo real. Para probar el flow completo con un contacto —esperas y ramas incluidas— se usa el test del flow (ver [Probar, publicar y versiones](/platform/es/automations/flows/versions-and-publishing#probar-con-un-contacto)). ### Cuando el paso requiere atención Un mensaje necesita **remitente y texto** en cada canal que usa. Mientras falte alguno, la tarjeta indica **Este mensaje necesita un remitente y un texto**, y al guardar desde el editor tu trabajo se conserva con un aviso: **Guardado. Este mensaje todavía está incompleto: necesita remitente y texto.** El paso aparece entonces marcado con **Requiere atención** en el lienzo y en la lista **Corrige tu flow para publicarlo**, con una línea por cada canal incompleto: un paso RCS con la tarjeta de RCS y la del SMS fallback vacías suma dos. Un borrador así se puede guardar, pero no publicar hasta completarlo (ver [Crear un flow](/platform/es/automations/flows/building-a-flow#corrige-lo-que-impide-publicar)). Un SMS fallback desactivado no necesita texto. Dentro de **Editar mensaje** está **Guardar cambios**, pero no hay botón para descartar: para deshacer lo editado, vuelve al editor de flows y usa **Descartar** allí. ## RCS con SMS fallback Un mensaje RCS llega al contacto con tu marca, pero no todos los teléfonos pueden recibir RCS. Por eso un paso **Enviar RCS** se crea con el **SMS fallback** ya activado: el plan B automático para que los contactos a los que RCS no llega reciban el mensaje como SMS. En el editor, la tarjeta de RCS y la de SMS están unidas por el conector **Si RCS no se puede entregar**, que lleva un interruptor. Déjalo activado para mantener el fallback, o desactívalo si este mensaje solo debe enviarse por RCS. En el panel, la tarjeta del SMS lleva la etiqueta **alternativa** y tiene su propio remitente y su propio texto. Ese texto empieza siendo una copia del texto RCS y lo sigue mientras no lo modifiques; a partir de ese momento es tuyo, y los cambios posteriores en el RCS no lo sobrescriben. El fallback puede entrar en juego en dos momentos: ```mermaid flowchart TD A["El contacto llega a un paso Enviar RCS"] --> Q1{"¿Se le puede enviar RCS?"} Q1 -->|No| S1["Se envía el SMS fallback en su lugar"] Q1 -->|Sí| R["Se envía el RCS"] R --> Q2{"¿Se entrega el RCS?"} Q2 -->|Sí| OK["Entregado por RCS"] Q2 -->|No| S2["Se envía el SMS fallback"] class OK success ``` - **Al enviar.** Si no se le puede enviar RCS a este contacto —se sabe que su teléfono no admite RCS, o tu remitente RCS no está disponible en su país—, se envía el SMS en su lugar. A los contactos de cuyo teléfono aún no se sabe si admite RCS se les envía primero el RCS. - **Después de enviar.** Si el RCS se envía pero no se entrega, se envía el SMS fallback, igual que en las campañas. El flow no espera a ninguno de los dos momentos: el contacto ya ha pasado al paso siguiente. Si necesitas saber por qué canal se entregó finalmente el mensaje, una **Espera de entrega** colocada detrás del paso decide sobre el mensaje que se envió de verdad y puede separar por canal de entrega (ver [Esperas](/platform/es/automations/flows/waits#espera-de-entrega)). En el recorrido del contacto, un mensaje que pasó al fallback indica que se envió por SMS porque los canales anteriores no pudieron entregarlo. La política de consentimiento que se explica a continuación se aplica al mensaje entero: el RCS y su SMS fallback siguen la misma política, y RCS usa el consentimiento SMS del contacto (ver [Consentimiento compartido (RCS y SMS)](/platform/es/consent/rcs-sms-shared-consent)). Cómo funciona el fallback como función del canal se explica en [SMS Fallback](/platform/es/channels/rcs/sms-fallback). ## Quién lo recibe: la política de consentimiento > **Warning**: Por defecto, un mensaje de un flow usa la política **Basic**: llega a todos los > contactos dados de alta e ignora la preferencia de marketing. Un contacto que dijo que > no al marketing pero no está suprimido en el canal **lo recibe**. Si el mensaje es de > marketing, cambia la política o añade un paso **Según consentimiento** antes, como se > explica más abajo. Cada paso Enviar mensaje tiene su propia **Política de consentimiento**: el consentimiento que exige ese mensaje. Cuando un contacto llega al paso, Instasent lo comprueba frente a esa política en ese mismo momento; a un contacto que no la cumple no se le envía el mensaje, y el flow reacciona según el otro ajuste del paso (ver [Cuando un mensaje no se puede enviar](#cuando-un-mensaje-no-se-puede-enviar)). La política está en la pestaña **Avanzado** de **Editar mensaje** y ofrece tres opciones, que el panel describe así: | Política | Qué dice el panel | | --------------- | -------------------------------------------------------------------------------- | | **Basic** | Envía a todos los contactos dados de alta e ignora las preferencias de marketing | | **Sin opt-out** | Excluye contactos que rechazaron marketing | | **Opt-in** | Solo contactos que aceptaron marketing explícitamente | Con ninguna de las tres se envía el mensaje a un contacto **suprimido** en el canal —es decir, bloqueado para todos los envíos de ese canal—. Un contacto que rechazó el marketing pero no está suprimido sigue contando como dado de alta, así que un mensaje en Basic le llega. A qué contactos llega exactamente cada política —incluidos los que no tienen ninguna preferencia de marketing registrada— se explica en [Políticas de cumplimiento](/platform/es/campaigns/compliance-policies); las reglas son las mismas para campañas y flows. ![La pestaña Avanzado de un mensaje con las opciones de política de consentimiento](/platform/es/automations/flows/images/sending-messages--2-advanced-tab.png) *Basic viene seleccionada salvo que tu proyecto tenga otra por defecto.* **Con qué política empieza un mensaje nuevo.** Un paso nuevo empieza con la política por defecto de tu proyecto para ese canal, si hay una configurada (ver [Cumplimiento](/platform/es/channels/compliance-defaults)), y si no, con **Basic**. De fábrica ningún canal tiene una configurada, así que en la mayoría de los proyectos cada mensaje nuevo empieza en Basic. Las plantillas de flows fijan la política de cada mensaje que crean, así que conviene revisarla también ahí (ver [Plantillas de flows](/platform/es/automations/flows/templates)). **Dos formas de respetar el «no» de un contacto al marketing:** - **Cambiar la política del mensaje** a **Sin opt-out** u **Opt-in**. A los contactos que no la cumplen no se les envía este mensaje. - **Repartirlos antes con un paso Según consentimiento.** Separa a los contactos en **Con consentimiento** y **Sin consentimiento** con las mismas reglas, de modo que quienes no la cumplen pueden seguir otro camino: una etiqueta, otro mensaje o el final del flow (ver [Ramas › Por consentimiento](/platform/es/automations/flows/branches#por-consentimiento)). Según consentimiento empieza en **Opt-in**, mientras que un mensaje empieza en Basic: son ajustes independientes, y el mensaje sigue aplicando su propia política. El consentimiento se comprueba siempre al enviar el mensaje, haya o no un paso Según consentimiento antes, pero se comprueba frente a la política **del mensaje**. Un flow sin paso Según consentimiento y con los mensajes en Basic envía a los contactos que rechazaron el marketing. Una vez enviado un mensaje, su política aparece en los detalles del mensaje: en el recorrido del contacto, **Ver el mensaje** los abre (ver [Seguimiento de un flow](/platform/es/automations/flows/monitoring-a-flow#el-recorrido-del-contacto)). ### Si el contacto se da de baja durante el flow El consentimiento se vuelve a comprobar en cada paso Enviar mensaje, así que si un contacto responde **STOP** o usa un enlace de baja mientras está dentro del flow, eso vale para los mensajes que vienen después. Lo que bloquea la baja depende de la política del mensaje desde el que se dio de baja, con las mismas reglas que en las campañas (ver [Políticas de cumplimiento › Qué pasa cuando alguien se da de baja](/platform/es/campaigns/compliance-policies#qué-pasa-cuando-alguien-se-da-de-baja)): - **Desde un mensaje Basic**, el contacto queda suprimido en el canal: no se le envía ningún mensaje posterior del flow, tenga la política que tenga. - **Desde un mensaje Sin opt-out u Opt-in**, queda registrado que rechaza el marketing: los mensajes posteriores Sin opt-out y Opt-in no se le envían, pero un mensaje **Basic** posterior sí le llega. Un mensaje que no se envía por este motivo sigue el interruptor **Detener la ejecución si no se puede enviar el mensaje** del paso: activado, la ejecución termina ahí como **Detenida**; desactivado, el contacto continúa sin él (ver [Cuando un mensaje no se puede enviar](#cuando-un-mensaje-no-se-puede-enviar)). Para terminar la ejecución en cuanto alguien se da de baja, añade **Baja del contacto** como evento de salida, sin marcarlo como objetivo (ver [Objetivos y salidas › Eventos de salida](/platform/es/automations/flows/goals-and-exits#eventos-de-salida)). ### Ejemplo: una oferta de primavera Una tienda crea un flow llamado *Oferta de primavera*: cuando un contacto ve un producto (**Producto visto**), se le envía un SMS con un descuento. Laura rechazó los SMS de marketing en las preferencias de su cuenta, pero nunca se dio de baja. - **El SMS se deja como se creó, en Basic.** Laura ve un producto y **recibe la oferta**. No ha fallado nada: Basic ignora la preferencia de marketing. - **El SMS se cambia a Opt-in.** A Laura no se le envía la oferta. Con **Detener la ejecución si no se puede enviar el mensaje** activado, como viene por defecto, su ejecución termina en ese paso con el estado **Detenida**, y su recorrido indica que el mensaje no se envió porque no cumple la política de consentimiento del canal. - **Un paso Según consentimiento (Opt-in) va antes del SMS.** Laura sigue por **Sin consentimiento**, donde un paso **Actualizar etiquetas** le añade la etiqueta `sin-consentimiento-marketing`. No recibe nada, su ejecución termina con normalidad, y los contactos que aceptaron el marketing siguen por **Con consentimiento** hasta la oferta. #### ¿Por qué le llegó el mensaje a un contacto que rechazó el marketing? Porque el mensaje usaba la política **Basic**, que es la que viene por defecto: llega a todos los contactos dados de alta e ignora la preferencia de marketing. En el recorrido del contacto, **Ver el mensaje** muestra la política que usó el mensaje. Para evitarlo, cambia el mensaje a **Sin opt-out** u **Opt-in** en **Avanzado**, o añade un paso **Según consentimiento** antes. Los contactos que ya están dentro del flow siguen en la versión con la que entraron; el cambio se aplica cuando lo publicas. ## Cuando un mensaje no se puede enviar A veces un mensaje no se puede enviar a un contacto de ninguna forma: no cumple la política de consentimiento, ningún canal puede llegar a él (por ejemplo, no tiene móvil), el remitente no está disponible para su país o el mensaje no está configurado del todo. Lo que pasa después depende del interruptor **Detener la ejecución si no se puede enviar el mensaje**, en la pestaña **Avanzado**: - **Activado (por defecto).** La ejecución del contacto se detiene en este paso, con el estado **Detenida**. No recibe nada más de esta ejecución del flow. - **Desactivado.** El contacto continúa al paso siguiente sin el mensaje, y el paso registra por qué no se envió. En los dos casos, el recorrido del contacto muestra el motivo por el que no se envió el mensaje; la lista completa de motivos está en [Seguimiento de un flow › Por qué no se envió un mensaje](/platform/es/automations/flows/monitoring-a-flow#por-qué-no-se-envió-un-mensaje). Conviene desactivarlo cuando el resto del flow sigue teniendo sentido sin el mensaje; por ejemplo, un paso **Actualizar etiquetas** al final que debe ejecutarse para todos. Con el interruptor desactivado, una **Espera de entrega** colocada detrás del mensaje puede además llevar por su propio camino a los contactos a los que no se pudo enviar, con su salida opcional **No se pudo enviar** (ver [Esperas › Espera de entrega](/platform/es/automations/flows/waits#espera-de-entrega)). Si lo que se busca es separar *antes de intentarlo* a los contactos a los que un canal no llega, un paso **Según alcance** los reparte según si SMS o RCS puede llegar a ellos (ver [Ramas › Por alcance del canal](/platform/es/automations/flows/branches#por-alcance-del-canal)). ## Momento del envío Un paso Enviar mensaje no tiene ventana de envío ni horario silencioso propios y envía en cuanto el contacto llega a él, a cualquier hora; para enviar solo en horas adecuadas, se coloca justo antes una **Espera por zona horaria** o una **Espera inteligente** (ver [Esperas › Los mensajes no tienen horario silencioso](/platform/es/automations/flows/waits#los-mensajes-no-tienen-horario-silencioso)). ## Qué se factura Cada mensaje que envía un flow se cobra como cualquier otro SMS o RCS, al precio de tu cuenta para ese canal y destino; la vista previa muestra el coste estimado por mensaje. El flow en sí, sus esperas, ramas, actualizaciones del contacto y objetivos no añaden ningún cargo. Cuando un RCS recurre al SMS fallback, el intento por RCS no se cobra y el SMS se factura con las condiciones de SMS; consulta [SMS Fallback › Qué se factura](/platform/es/channels/rcs/sms-fallback#qué-se-factura). Los mensajes se pagan con tu saldo (ver [Saldo](/platform/es/billing/wallet-balance)). ## Temas relacionados - [Esperas](/platform/es/automations/flows/waits) - Reacciona a la entrega, los clics y las respuestas, y envía en el momento adecuado. - [Ramas](/platform/es/automations/flows/branches) - Comprueba el consentimiento y el alcance antes de enviar. - [Políticas de cumplimiento](/platform/es/campaigns/compliance-policies) - A quién llega cada política de consentimiento. - [Consentimiento y suscripciones](/platform/es/consent) - Preferencia de marketing, bajas y supresión. --- This is one page of the Instasent documentation. For the complete machine-readable index of every guide and API reference, fetch https://staging-instasent-docs-nextjs.oscar-284.workers.dev/llms.txt — start there for full context.