El cliente ha comprado. Unas horas después, un email pregunta: «¿Te has dejado algo en la cesta?». Avisa de que la entrega va con retraso; el siguiente mensaje le invita a volver a pedir. Técnicamente, la automatización funciona exactamente como se configuró. El problema está en lo que las reglas pasaron por alto.
Un proceso automatizado aplica reglas a datos y eventos. Si el evento está incompleto, llega tarde o se interpreta mal, el mensaje puede ser inadecuado aunque su texto sea bueno.
La pregunta no es solo qué activa una automatización, sino qué debería detenerla o cambiar su rumbo.
Del calendario a la situación
«Enviar tres días después del pedido» es una regla de calendario. «Enviar después de la entrega confirmada, si el mensaje es adecuado y se cumplen sus condiciones» es una regla construida en torno a la experiencia del cliente.
El segundo enfoque exige algo más que una redacción mejor.
- ¿Es fiable el estado de entrega?
- ¿Cuándo llega al sistema?
- ¿Qué cuenta como excepción?
Si los datos no permiten esa lógica, elige un mensaje coherente con lo que se sabe.
No escribas «Ahora que has recibido el producto» a partir de una simple fecha estimada. Puedes comunicar de forma útil sin inventar el estado de un pedido.
Qué tipos de procesos pueden tener sentido
| Situación | Función posible | Pregunta antes de implementarlo |
|---|---|---|
| Alta confirmada | Orientación y expectativas claras | ¿Qué pidió la persona? |
| Acción comercial sin terminar | Ayuda para seguir el recorrido | ¿Sabemos que no la terminó en otro sitio? |
| Primera experiencia | Ayuda para usar el producto | ¿Qué estado real podemos usar? |
| Producto de uso repetido | Recordatorio relevante | ¿El intervalo elegido se basa en algo? |
| Inactividad significativa | Una posible nueva presentación de la oferta | ¿Es la inactividad inusual para la categoría? |
La tabla describe pistas; no recomienda activar cada proceso. Algunas empresas tienen que corregir primero sus mensajes de confirmación y de servicio.
Lo que hay que comprobar antes del envío
Un evento puede hacer que una persona entre en revisión. Antes del envío, comprueba las reglas aplicables: permisos, preferencias, estado comercial, mensajes anteriores y motivos para detenerse.
Los datos pueden cambiar durante la espera. Un pedido nuevo puede hacer innecesario un recordatorio. Aplica las bajas según el objetivo del mensaje. Una sincronización fallida no debe tratarse como la prueba de que se cumplen todas las condiciones.
¿Qué hay que comprobar antes del envío?
El evento inicial no sustituye la comprobación del estado actual.
APTITUD
Finalidad, preferencias y condiciones aplicables.
ESTADO ACTUAL
Pedido, entrega, devolución o problema sin resolver.
COORDINACIÓN
Mensajes ya enviados y otros procesos activos.
DECISIÓN
Enviar, retrasar, detener o pedir una intervención, según las reglas acordadas.
Marco ilustrativo. Su aplicación depende del contexto y de los datos del proyecto.
En los mensajes comerciales, la base jurídica y las reglas de contacto tienen que fijarse antes de la activación. Una automatización de cesta abandonada no queda exenta de las normas del marketing solo porque alguien actuó en la web.
Un ejemplo en el que la secuencia cambia la experiencia
Tomemos una tienda ficticia de electrodomésticos. Un cliente compra un aparato y, después de la entrega, podría recibir una guía de uso. Más adelante, puede plantearse una comunicación sobre accesorios compatibles, si está justificada y permitida.
Pero entre esos dos momentos, el producto se devuelve. Si la plataforma de marketing lo sabe, la oferta de accesorios puede detenerse. Si el estado nunca llega o no forma parte de las reglas, el proceso sigue como si nada hubiera cambiado.
| Evento nuevo | Pregunta para el proceso |
|---|---|
| La entrega se retrasa | ¿El mensaje supone que el cliente ha recibido el producto? |
| Reclamación o solicitud de ayuda | ¿Es adecuada ahora una comunicación comercial? |
| El pedido se cancela o se devuelve | ¿Sigue siendo relevante el producto asociado? |
| Cambia la preferencia de marketing | ¿Se actualizó la aptitud antes del envío? |
No toda solicitud de ayuda tiene que bloquear toda comunicación. La regla depende del tipo de situación y de la función del mensaje. Un mensaje necesario para resolver el problema no tiene la misma prioridad que una promoción.
Varios procesos pueden hablar a la vez
En una semana, una persona puede recibir la newsletter, una secuencia de bienvenida y emails posteriores a la compra. Cada uno puede parecer razonable por separado mientras la experiencia de conjunto resulta invasiva o contradictoria.
Fijamos prioridades, límites de frecuencia cuando los sistemas lo permiten y reglas para los solapamientos. No prometemos una coordinación perfecta entre todos los servicios si la integración no puede sostenerla. Comprobamos en concreto qué información circula entre el e-commerce, el CRM, el email y la publicidad.
Los mensajes no tienen la misma prioridad.
Ejemplo de preguntas para un pedido con un problema de entrega.
INFORMACIÓN ESENCIAL
¿Qué tiene que saber el cliente sobre su pedido?
RESOLUCIÓN
¿Qué mensaje ayuda al cliente a conseguir ayuda?
PROMOCIÓN
¿Es adecuada ahora la oferta adicional?
Ejemplo ficticio, ni resultados ni previsiones de NOT MORE.
Qué significa probar un proceso
Recibir un email de prueba no basta. Comprueba quién entra en el proceso, qué datos se usan, qué lo detiene y qué pasa cuando una integración se retrasa.
Los casos de prueba pueden incluir un pedido confirmado durante el periodo de espera, un evento duplicado, una baja, un producto no disponible o una dirección a la que no se puede llegar. Define el resultado esperado antes de probar.
Estas comprobaciones no son formalidades técnicas. Evitan experiencias que parecen descuidadas: emails duplicados, recomendaciones incompatibles u ofertas enviadas después de que una persona pidiera dejar de recibir marketing.
Quién mantiene la automatización después del lanzamiento
Los catálogos, los productos, los formularios y las políticas comerciales cambian. Un proceso correcto en el lanzamiento puede volverse erróneo si nadie revisa aquello de lo que depende.
Establecemos las responsabilidades de los datos, el contenido y el funcionamiento. Hace falta una forma de ver los errores y de detener o corregir la comunicación cuando la situación lo exige. La automatización reduce algunas operaciones repetitivas, pero introduce un trabajo de diseño y mantenimiento.
Una plataforma puede atribuir facturación a un proceso sin mostrar que este provocó todas esas compras. Comparamos el resultado con los costes, la relevancia y los efectos en la experiencia.
Cómo trabajamos en NOT MORE.
Partimos del recorrido del cliente y de la información fiable de la que disponemos. Elegimos las automatizaciones que pueden ayudar, definimos las reglas y los mensajes, y después comprobamos su comportamiento en las situaciones normales y en las excepciones importantes.
A veces, un proceso sencillo apoyado en datos fiables es la mejor opción. Otras situaciones exigen una integración más amplia. La estrategia define el objetivo; la implementación tiene que hacerlo funcionar en condiciones reales.
Quién recibe la alerta y puede detener el proceso
Una automatización útil necesita reglas de comprobación. NOT MORE. puede poner en marcha la integración, las condiciones y las alertas, y después probar las situaciones acordadas. El cliente valida las reglas comerciales y designa a la persona que puede revisar un caso real, corregir una información o suspender temporalmente la comunicación.
Documentamos qué pasa cuando falta un estado, cuando dos sistemas se contradicen o cuando una acción falla. El seguimiento tiene una frecuencia, un responsable y un proceso de escalado. En el trabajo continuo, las observaciones llevan a ajustes y a informes que muestran tanto lo que funciona como lo que queda por resolver.