«Responde a este correo» es un compromiso con lo que ocurre tras el envío. Una migración puede mantener intacto el diseño de una plantilla y, aun así, romper esa promesa si cambia la dirección, la ruta entrante o el flujo de soporte.
Revisa en Migma la llamada a responder como parte del diseño y valida con los responsables de envío y soporte dónde aterriza realmente esa contestación. Al migrar de Mailgun a Loops, la entrega saliente y la recepción entrante exigen decisiones independientes.
Esta guía está publicada por Migma. Se centra en el texto visible para el destinatario y en la validación de la ruta de respuesta, no en una receta integral de infraestructura ni en una comparativa independiente de proveedores. Las páginas oficiales de producto se consultaron el 16 de octubre de 2026.
Rastrea la ruta de respuesta antes de redactar el texto
Identifica todos los correos activos que inviten a contestar. No te limites a los mensajes con un botón de respuesta destacado: una despedida cercana, una pregunta de encuesta o una frase de ayuda generan la misma expectativa.
Para cada plantilla, pide al responsable que confirme la dirección Reply-To configurada y qué ocurre exactamente detrás. Una respuesta puede llegar a un buzón atendido, convertirse en un ticket del centro de ayuda o procesarse directamente en la aplicación. Son flujos totalmente distintos, aunque el usuario vea la misma dirección.
La página de enrutamiento entrante de Mailgun explica cómo procesar y redirigir mensajes recibidos, incluidas las respuestas que alimentan una aplicación o un ticket de soporte. Esta función es independiente de la capacidad de enviar correos salientes.
Define el alcance real de la migración
La guía de migración desde Mailgun de Loops señala que Loops no cuenta con un equivalente para las rutas de Mailgun (Mailgun Routes). Por ello, recomienda mantener Mailgun u otro proveedor entrante para gestionar esas vías mientras sigan activas.
Esto no impide migrar el envío saliente, pero deja claro que «trasladar las plantillas» y «sustituir el flujo de respuesta» son tareas distintas. No desactives una ruta entrante solo porque la nueva plantilla saliente haya superado una prueba.
El flujo de exportación de Migma facilita el diseño revisado y la entrega del HTML, pero no migra de forma automática las rutas de Mailgun, no configura buzones de soporte ni establece una conexión nativa con Loops. Asegúrate de que estas responsabilidades queden bien reflejadas en el plan de trabajo.
Adapta el mensaje al canal de respuesta real
Redacta el cierre en Migma solo cuando el responsable del flujo confirme el comportamiento admitido. Estos ejemplos ilustran tres compromisos distintos:
Un buzón atendido por el equipo
«Si necesitas ayuda para elegir, responde a este correo y nuestro equipo lo revisará». Utiliza esta opción únicamente si el mensaje llega a un equipo asignado a esa gestión. No inventes plazos de respuesta para que el texto parezca más tranquilizador.
Un formulario de soporte con el contexto necesario
«¿Necesitas ayuda con este pedido? Entra en la página de soporte e indica tu número de referencia». Enlaza a una página verificada e indica qué datos necesita el equipo. Si las respuestas al correo no se monitorizan, evita incluir cualquier otra llamada a responder en el resto del mensaje.
Una respuesta que actualiza la aplicación
«Puedes responder directamente para añadir un comentario a esta conversación». Esta frase promete una acción dentro del producto. Pide al equipo técnico que demuestre cómo se asocia el mensaje a la conversación correcta y si los adjuntos o el texto citado se procesan según lo previsto.
Estas propuestas son sugerencias de redacción, no afirmaciones sobre tu infraestructura. Elige la que encaje con la ruta validada o redacta un cierre propio a partir de hechos confirmados.
Valida el circuito completo desde el correo final
Ejecuta Migma Email Preflight para revisar el diseño, los enlaces y la visualización en la bandeja de entrada. A continuación, pide al responsable de la integración que envíe una prueba controlada desde la plataforma definitiva a través del canal de salida real.
Responde directamente al correo recibido en lugar de escribir la dirección a mano en un mensaje nuevo. Este test de ida y vuelta debe confirmar que las cabeceras finales, la dirección y la ruta funcionan de forma conjunta.
Utiliza una tabla de validación como esta:
| Comprobación | Evidencia que se debe conservar |
|---|---|
| Mensaje saliente | Remitente definitivo y Reply-To del correo de prueba recibido |
| Respuesta | Respuesta controlada con contenido representativo y seguro |
| Destino | Buzón correcto, ticket o conversación dentro de la aplicación |
| Responsable | Persona designada para dar seguimiento |
| Gestión de errores | Lo que ve el equipo si el enrutamiento o el procesamiento fallan |
No incluyas conversaciones reales de clientes ni credenciales privadas en un registro de diseño compartido. Emplea contenido de prueba aprobado y guarda las evidencias operativas en el sistema correspondiente.
Analiza los casos que un test básico no detecta
Una respuesta en texto plano puede funcionar correctamente mientras otro caso de uso habitual falla. Pregunta al equipo técnico qué situaciones son críticas en vuestro flujo real: respuestas desde un buzón secundario, archivos adjuntos, mensajes reenviados o contestaciones a correos antiguos tras la migración.
No hace falta comprobar cada escenario teórico en todas las campañas. Concéntrate en lo que promete el texto y en las vías que los usuarios ya utilizan. Si una función no está soportada, adapta el mensaje o mantén una ruta operativa en lugar de dar a entender que funciona.
Presta especial atención a los correos enviados con anterioridad: editar la plantilla de mañana no cambiará la dirección Reply-To que ya recibieron tus destinatarios. Coordínate con el equipo responsable antes de dar de baja una dirección o una ruta a la que esos mensajes sigan apuntando.
Documenta la entrega saliente y la recepción entrante por separado. Que el proveedor acepte el envío no garantiza que la contestación del cliente llegue a nadie. Aprovecha los resultados de la prueba para ajustar el siguiente borrador en Migma y publica llamadas a responder únicamente cuando el equipo pueda atenderlas.
Preguntas frecuentes
¿El traslado de plantillas salientes sustituye las rutas de Mailgun?
No. La guía de migración de Loops indica que no cuenta con una función equivalente de enrutamiento entrante. Conviene mantener Mailgun u otro proveedor entrante para las rutas de respuesta necesarias y probarlas al margen del envío saliente.
¿Desde dónde debe iniciarse una prueba de la ruta de respuesta?
Desde un mensaje controlado recibido a través del canal de envío definitivo. Responde directamente a ese correo y comprueba que llega al buzón, ticket o conversación de la aplicación previsto. Escribir la dirección manualmente en un correo nuevo deja sin validar parte del trayecto.
¿Se puede seguir invitando a responder durante la migración?
Solo si el equipo responsable ha comprobado que la dirección y el flujo posterior siguen operativos. En caso contrario, recurre a un canal de contacto verificado y compatible, y modifica cualquier llamada a responder contradictoria en las nuevas creatividades.
¿Por qué siguen siendo importantes los correos enviados con anterioridad?
Porque conservan la dirección Reply-To y las condiciones vigentes en el momento del envío. Modificar las plantillas futuras no altera esos mensajes. Conviene verificar cómo se gestionarán esas respuestas antes de retirar una dirección o ruta entrante antigua.