¿Cómo encadena secuencias de correo para que lo que hace un cliente potencial decida lo que ocurre después?

01El problema de negocio

Tiene una lista de personas a las que merece la pena contactar y un mensaje que merece más de un envío. Un solo email se ignora; cinco idénticos son spam. Lo que realmente quiere es una escalera en la que el comportamiento decida el peldaño:

• quien responde debe dejar de recibir la campaña de inmediato y llegar a una persona;
• quien abre o hace clic ha mostrado interés y debe recibir el siguiente mensaje, distinto;
• quien nunca interactúa debe avanzar con un temporizador, o detenerse;
• quien se da de baja o rebota debe quedar suprimido en todas partes, de forma permanente;
• y usted debe poder responder a «¿sigue funcionando esta campaña?» sin abrir cinco pantallas.

Los cuatro primeros son mecanismo. El quinto es el que decide si la máquina merece la pena, y es el que casi nunca se construye.

02Por qué falla el enfoque obvio

Una secuencia larga con todos los pasos dentro

La lectura más sencilla de «campaña de varios contactos» es una secuencia con diez pasos. Envía con un temporizador y no puede ramificarse: un destinatario que hace clic en el paso dos recibe el paso tres exactamente igual que si no lo hubiera hecho. La única palanca de comportamiento que tiene una secuencia sobre su propio flujo es desinscribir: puede detenerse, pero no puede girar.

Esperar que una secuencia pase el testigo a otra secuencia

La siguiente idea es un conjunto de secuencias cortas en el que el último paso de cada una inscribe en la siguiente. Ese paso no existe. Los nodos de una secuencia envían emails, esperan y crean registros: inscribir en una secuencia no es una acción que pueda realizar una secuencia. Nada en el editor lo insinúa hasta que usted busca el nodo y descubre que no está.

Barrer con un proceso programado en su lugar

Un proceso programado diario sobre los contactos, que mueve a cualquiera cuya interacción haya cambiado, funciona, y desperdicia justo lo que hacía que esto mereciera la pena. La interacción es un evento: abrió a las 09:14, hizo clic en el enlace de precios, respondió. Un barrido nocturno solo ve el estado, llega con hasta un día de retraso y no puede decirle qué mensaje provocó la reacción.

Dejar que el proceso receptor se dispare para cualquiera

Una vez construida la cadena basada en tareas, el proceso receptor vigila la creación de tareas. Deje su actor en cualquier usuario (la lectura por defecto de «cuando se crea una tarea») y cada tarea que un comercial crea a mano pasa por la maquinaria de la campaña. La solución es un único ajuste, y el §5 explica por qué no es opcional.

03Modelo de datos

Tres objetos y una convención sostienen todo el diseño.

Fuente. Centro de ayuda de Coevera, Using email sequences in Coevera: la secuencia tal como viene de fábrica, antes de encadenarle nada.

Qué inscribe una secuencia, y según qué

El disparador de una secuencia designa un tipo de entidad y un id de campo concreto (el campo de email al que envía), con un lookup opcional para poder llegar a una dirección de un registro relacionado. Ese detalle importa más de lo que parece: una secuencia que inscribe leads puede enviar al email del contacto principal a través de la relación, y por eso el registro inscrito y el destinatario no tienen por qué ser lo mismo.

Los ajustes que delimitan una secuencia

Por qué el mensaje tiene que ser un registro

Una acción global puede crear una tarea, un lead o un texto, y las estadísticas cuentan cada uno por separado. Una tarea es el soporte adecuado aquí porque es barata, se vincula al contacto, admite campos personalizados y su creación es una superficie de disparo. El puntero viaja en uno de esos campos.

04Configuración a nivel de campo

Las cuatro acciones globales, completas

Son los únicos ganchos de comportamiento de la secuencia. Hay exactamente cuatro eventos:

Cada una es un indicador más su carga útil: una respuesta puede desinscribir, enviar una respuesta provisional y crear una tarea, de forma independiente entre sí.

