Cuando el flujo automatizado envió el mensaje de bienvenida a un cliente que llevaba 2 años
El trigger del flujo de bienvenida estaba configurado para activarse cuando un contacto existente en el CRM tenía un campo de "fecha de primera compra" que pasaba de vacío a tener un valor. Era la lógica correcta para el caso que el flujo debía manejar: un nuevo cliente que acababa de cerrar su primer contrato. Lo que ninguno de los que habíamos diseñado el flujo había anticipado era que el proceso de migración de datos históricos que habíamos realizado el mes anterior había poblado ese campo retroactivamente para todos los clientes existentes, incluyendo los que llevaban 2 años de relación, sin que el sistema de automatización tuviera ningún mecanismo para distinguir entre una primera compra nueva y un campo que acababa de ser rellenado de forma retrospectiva.
El resultado fue el envío simultáneo del email de bienvenida de nuevo cliente a 89 clientes activos, varios de ellos con más de 18 meses de relación consolidada. El email decía, con la amabilidad característica de un onboarding bien diseñado: "Bienvenido/a a nuestra familia. Estamos emocionados de comenzar este camino juntos. En los próximos días recibirás información sobre cómo sacar el máximo provecho de tu nueva solución." Para un cliente que llevaba 2 años usando la solución y que era uno de los más satisfechos de la base, la comunicación no solo era incorrecta. Era perpleja.
Las respuestas de los clientes afectados llegaron en 2 categorías. La primera, y más numerosa, fue de confusión benigna: clientes que escribían preguntando si había un error en el sistema, si habían sido dados de baja sin saberlo o si la comunicación era para otra persona. La segunda categoría, menos numerosa pero más preocupante, fue de clientes que interpretaron el email como una señal de que algo había cambiado en la relación sin que se les hubiera informado: ¿habían sido transferidos a otro plan? ¿Había cambiado algo en los términos del contrato?
La gestión del incidente requirió 4 días de trabajo intensivo del equipo de customer success. El protocolo fue específico: primero, identificar todos los contactos que habían recibido el email incorrecto y clasificarlos por antigüedad de relación. Segundo, enviar un email de corrección dentro de las 12 horas del descubrimiento del error, reconociendo que habían recibido una comunicación incorrecta por un error de sistema. Tercero, hacer seguimiento telefónico con los 11 clientes que habían respondido de forma activa al email incorrecto.
El error no produjo ninguna cancelación de contrato. Sí produjo algo más sutil y más costoso a largo plazo en algunos casos: una pequeña erosión de confianza en la profesionalidad de la operación para los clientes que habían recibido la comunicación sin contexto de corrección oportuna. La lección técnica fue sobre la importancia de los mecanismos de desambiguación en los triggers de automatización: cuando un trigger se basa en un cambio de estado de un campo, el flujo debe verificar si ese cambio de estado representa realmente el evento que el trigger intenta capturar o si es un artefacto de un proceso administrativo diferente.