Saltar al contenido
Arquitectura de CanopyA fondo7 min de lectura

Automatización

Secuencias con salida por respuesta, flujos de trabajo sobre eventos del dominio y reglas condicionadas al registro de auditoría. Por qué la automatización lee del registro de eventos en lugar de dispararse como efecto secundario en el camino de escritura, qué cuesta eso en latencia, y qué devuelve en capacidad de recuperación.

Vista de Secuencias y Flujos de trabajo de Canopy con las secuencias activas, los conteos de inscritos y de respuestas, y los disparadores de flujos basados en reglas

La pregunta que determinó la forma del motor de automatización: las reglas deben correr como efectos secundarios en el camino de escritura, o como suscriptores de un registro de eventos durable. Un motor ingenuo dispara las reglas en línea. El operador marca un negocio como cerrado ganado, el manejador en línea corre de inmediato, sale el correo con la prueba de trabajo, se crea la tarea de seguimiento, y la entrada de auditoría se escribe al final. Ese es el camino con menos piezas móviles y menor latencia, y también es el camino donde cada disparo equivocado es invisible, porque la auditoría se escribió después del efecto y no antes. La regla se disparó, el correo salió, el cliente lo recibió; el único registro de por qué se disparó está en la configuración de la regla en el momento del disparo, que el operador puede haber cambiado desde entonces. La automatización en línea es rápida y frágil. Elegí el segundo camino: cada mutación significativa en Canopy escribe primero en el registro de auditoría. Las reglas leen del registro y actúan. Eso es unos cientos de milisegundos más lento que disparar en línea; también es la razón por la que una regla que se dispara mal se puede recuperar. La mutación deja constancia del actor y del cambio. La acción deja constancia de la regla que la disparó y de lo que esa regla estaba leyendo. El registro de auditoría guarda ambas cosas. Así que la pregunta 'por qué salió este correo' tiene una consulta, no una sesión de depuración contra el rastro de pila de un manejador en línea y una configuración de regla que pudo cambiar desde entonces. Consideré el patrón del constructor de automatizaciones sin código: condiciones para arrastrar y soltar, ramas de varios caminos, plantillas con pruebas A/B, todo el paquete. Lo rechacé por la misma razón por la que rechazo casi todas las adiciones de producto. Los compradores que de verdad necesitan software de marketing de ciclo de vida ya están bien atendidos por los jugadores establecidos de esa categoría y ya eligieron uno. Los compradores que todavía no eligen necesitan que los siguientes diez pasos operativos ocurran sin que nadie los recuerde, no un programa de ciclo de vida enorme que para el cuarto mes nadie en la oficina entiende. El software de marketing de ciclo de vida es una categoría real que merece existir; Canopy simplemente no está en ella. El mecanismo se divide en tres primitivas: secuencias, flujos de trabajo y reglas. Cada una tiene un propósito estrecho y lee del registro de auditoría de una manera distinta. Las secuencias son envíos de varios pasos con salida por respuesta. Un prospecto entra a una secuencia cuando el operador la invoca; la secuencia manda el paso uno de inmediato o con retraso; el paso dos sigue después del intervalo configurado; y el prospecto puede salir de la secuencia respondiendo a cualquiera de los mensajes, siendo movido a una etapa de negocio que lo saca, o porque el operador la detenga a mano. La salida por respuesta es lo que más importa: un prospecto que responde deja de recibir el siguiente mensaje de la cadena porque el registro de auditoría escribe el evento de respuesta entrante, la regla de salida de la secuencia lee ese evento, y el siguiente paso se cancela. Sin salida por respuesta, las cadenas automáticas siguen disparando dentro de una conversación que el prospecto ya empezó, y el resultado es esa cadencia de correos que hace que el destinatario odie a quien se los manda. La salida por respuesta no es opcional, por la misma razón por la que los frenos no son opcionales en un coche. Los flujos de trabajo se disparan con eventos del dominio. Un negocio nuevo llega a una etapa, un negocio viejo se queda callado por una ventana larga, un reporte de escaneo marca un hallazgo que amerita seguimiento, el correo de un contacto rebota tres veces seguidas, un contacto nuevo entra a la base de datos desde un formulario. Cada una de esas cosas es un evento en el registro de auditoría, y cada flujo de trabajo es una suscripción a una forma concreta de evento con una cadena de acciones que se dispara cuando esa forma coincide. Los flujos son expresivos: uno solo puede disparar varias acciones, condicionar sobre varios campos y encadenarse con otros flujos a través de los eventos que él mismo escribe. También están acotados: el marco limita la profundidad del encadenamiento para que un flujo mal configurado no se dispare a sí mismo de forma recursiva. Las reglas son la primitiva de más bajo nivel: condicionan sobre qué cambió en el registro de auditoría, no solo sobre qué se disparó. La diferencia importa. Un flujo se dispara con 'un negocio se movió a propuesta'; una regla se dispara con 'un negocio se movió de calificado a propuesta' (importa el estado de origen), o con 'un negocio lo movió a propuesta el operador X' (importa el actor), o con 'un negocio se movió a propuesta Y su valor supera los veinticinco mil dólares' (importa la condición del campo). Las reglas leen la foto del antes y el después de la entrada de auditoría, no solo el tipo de evento, lo que significa que pueden ser específicas sobre qué las disparó de maneras que un flujo no puede. El costo de esa expresividad es que las reglas son una superficie de más bajo nivel y exigen más cuidado para escribirlas bien; el beneficio es que esa misma expresividad cubre casos que si no requerirían código a la medida. Las plantillas de correo tienen versiones. Una plantilla es una pieza de texto con campos de combinación y su línea de asunto, y cada cambio guarda una versión nueva con su marca de tiempo y su actor. Cuando una secuencia manda un paso usando una plantilla, el registro de auditoría deja constancia de qué versión se envió. Si después alguien edita la plantilla y el operador quiere saber 'qué recibió exactamente este prospecto el martes pasado', la respuesta es consultable: la auditoría guarda la versión enviada, y esa versión se puede recuperar del historial de la plantilla. Las plantillas también se pueden revertir: el operador elige una versión anterior y la promueve a actual, lo cual es otro evento de auditoría. El historial de envíos se conserva a través de las reversiones, así que el comprador puede auditar qué salió de verdad sin reconstruirlo desde los registros de la plataforma de correo. Las acciones en lote cubren los casos donde automatizar es excesivo. El operador quiere mandar un envío único a una lista de contactos, no inscribirlos en una secuencia; la herramienta de lote le deja componer el mensaje, elegir los contactos, previsualizar el texto combinado y enviar. Cada acción en lote escribe una sola entrada de auditoría con los identificadores de contacto afectados, el contenido del mensaje y el actor. Esa entrada le permite al comprador responder 'quién mandó este correo a estos cincuenta contactos' sin revisar cincuenta registros de envío por separado. Cada acción automática escribe de vuelta en el registro de auditoría la regla que la disparó. Esta es la inversión que sostiene todo frente al camino de la automatización en línea. Cuando algo se automatiza y no debió automatizarse, el operador abre el registro, encuentra la acción, lee la regla que la disparó, y o afina la regla o la desactiva. El rastro no requiere una sesión de depuración contra los registros internos de un proveedor, porque el rastro está en la base de datos del propio comprador. La misma consulta que explica por qué salió un correo explica también por qué se creó una tarea de seguimiento o por qué un flujo se encadenó con otro. La exclusión honesta: esto no es una suite de automatización de marketing para programas de ciclo de vida de mil pasos. El marco está acotado por el tipo de operaciones que un operador de equipo pequeño necesita expresar: 'cada vez que pase X, haz Y y Z, con salida por respuesta en lo que sale'. No es una herramienta para orquestar el programa de ciclo de vida de una empresa de la lista Fortune 500 con análisis de cohortes, puntajes predictivos y viajes ramificados de diecisiete pasos. La arquitectura se detiene antes de esa escala a propósito, porque los operadores para los que está hecha no sabrían operar la superficie más grande, y los operadores que sí saben operarla no están comprando servicios para negocios pequeños. La consecuencia operativa que el comprador siente es justo la que la arquitectura persigue: cuando algo se automatiza y no debió, la respuesta está a una consulta de distancia. La regla que se disparó está nombrada en la entrada de auditoría. El estado del antes y el después se puede recuperar. La reversión es una sola acción en lote sobre los registros afectados. Las siguientes diez cosas ocurren sin que el operador tenga que recordarlas, y cuando una de esas diez estuvo mal, el sistema se explica a sí mismo en lugar de esconder la causa. Esa es la versión de la automatización que cabe en esta arquitectura, y es la que aguanta meses de operación.

O salga de aquí

El resto del caso de estudio está en /es/proyectos/canopy.