La condición personalizada es donde viven las aperturas y los clics

La respuesta, la baja y el rebote son eventos fijos. La apertura y el clic no son eventos a los que se suscriba: son condiciones que usted describe. La condición personalizada acepta un filtro corriente, y la forma que funciona tiene dos cláusulas:

Message.subject         Is  "{the subject of the step you are watching}"
Email.tracking_status   Is  Opened  OR  Clicked

La cláusula del asunto es lo que limita la condición a un paso de la secuencia en lugar de a cualquier mensaje enviado jamás. También significa que editar la línea de asunto de un paso rompe sin aviso la condición que lo vigila: el filtro sigue buscando una cadena que ya nadie envía.

El puntero y el contador

Ponga al campo puntero un nombre que diga lo que hace. Es el valor más estructural de la cadena y el más fácil de confundir con algo inofensivo; el §6 describe la consecuencia.

Una nota sobre las condiciones booleanas en los filtros

Las condiciones de supresión evalúan booleanos, y una evaluación booleana de «es falso» se almacena sin ningún operador: operator: null con un valor de 0. Esto es coherente en todos los lugares donde se filtran booleanos, así que una regla con un operador nulo sobre un campo de casilla de verificación es normal y no está rota. Conviene saberlo antes de ponerse a buscar un operador que falta y que nunca debió estar ahí.

05Automatización y lógica

El proceso receptor, y el ajuste que lo hace seguro

Un proceso, disparado por la creación de tareas, lee el puntero y enruta. Su actor de disparador es lo que hay que configurar bien. El actor de un disparador de registros toma uno de cuatro valores:

Solo aplicaciones es la opción correcta para un proceso receptor, y marca la diferencia entre un circuito cerrado y uno en el que cualquiera puede meter a alguien por accidente. Un comercial que registra una llamada no debería volver a inscribir a un cliente potencial en una campaña de goteo.

La ruta, de principio a fin

sequence step / global action fires
  └─ creates Task  { pointer = "next sequence" }
       └─ catcher process  (Task · Create · ApplicationsOnly)
            ├─ filter: task activity type is an engagement type
            ├─ filter: pointer is not empty
            ├─ filter: contact is in this campaign, not unsubscribed, not archived
            └─ write Contact.step_counter = Task.pointer
                 └─ hand off to the enrolment process
                      └─ branch on step_counter → enrol into that sequence

El traspaso del final es una llamada a un subproceso, que es como cualquier cosa cruza aquí la frontera de un proceso; la restricción y la disciplina de nombres están en el Blueprint 011.

La escalera de inscripción compartida es la parte frágil

En la práctica, el proceso de inscripción no se construye por campaña: se va acumulando. Un ejemplo en producción reúne decenas de campañas no relacionadas en un único proceso de más de cien nodos, con el filtro de una campaña situado a diecinueve niveles de profundidad. Como un filtro es una única puerta cuyas ramas se rigen por la primera coincidencia, la inscripción de un contacto depende de su posición respecto a diecinueve campañas que no tienen nada que ver con él. Cualquier cosa que haga que un filtro anterior coincida primero deja sin aviso fuera de alcance al posterior.

Dé a una campaña su propio proceso de inscripción cuando importe. La escalera compartida es cómoda una vez y cara a partir de entonces.

Haga que un peldaño produzca trabajo

Toda la cadena anterior es maquinaria. En algún punto de ella, una rama debe crear una tarea que se espere realmente que haga una persona: abierta, asignada a un propietario real, con fecha de vencimiento. La candidata obvia es el gancho de respuesta, y la siguiente es un clic en algo comercialmente relevante. El Blueprint 014 plantea el mismo argumento desde el otro lado: la automatización debe dirigir la atención hacia un humano, y debe ser un humano quien se comprometa.

06Límites y compromisos

