El Lifecycle Stage és una marca de màxims, no un estat

Per què el lifecycle stage de HubSpot està fet per avançar només cap endavant

HubSpot va dissenyar el lifecycle stage com una escala d’un sol sentit. Les etapes tenen un ordre, i la propietat està pensada per avançar. Si feu retrocedir un contacte amb un workflow o una importació, HubSpot rebutjarà el canvi o només us deixarà fer-lo després de buidar el valor. Si el buideu, també perdeu les marques de temps «Became a [stage] date», que són les que fan possible el reporting de conversió.

Aquest disseny no és una limitació que calgui esquivar. És el model correcte, perquè el lifecycle stage respon una sola pregunta: fins on va arribar mai aquesta persona? Això és un fet històric, i els fets històrics no se sobreescriuen. En el moment que torneu a Subscriber un client que ha fet churn, esborreu la prova que algun cop va ser client. La vostra taxa de conversió de Lead a Customer canvia en silenci per a cada cohort a la qual pertanyia aquella persona.

La regla que instal·lo a cada projecte: el lifecycle stage és una marca de màxims. Només avança, i tot el que hagi de retrocedir va en una altra propietat.

Les tres feines que esteu sobrecarregant

Quan obro una auditoria de lifecycle, separo aquell únic desplegable en tres conceptes diferents.

1. Progrés dins el funnel (lifecycle stage). El punt més llunyà on va arribar aquesta persona. Només cap endavant. Alimenta el reporting de conversió i les propietats «Became X date».

2. Estat actual (una propietat d’estat). Aquesta persona és activa, inactiva, ha fet churn, està desqualificada o reciclada, ara mateix? Aquesta sí que es pot moure en qualsevol direcció, perquè descriu el present, no el passat. Poseu-li el nom del que és: Member Status, Account Status, Engagement Status. Trieu un nom que un rep pugui llegir sense glossari.

3. Tipus de contacte (una propietat de classificació). És un comprador, un usuari, un empleat d’un client, un contacte d’un partner, un periodista? És un atribut de la relació, no una posició dins el funnel, i no s’hauria de codificar mai com un lifecycle stage.

Quan aquests tres viuen en tres propietats, la majoria de les queixes de «el lifecycle està trencat» desapareixen, perquè el que estava trencat era el disseny, no les dades.

Un exemple real de la separació

En el muntatge de HubSpot de Tech Barcelona ens vam trobar exactament amb això. Un soci que cancel·la la seva quota es queda a Customer al lifecycle stage, expressament. L’estat actual real viu en una propietat a part, Member Status (Active, Inactive, Churn). Quan algú de l’equip del client va preguntar per què un soci que havia fet churn continuava apareixent com a Customer, la resposta va ser que fer retrocedir el lifecycle hauria esborrat el registre de qui havia arribat a ser soci algun cop.

El mateix projecte va fer aflorar el problema del tipus de contacte. Els empleats d’empreses sòcies i partners s’havien mapat com a Subscriber, cosa que contaminava el grup de persones a qui realment es podia fer màrqueting. L’arranjament temptador era passar-los tots a Customer. Ens hi vam oposar, perquè avui Customer vol dir «ens paga», i el dashboard de socis i el reporting de conversió llegeixen directament d’aquella etapa. Barrejar empleats que no paguen dins Customer hauria destruït l’únic número en què confiava l’equip directiu. El més net era deixar el lifecycle com estava, mantenir el tipus de contacte en la seva pròpia propietat i crear una llista que exclogués qualsevol persona que ja fos sòcia.

Mateix projecte, mateixa lliçó: quan un número de reporting importa, no canvieu el que vol dir l’etapa per resoldre un problema de segmentació. Afegiu una propietat.

L’auditoria del lifecycle stage (45 minuts, sense workflows)

No cal reconstruir res per saber com n’està de malament. Feu aquestes comprovacions en ordre.

Comprovació 1: compteu les etapes que feu servir de debò. Exporteu els contactes i agrupeu-los per lifecycle stage. Si teniu etapes personalitzades que ningú no ha tocat en un any, són decoració. Esborreu-les o fusioneu-les. Cada etapa de més multiplica les maneres en què els registres es poden contradir.

Comprovació 2: busqueu el que escriu cap enrere. Obriu cada workflow i cada plantilla d’importació que fixi el lifecycle stage. Tot el que el posi en una etapa anterior a l’actual del registre, o està fallant en silenci, o està executant una rutina de buidar i tornar a fixar que us està traient les marques de temps. Apunteu-los tots.

