Dos trabajos distintos se llaman "orquestación" y confundirlos es lo que paraliza los proyectos multicanal. La orquestación de journey decide si contactar, cuándo, por qué y con qué canal: es lógica de negocio. Las operaciones de entrega ejecutan una decisión ya tomada: selección de remitente y ruta, adaptadores, reintentos y failover dentro de un canal. Tienen dueños, pruebas y modos de fallo distintos.
Modelar el estado del cliente, no el flujo por canal
La decisión más importante es si el sistema mantiene un estado canónico del proceso —esta factura está sin pagar, esta cita sin confirmar— o secuencias separadas por canal que no se enteran entre sí. Con estado canónico, cada intento en cada canal actúa sobre ese mismo registro, que decide qué ocurre después.
Eventos disparadores y su vigencia
Los eventos caducan: la factura ya pagada, la cita ya confirmada. Hay que releer el estado justo antes de enviar, no solo al programar, y llevar una marca de vigencia en la solicitud para rechazar decisiones obsoletas.
Reglas de elegibilidad evaluadas en el momento del envío
Consentimiento con evidencia recuperable, supresión propagada entre canales y proveedores, disponibilidad real del canal, identidad verificada, idioma y zona horaria local, horario silencioso evaluado en hora local, límites de frecuencia y clase de tráfico: todo esto se evalúa en el momento del envío, no en el de inscripción.
Política de decisión: qué canal y por qué
El canal preferido, la urgencia y el plazo, la sensibilidad del contenido —el SMS ordinario debe tratarse como no cifrado en tránsito y visible en pantalla bloqueada, as í que no debe llevar credenciales ni datos sensibles—, el riesgo, el coste como una entrada más de la política, y la capacidad del canal deben quedar escritos en una tabla por caso de uso.
Idempotencia, estado del intento y fallback
La deduplicación debe ocurrir a nivel de estado, con una referencia propia guardada antes del envío. Cada intento necesita un estado explícito —creado, enviado, estado final del proveedor, expirado por tiempo, sustituido—, distinguiendo un fallo definitivo de una simple falta de confirmación. El fallback debe dispararse por plazos del propio proceso y por señales fiables (rechazo explícito, destino inválido), tratando con cautela la mera ausencia de acuse. Debe tener un límite de canales e intentos y un camino cuando la cadena se agota.
Condiciones de parada, respuestas y atribución
Toda campaña necesita condiciones de parada explícitas —resultado logrado, cambio de estado, baja o queja, plazo vencido, límite de frecuencia, interruptor operativo— evaluadas en el momento del envío. Las respuestas entrantes y las bajas deben llegar a la máquina de estados y propagarse entre canales. Un único ID de journey en todos los intentos, clics y resultados permite saber qué funcionó, en vez de que cada canal se atribuya el mérito.
Dónde vive cada capa
Las operaciones de entrega —adaptadores, enrutamiento, identidad del remitente, reintentos, reconciliación y escalada— son la parte que casi ningún equipo debería construir dos veces. Flowstates suministra y opera canales y rutas, soporta proveedores propios mediante BYOV y soporta despliegues híbridos como esa capa gestionada. La orquestación es más variable y suele vivir donde ya vive el estado canónico del negocio: en la propia aplicación, en un CRM o en un flujo con soporte de Flowstates.