• Como nada pide, nada detecta. Observado en una escalera real: una cohorte parada en el primer paso durante meses, sin ninguna respuesta registrada, ninguna reunión y ninguna descalificación en ninguno de ellos. La cadena funcionaba; la alimentación había cesado. Nada notifica la ausencia de nuevos registros, porque una campaña vacía y una semana tranquila tienen la misma forma: la misma clase de fallo que la caída de la replicación del Blueprint 009.
• Un campo puntero mal nombrado es un cable con corriente. Un campo etiquetado como una duración en minutos, que lleva el número de la siguiente secuencia, hace el trabajo de mayores consecuencias de la cadena bajo un nombre que invita a editarlo. Cualquiera que lo cambie (una persona que ordena una tarea, o cualquier automatización futura que toque un campo con ese nombre) desvía sin aviso a los contactos hacia otra campaña. Póngale nombre según su función, y trate cualquier etiqueta corta y genérica en un campo de control como un defecto a punto de producirse.
• La escalera puede terminar gracias a un ajuste y no a sus datos. Una secuencia final cuya plantilla de tarea sigue apuntando a un peldaño anterior, y que solo se detiene porque su indicador de crear tarea está desactivado, está a una casilla de un bucle infinito. Haga que el puntero del último peldaño sea terminal en los datos (cero, o un valor con el que no coincida ninguna rama) para que activar el indicador sea seguro.
• Nada hace avanzar el contador salvo la interacción. El proceso de entrada escribe el primer paso; solo el proceso receptor lo hace avanzar. Un contacto que nunca abre, hace clic ni responde se queda en el primer paso para siempre: un comportamiento correcto, e invisible a menos que alguien informe sobre ello.
• Editar una línea de asunto rompe la condición que la vigila. La condición personalizada coincide con la cadena del asunto, así que un retoque del texto desconecta el gancho sin aviso. Nada falla; el peldaño simplemente deja de capturar a nadie.
• La gestión de rebotes quema direcciones de forma permanente. Ante un rebote se puede dar de baja al destinatario, lo cual es correcto para la entregabilidad e implacable con una lista defectuosa: una importación mal validada suprime una parte de sí misma en el primer contacto, y esos contactos quedan después excluidos de todas las campañas futuras por las mismas condiciones de supresión. Valide antes del primer envío; el Blueprint 005 muestra el aspecto de una importación sin validar.
• Las estadísticas son por secuencia, no por cadena. Cada secuencia informa de inscripciones, envíos, destinatarios, aperturas, clics, respuestas, rebotes, bajas, tareas y leads creados, y un recuento de inscripciones actuales, pero nada agrega una escalera. La salud de la campaña en su conjunto tiene que reconstruirse a mano a partir de cinco pantallas, y precisamente por eso nadie lo hace.

El compromiso que conviene decir claramente

Construir la escalera con tareas le da una ramificación real por comportamiento en una plataforma cuyas secuencias no pueden ramificarse, usando solo piezas nativas. Lo que cuesta es que la lógica de la cadena vive en tres lugares a la vez (la plantilla de tarea dentro de cada secuencia, los filtros del proceso receptor y los filtros del proceso de inscripción) y ninguna pantalla muestra los tres juntos. Eso es llevadero con una convención de nombres y un diagrama, e insostenible sin ellos. Si la campaña es realmente lineal y nadie necesita ramificar según el comportamiento, una secuencia con más pasos es la respuesta honesta, y mantenerla viva cuesta una fracción.

07Verificación

Leído en un espacio de producción real: una escalera de secuencias de cinco peldaños, su proceso receptor, el proceso de inscripción compartido y el esquema detrás de los tres.