Comprovació 3: trobeu les contradiccions. Creeu una llista de contactes a Customer sense cap deal closed won associat. Després, al revés: contactes amb un deal closed won que no són a Customer. Totes dues llistes haurien de ser gairebé buides. Si no ho són, el vostre lifecycle s’està fixant a mà o mitjançant integracions sense regles.

Comprovació 4: reviseu el rollup d’empresa. El lifecycle del contacte i el de l’empresa se separen de seguida. Una empresa apareix com a Subscriber mentre el seu contacte principal és Customer, o al revés. Si no heu automatitzat mai el rollup, doneu per fet que està malament.

Comprovació 5: esbrineu qui és responsable de cada transició. Per a cada etapa, pregunteu qui o què pot moure-hi un registre. Si la resposta és «qualsevol», «un formulari» o «crec que ho fa el Sam», aquella etapa no té criteris d’entrada. Aquest és el defecte real.

L’arranjament, en l’ordre que evita danys

L’ordre importa, perquè l’ordre equivocat vol dir buidar dades que no podreu recuperar.

Pas 1: primer, una foto. Exporteu el lifecycle stage i totes les propietats «Became X date» abans de tocar res. És la vostra marxa enrere.

Pas 2: creeu les propietats d’estat i de tipus de contacte. Ompliu-les a partir del que el lifecycle estava codificant malament. Els clients que han fet churn reben l’estat Churn. Els empleats de clients reben el tipus de contacte Customer Employee. Feu-ho abans de canviar un sol valor de lifecycle.

Pas 3: escriviu criteris d’entrada per a cada etapa. Una frase per etapa, comprovable, amb un únic responsable. Un registre entra a Opportunity quan es crea un deal al pipeline de vendes, no quan a un rep li ha anat bé la trucada. Si no ho podeu comprovar amb un filtre, reescriviu-ho.

Pas 4: automatitzeu les transicions i elimineu les manuals. Els canvis d’etapa surten de workflows lligats als criteris, mai d’un desplegable que edita un rep. Quan un rep necessiti de debò saltar-se la regla, que passi per una sol·licitud, no per editar el camp.

Pas 5: arregleu el rollup d’empresa. El lifecycle de l’empresa s’hauria de derivar dels seus contactes i deals amb una regla escrita, per exemple que guanyi l’etapa més alta entre els seus contactes. Munteu-lo un sol cop com a workflow perquè no es pugui desviar.

Pas 6: corregiu només els errors cap endavant. Si un registre és en una etapa posterior a la que s’ha guanyat, aquest és l’únic cas que necessita una neteja deliberada, feta en bloc, conservant les marques de temps i documentada.

Pas 7: demostreu-ho amb una vista de conciliació. Mantingueu una llista fixa amb les contradiccions de la comprovació 3. Si hi apareix alguna cosa, ha fallat una regla. És la mateixa lògica de filtre de prova que fem servir per confirmar que un origen de registres bloquejat continua bloquejat.

Què canvia al vostre reporting

Amb el lifecycle com a marca de màxims, hi ha tres coses que milloren de seguida.

Les vostres taxes de conversió del funnel deixen de moure’s sota els vostres peus. La taxa de Lead a Customer d’un cohort és un número fix, perquè ningú no pot reescriure qui hi va arribar.

Per fi podeu respondre «quants clients actius tenim» des de la propietat d’estat i «quantes persones van arribar a ser clients» des del lifecycle, i els dos números poden ser diferents. Aquesta diferència és el vostre historial de churn.

I deixeu de fer servir el lifecycle stage com a atribució. Descriu el progrés, no d’on va venir la demanda, i canvia a mesura que avança el registre. L’atribució va en els seus propis camps immutables.

La versió sense embuts

Si el vostre workflow de lifecycle fa retrocedir registres, no esteu netejant dades. Esteu reescrivint la història i dient-ne higiene. Mantingueu l’etapa com a registre de fins on va arribar algú, poseu el present en una propietat d’estat, el tipus de relació en una propietat de classificació, i deixeu per escrit qui pot moure cada etapa.

És la mateixa lògica que hi ha darrere la capa de lifecycle del nostre CleanOps Protocol i del pas d’higiene de lifecycle dins el nostre mòdul CRM Foundation and Data Architecture. Si voleu un altre parell d’ulls abans de canviar res, el GTM Maturity and Revenue Leak Assessment us dirà per on les vostres dades de lifecycle estan trencant el reporting de pipeline, i quant us costa.