Cuando falta un campo del huésped, se omite el envío en vez de romper la ejecución

Qué hace realmente un constructor de workflows cuando falta un campo

Todo constructor de journeys hoteleros promete personalización: recuperar el nombre del huésped, insertar su fecha de reserva, mencionar el tipo de habitación que reservó. La demo siempre funciona porque los datos de la demo están completos. En cuanto lo ejecutas con tu lista real de contactos, a un huésped le falta el nombre, o un campo de la reserva está vacío porque viene de una fuente de reservas que no lo rellena, y la pregunta deja de ser teórica. ¿Qué hace realmente el envío?

La mayoría de los constructores solo tienen una respuesta, y normalmente es implícita en vez de elegida. Algunos rompen toda la ejecución del workflow en cuanto una variable de la plantilla no devuelve nada. Otros envían el mensaje igualmente, dejando el hueco en blanco, de modo que el huésped abre un correo electrónico que le saluda con "Hola ,", con el campo de personalización vacío justo donde debería ir su nombre. Ninguna de esas opciones es una decisión que haya tomado el hotel. Es simplemente lo que hace el código cuando se encuentra una cadena vacía.

El constructor de journeys de GuestMaker trata esto como una opción real de configuración, porque lo es. Cuando falta una variable de personalización en el momento del envío, hay tres modos de fallo explícitos, y el hotel elige cuál aplica: skip_contact, la opción predeterminada recomendada, en la que se omite a ese huésped concreto y todos los demás continúan el journey con normalidad; fail_execution, en la que se detiene toda la ejecución del journey para ese huésped específico; y send_anyway, en la que el mensaje sale con el hueco en blanco exactamente donde habría estado la variable. Tres resultados distintos para el mismo caso de dato ausente, y el hotel decide cuál encaja con la campaña.

Omitir o enviar igualmente: elegir el modo de fallo adecuado para la automatización de correo electrónico

La opción predeterminada recomendada es skip_contact, y la lógica detrás de esa opción es sencilla. Omitir significa que un huésped, entre todos los que estén en ese paso del journey, no recibe este envío concreto. Nada más cambia: todos los demás continúan el journey con normalidad. Es la opción que asume que lo más seguro cuando faltan datos es no hacer nada, en lugar de hacer algo mal.

Send_anyway existe porque hay casos reales en los que un hueco en blanco es mejor que omitir el envío, o al menos no es peor. Un recordatorio genérico de tipo "Tu estancia se acerca" puede seguir siendo útil aunque falte el tipo de habitación. Pero tiene que ser una elección deliberada, tomada por alguien que ha visto la plantilla y ha decidido que un campo vacío no dejará mal a la marca, no una opción predeterminada que nadie seleccionó activamente. La diferencia importante está entre que el hotel lo elija y que el constructor lo aplique por defecto. Una cosa es una decisión tomada una vez, en la configuración del nodo, con la plantilla real delante. La otra es una sorpresa que el huésped se encuentra en su bandeja de entrada.

Fail_execution es la opción más estricta, y existe para campañas en las que un envío parcial es claramente peor que no enviar nada. Piensa en un flujo de confirmación que necesita un campo concreto de la reserva para que el mensaje tenga sentido. Si ese campo falta, no quieres que salga una versión del mensaje con un agujero, ni que el resto del journey de ese huésped asuma discretamente que el paso se completó correctamente. Detener toda la ejecución para ese huésped es el fallo correcto, aunque sea el más disruptivo.

El límite de frecuencia en campañas hoteleras es una omisión, no un retraso

Hay un segundo lugar, más silencioso, donde aparece "omitir" en un journey de GuestMaker, y es fácil asumir que se comporta como el primero. No es así, y la diferencia importa más de lo que parece.

El límite de frecuencia en un nodo de correo electrónico, llamado Smart Sending, existe para evitar que un huésped reciba demasiados mensajes en una ventana demasiado corta. La suposición instintiva es que un envío limitado por frecuencia se aplaza, queda retenido hasta que el huésped vuelva a ser elegible y después se envía tarde. No es eso lo que ocurre. Un envío bloqueado por frecuencia se omite directamente. No se pone en cola, no espera a que haya una ventana libre, no se dispara más tarde ese mismo día cuando el límite se restablece. Simplemente no sale, y esa decisión se registra con su propio motivo explícito, separado de cualquier nodo de espera o retraso real dentro del journey.

