El Lifecycle Stage es una marca de máximos, no un estado

Por qué el lifecycle stage de HubSpot está hecho para avanzar solo hacia delante

HubSpot diseñó el lifecycle stage como una escalera de un solo sentido. Las etapas tienen un orden, y la propiedad está pensada para avanzar. Si hacéis retroceder un contacto con un workflow o una importación, HubSpot rechazará el cambio o solo os dejará hacerlo después de vaciar el valor. Si lo vaciáis, también perdéis las marcas de tiempo «Became a [stage] date», que son las que hacen posible el reporting de conversión.

Ese diseño no es una limitación que haya que esquivar. Es el modelo correcto, porque el lifecycle stage responde a una sola pregunta: ¿hasta dónde llegó alguna vez esta persona? Eso es un hecho histórico, y los hechos históricos no se sobrescriben. En el momento en que devolvéis a Subscriber a un cliente que ha hecho churn, borráis la prueba de que alguna vez fue cliente. Vuestra tasa de conversión de Lead a Customer cambia en silencio para cada cohorte a la que pertenecía esa persona.

La regla que instalo en cada proyecto: el lifecycle stage es una marca de máximos. Solo avanza, y todo lo que necesite retroceder va en otra propiedad.

Los tres trabajos que estáis sobrecargando

Cuando abro una auditoría de lifecycle, separo ese único desplegable en tres conceptos distintos.

1. Progreso en el funnel (lifecycle stage). El punto más lejano al que llegó esta persona. Solo hacia delante. Alimenta el reporting de conversión y las propiedades «Became X date».

2. Estado actual (una propiedad de estado). ¿Esta persona está activa, inactiva, ha hecho churn, está descalificada o reciclada, ahora mismo? Esta sí puede moverse en cualquier dirección, porque describe el presente, no el pasado. Ponedle el nombre de lo que es: Member Status, Account Status, Engagement Status. Elegid un nombre que un rep pueda leer sin glosario.

3. Tipo de contacto (una propiedad de clasificación). ¿Es un comprador, un usuario, un empleado de un cliente, un contacto de un partner, un periodista? Es un atributo de la relación, no una posición en el funnel, y nunca debería codificarse como un lifecycle stage.

Cuando esos tres viven en tres propiedades, la mayoría de las quejas de «el lifecycle está roto» desaparecen, porque lo que estaba roto era el diseño, no los datos.

Un ejemplo real de la separación

En el montaje de HubSpot de Tech Barcelona nos encontramos exactamente con esto. Un socio que cancela su membresía se queda en Customer en el lifecycle stage, a propósito. El estado actual real vive en una propiedad aparte, Member Status (Active, Inactive, Churn). Cuando alguien del equipo del cliente preguntó por qué un socio que había hecho churn seguía apareciendo como Customer, la respuesta fue que hacer retroceder el lifecycle habría borrado el registro de quién llegó a ser socio alguna vez.

El mismo proyecto sacó a la luz el problema del tipo de contacto. Los empleados de empresas socias y partners se habían mapeado como Subscriber, lo que contaminaba el grupo de personas a las que realmente se podía hacer marketing. El arreglo tentador era pasarlos todos a Customer. Nos negamos, porque hoy Customer significa «nos paga», y el dashboard de socios y el reporting de conversión leen directamente de esa etapa. Mezclar empleados que no pagan en Customer habría destruido el único número en el que confiaba el equipo directivo. Lo más limpio era dejar el lifecycle como estaba, mantener el tipo de contacto en su propia propiedad y crear una lista que excluyera a cualquiera que ya fuera socio.

Mismo proyecto, misma lección: cuando un número de reporting importa, no cambiéis lo que significa la etapa para resolver un problema de segmentación. Añadid una propiedad.

La auditoría del lifecycle stage (45 minutos, sin workflows)

No hace falta reconstruir nada para saber lo mal que está. Haced estas comprobaciones en orden.

Comprobación 1: contad las etapas que usáis de verdad. Exportad los contactos y agrupadlos por lifecycle stage. Si tenéis etapas personalizadas que nadie ha tocado en un año, son decoración. Borradlas o fusionadlas. Cada etapa de más multiplica las formas en que los registros pueden contradecirse.

Comprobación 2: buscad lo que escribe hacia atrás. Abrid cada workflow y cada plantilla de importación que fije el lifecycle stage. Todo lo que lo ponga en una etapa anterior a la actual del registro, o está fallando en silencio, o está ejecutando una rutina de vaciar y volver a fijar que os está quitando las marcas de tiempo. Apuntad cada uno.