• El conjunto de acciones globales se leyó del esquema, lo que confirma exactamente cuatro eventos (respuesta, baja, condición personalizada, rebote) con sus indicadores independientes de desinscribir, enviar email y crear registro, que solo la condición personalizada lleva un filtro, y que solo el rebote ofrece dar de baja al destinatario.
• La condición personalizada se leyó de una secuencia real: una cláusula de línea de asunto combinada con un estado de seguimiento del email de abierto o con clic.
• Los ajustes de la secuencia (ventana de envío, zona horaria, activo desde y activo hasta, desinscripción automática al caducar, cada email inicia una conversación, y el proceso disparador designado) se leyeron del esquema y se confirmó que tenían datos en secuencias reales.
• Se rastreó el proceso receptor en producción: disparado por la creación de tareas con el actor ApplicationsOnly, filtra por tipo de actividad de interacción, un puntero no vacío y la pertenencia del contacto a la campaña y sus indicadores de supresión, y después escribe el puntero en el contacto y pasa el testigo.
• Los cuatro valores de actor se confirmaron a partir del enum, al igual que los eventos de disparo, que incluyen email enviado y email recibido junto con crear, actualizar y eliminar.
• El esquema de punteros de la escalera se leyó de las plantillas de tarea: cada peldaño escribe el número de su sucesor, y el peldaño final sigue llevando un puntero de vuelta a uno anterior mientras depende de un indicador desactivado para terminar.
• Se midió el proceso de inscripción compartido: más de cien nodos, decenas de campañas no relacionadas en una única escalera de primera coincidencia, el filtro de una campaña a diecinueve niveles de profundidad, y el propio proceso con un estado de advertencia.
• La convención booleana de operador nulo se confirmó en tres procesos independientes: una evaluación booleana de «es falso» no almacena ningún operador y sí un valor de cero.

No observado, y se indica como tal:

• Una secuencia en pleno envío durante este trabajo. Cada hallazgo se ha leído de la configuración almacenada y de las estadísticas almacenadas, no de una campaña ejecutada a propósito.
• Qué ocurre si se activa el indicador de crear tarea del peldaño final: el bucle se deduce del valor del puntero almacenado, no se ha observado.
• Si editar la línea de asunto de un paso desconecta la condición personalizada, lo que se deriva de la forma del filtro pero no se ha probado.
• El comportamiento de los tipos de registro lead y texto que puede crear una acción global; solo se rastreó la vía de las tareas.
• Que ApplicationsOnly ignore una tarea creada por una persona. Su significado se leyó del enum, no se probó creando una tarea a mano.

Qué indicaría una regresión

• Que todas las secuencias de la escalera informen de cero inscripciones actuales. La comprobación de salud más barata, y la única que distingue «no hay nadie en curso» de «nadie ha interactuado todavía».
• Tareas que se acumulan mientras el contador de pasos sigue en uno. El proceso receptor se dispara y el traspaso no, así que los contactos se marcan y nunca avanzan.
• Que el recuento de tareas creadas de un peldaño caiga a cero mientras continúan los envíos. Su condición personalizada ha dejado de coincidir, casi siempre porque se editó una línea de asunto.
• Cualquier tarea abierta del tipo de actividad de la campaña cuyo propietario sea un humano. O bien el actor del proceso receptor se ha relajado y ya no es solo aplicaciones, o bien alguien está trabajando dentro de los tipos de tarea de la máquina, y ambas cosas producirán inscripciones inesperadas.

Blueprints relacionados

• Blueprint 011 — ¿Cómo mantiene cientos de automatizaciones del CRM de forma sostenible? — los filtros de primera coincidencia y los traspasos a subprocesos, con los que se construye esta cadena.
• Blueprint 014 — ¿Cómo detecta a los clientes en riesgo de abandono antes de la renovación? — el mismo argumento desde el otro lado: la automatización dirige la atención, una persona se compromete.
• Blueprint 009 — ¿Cómo automatiza sobre campos del CRM que pertenecen a otro sistema? — por qué una alimentación detenida es silenciosa y no un error visible.
• Blueprint 005 — ¿Cómo migra contactos desde otro sistema sin perder datos sin darse cuenta? — lo que hace una lista sin validar en el primer contacto.