Esa distinción solo resulta útil si puedes verla. Cuando el equipo de marketing de un hotel mira la ejecución de un journey y un paso no se ha disparado, la pregunta honesta siempre es: "¿este huésped sigue esperando o decidimos no enviarle nada?" Son problemas distintos, con soluciones distintas. Un huésped atrapado en un nodo de retraso quizá necesita que se revise la condición de espera. Un huésped cuyo envío se omitió por motivos de frecuencia nunca iba a recibirlo en esa ejecución, punto, y el registro lo dice claramente en lugar de dejar ambos casos indistinguibles en un log de ejecución.

Qué omite realmente Smart Sending y cómo lo sabrías

Es fácil infravalorar lo que aporta "omitir, no retrasar" como si fuera un detalle menor de implementación. No lo es. Un retraso implica que el envío sigue pendiente y llegará más tarde, lo que significa que cualquiera que lea el historial de ejecución del journey esperaría encontrarlo finalmente, enviado unas horas o unos días después de que desapareciera el límite. Una omisión no promete nada de eso. Dice: en esta ejecución, con este disparador, este huésped no recibió este mensaje, y esa decisión es definitiva para este paso.

El resultado es una explicación más honesta de lo que ocurrió realmente, y evita un modo de fallo peor: que un mensaje llegue inesperadamente tarde, desconectado de aquello que lo activó originalmente, porque un diseño basado en envíos retrasados intentó ponerse al día con una cola acumulada. Que un huésped reciba un recordatorio de "tu check-in es mañana" dos días después del check-in, porque estaba en cola detrás de un límite de frecuencia en vez de haberse omitido, es peor que no recibir ese envío concreto. Nadie diseña ese comportamiento a propósito. Ocurre cuando "omitir" y "retrasar" se mezclan bajo un mismo mecanismo en lugar de mantenerse como dos resultados separados y claramente etiquetados.

No vamos a dar aquí una cifra sobre la frecuencia con la que se activa un límite en un envío determinado, porque depende por completo de cómo haya configurado cada hotel sus propias reglas de frecuencia, de cuántos journeys estén activos y de cuántas veces un huésped cruce más de uno de ellos. Lo que sí es cierto, sea cual sea la cifra, es que el mecanismo tiene que ser una omisión, registrada como omisión, o el hotel pierde la capacidad de distinguir entre "todavía llegará" y "no ocurrió" cuando va a comprobarlo.

Así son los casos límite reales en la automatización de marketing hotelero

Los campos de personalización ausentes y los límites de frecuencia no son casos límite en el sentido de que sean raros. Lo son porque son justo el momento en que las decisiones de diseño de un constructor de workflows dejan de ser invisibles. La mayoría de los días, todos los huéspedes tienen un nombre registrado y nadie está cerca de un límite de frecuencia, así que de verdad no importa qué haría el constructor si no fuera así. El diseño solo se pone a prueba el día en que no se cumple, y para entonces el mensaje ya ha salido, o ya ha fallado.

El consentimiento es una cuestión distinta de los datos de personalización incompletos o los límites de frecuencia. Los envíos de marketing deben evaluarse según el permiso del destinatario para ese canal y esa categoría de mensaje. Elegir skip_contact, fail_execution o send_anyway para un campo que falta no concede consentimiento de marketing, y Smart Sending no lo sustituye. Un nombre que falta y un permiso que falta son motivos distintos para detener y revisar un envío; no deben confundirse.

Personalización que no presupone nada sobre tus datos

Nada de esto va realmente de campos ausentes, límites de frecuencia o comprobaciones de consentimiento por separado. Va de si un constructor de journeys hoteleros trata el momento en que tus datos no son perfectos como un escenario que merece diseño, o como algo que queda en manos de lo que el código acabe haciendo. Las bases de datos reales de contactos tienen huecos. Un campo de reserva de una fuente no coincide con el de otra. El nombre de un huésped puede no estar todavía en el sistema. Más que un fallo de calidad de datos, todo eso es la forma que tiene una lista real de contactos de un hotel un martes cualquiera.

Un constructor de journeys que solo tiene una respuesta para todo eso, romper la ejecución o enviarla rota, no es más sencillo. Está decidiendo por ti, en silencio, y esperando que nunca te fijes en qué elección tomó. Skip_contact, fail_execution y send_anyway existen porque la respuesta adecuada depende de verdad de la campaña. Un flujo de confirmación y un recordatorio genérico de newsletter no merecen el mismo modo de fallo, y fingir que sí es la forma en que un hotel acaba disculpándose por un hueco en blanco en la bandeja de entrada de un huésped, en lugar de haber decidido de antemano que ese envío nunca debía salir así.