Comprobación 3: encontrad las contradicciones. Cread una lista de contactos en Customer sin ningún deal closed won asociado. Después, al revés: contactos con un deal closed won que no están en Customer. Las dos listas deberían estar casi vacías. Si no lo están, vuestro lifecycle se está fijando a mano o mediante integraciones sin reglas.

Comprobación 4: revisad el rollup de empresa. El lifecycle del contacto y el de la empresa se separan enseguida. Una empresa aparece como Subscriber mientras su contacto principal es Customer, o al revés. Si nunca habéis automatizado el rollup, dad por hecho que está mal.

Comprobación 5: averiguad quién es responsable de cada transición. Para cada etapa, preguntad quién o qué puede mover un registro a ella. Si la respuesta es «cualquiera», «un formulario» o «creo que lo hace Sam», esa etapa no tiene criterios de entrada. Ese es el defecto real.

El arreglo, en el orden que evita daños

El orden importa, porque el orden equivocado significa vaciar datos que no podréis recuperar.

Paso 1: primero, una foto. Exportad el lifecycle stage y todas las propiedades «Became X date» antes de tocar nada. Es vuestra marcha atrás.

Paso 2: cread las propiedades de estado y de tipo de contacto. Rellenadlas a partir de lo que el lifecycle estaba codificando mal. Los clientes que han hecho churn reciben el estado Churn. Los empleados de clientes reciben el tipo de contacto Customer Employee. Hacedlo antes de cambiar un solo valor de lifecycle.

Paso 3: escribid criterios de entrada para cada etapa. Una frase por etapa, comprobable, con un único responsable. Un registro entra en Opportunity cuando se crea un deal en el pipeline de ventas, no cuando a un rep le ha ido bien la llamada. Si no lo podéis comprobar con un filtro, reescribidlo.

Paso 4: automatizad las transiciones y eliminad las manuales. Los cambios de etapa salen de workflows ligados a los criterios, nunca de un desplegable que edita un rep. Cuando un rep necesite de verdad saltarse la regla, que pase por una solicitud, no por editar el campo.

Paso 5: arreglad el rollup de empresa. El lifecycle de la empresa debería derivarse de sus contactos y deals con una regla escrita, por ejemplo que gane la etapa más alta entre sus contactos. Montadlo una vez como workflow para que no pueda desviarse.

Paso 6: corregid solo los errores hacia delante. Si un registro está en una etapa posterior a la que se ha ganado, ese es el único caso que necesita una limpieza deliberada, hecha en bloque, conservando las marcas de tiempo y documentada.

Paso 7: demostradlo con una vista de conciliación. Mantened una lista fija con las contradicciones de la comprobación 3. Si aparece algo ahí, ha fallado una regla. Es la misma lógica de filtro de prueba que usamos para confirmar que un origen de registros bloqueado sigue bloqueado.

Qué cambia en vuestro reporting

Con el lifecycle como marca de máximos, hay tres cosas que mejoran de inmediato.

Vuestras tasas de conversión del funnel dejan de moverse bajo vuestros pies. La tasa de Lead a Customer de una cohorte es un número fijo, porque nadie puede reescribir quién llegó.

Por fin podéis responder «cuántos clientes activos tenemos» desde la propiedad de estado y «cuántas personas llegaron a ser clientes» desde el lifecycle, y los dos números pueden ser distintos. Esa diferencia es vuestro historial de churn.

Y dejáis de usar el lifecycle stage como atribución. Describe el progreso, no de dónde vino la demanda, y cambia a medida que avanza el registro. La atribución va en sus propios campos inmutables.

La versión sin rodeos

Si vuestro workflow de lifecycle hace retroceder registros, no estáis limpiando datos. Estáis reescribiendo la historia y llamándolo higiene. Mantened la etapa como registro de hasta dónde llegó alguien, poned el presente en una propiedad de estado, el tipo de relación en una propiedad de clasificación, y dejad por escrito quién puede mover cada etapa.

Es la misma lógica que hay detrás de la capa de lifecycle de nuestro CleanOps Protocol y del paso de higiene de lifecycle dentro de nuestro módulo CRM Foundation and Data Architecture. Si queréis otro par de ojos antes de cambiar nada, el GTM Maturity and Revenue Leak Assessment os dirá por dónde vuestros datos de lifecycle están rompiendo el reporting de pipeline, y cuánto os cuesta.