Vuestro forecast no está mal. Vuestras etapas de deal sí.

El pipeline fantasma es la fuga a la que nadie pone precio

Cuando hacemos una auditoría de GTM, las mismas cinco fugas de ingresos aparecen en casi todos los equipos que facturan entre 1 millón y 30 millones de ARR. La fuga número cuatro es la gestión del CRM y del pipeline: conjuntos de propiedades inflados, etapas incoherentes, deals atascados y pipeline fantasma contado en el número del consejo.

La fuga cuatro es la que más discuten los clientes, porque no parece una fuga. No hay nada roto. Los informes cargan. Los dashboards se muestran. Los deals existen. El sistema se comporta exactamente como se construyó.

Eso es lo que la hace cara. Un deal muerto no lanza ningún error. Se queda en Demo Complete, conserva su importe, conserva su fecha de cierre y se cuenta en silencio cada vez que alguien suma el pipeline. A los proveedores les gusta citar qué parte del pipeline está muerta, y las cifras flotan entre una quinta y una tercera parte según qué benchmark elijáis. Yo no construiría un plan sobre ninguna de ellas. La respuesta honesta es que en la mayoría de portales ese número simplemente no se mide, que es peor posición que una mala estimación.

Haced mejor la cuenta en vuestro propio portal. Tomad vuestro pipeline abierto. Suponed que una cuarta parte nunca se cerrará y nunca iba a cerrarse. Si vuestro número del consejo es 4 millones, estáis fijando cuotas, plantilla y planes de caja contra 1 millón de ficción. Nadie ha mentido. El sistema simplemente no tenía forma de decir que no.

Y se multiplica en tres direcciones. Los ratios de cobertura se inflan, así que la dirección invierte de menos en pipeline nuevo justo cuando hace falta. Las medias de tiempo en etapa y de velocidad se ven arrastradas por deals que dejaron de moverse en marzo, así que cada benchmark de etapa que reportáis es una mezcla de deals vivos y cadáveres. Y el win rate se vuelve ilegible, porque el denominador está lleno de oportunidades que nunca fueron oportunidades.

Si un rep puede cambiar vuestro número del consejo editando un campo, no es un número del consejo. Y si un rep puede inflarlo por no editar un campo, tampoco lo es.

Qué es de verdad un deal estancado

La mayoría de equipos no sabe responder a esta pregunta en una frase, y esa es la verdadera causa de fondo. «Estancado» no es una regla. Es una sensación que tiene un jefe de ventas un viernes.

Esta es la definición que escribimos en el modelo de datos. Un deal está estancado cuando se cumplen al menos dos de estas condiciones:

1. Sin actividad bidireccional en la ventana. Ni un envío registrado, ni una tarea que el rep se creó para sí mismo. Un intercambio real, iniciado o respondido por el comprador. Nuestro umbral por defecto para considerar frío un contacto es de 90 días sin actividad bidireccional, y para los deals en un ciclo activo lo ajustamos, normalmente a entre 21 y 30 días según la duración del ciclo.
2. La antigüedad en la etapa supera el benchmark de la etapa. No la antigüedad del deal. La antigüedad en la etapa. Un deal que lleva en Proposal Sent cuatro veces la mediana de tiempo que cualquier deal pasa en Proposal Sent os está diciendo algo que un filtro de antigüedad total no puede.
3. La fecha de cierre se ha aplazado más de dos veces. Un aplazamiento es cosa del comprador. Tres aplazamientos son un rep protegiendo un número.
4. Nunca se cumplieron los criterios de salida de la etapa. El deal está en Negotiation y no hay comprador económico identificado, ni precio enviado, ni siguiente paso agendado. Se movió por optimismo.

Fijaos en lo que no está en la lista: la sensación del rep. «Dice que sigue vivo» no es una prueba, y «commit» no es una etapa. Si la carga de la prueba recae en el sistema, un deal se queda hasta que se gana su sitio. Si la carga de la prueba recae en el rep para demostrar que está muerto, el deal se queda para siempre.

Escribidlo como una sola frase con un responsable y un umbral, igual que escribimos las reglas de supresión para outbound. «Deals estancados» no es una regla. «Sin actividad bidireccional del comprador en 30 días, más antigüedad en etapa superior a 2x la mediana de la etapa, responsabilidad de Ventas, revisado cada semana, con salvaguarda ante cualquier respuesta entrante» sí es una regla.

Tres fallos de diseño que crean deals estancados

Las etapas describen vuestro proceso, no el del comprador

El más habitual y el menos evidente. Las etapas se construyen a partir de un documento de especificaciones en vez de una sesión de trabajo con la persona que de verdad lleva el proceso de principio a fin.

Nos pasó en la migración de Tech Barcelona. Las etapas del pipeline de visitas en HubSpot no coincidían con cómo llevaba realmente una visita la persona responsable de las visitas. La causa de fondo quedó escrita en el ticket de corrección en lenguaje llano: las etapas se habían construido de forma genérica a partir de la especificación original de mapeo de propiedades, sin una sesión dedicada con la responsable del proceso para confirmar su paso a paso real. La solución no fue automatizar. La solución fue reconstruir el pipeline con las cuatro etapas que ella usa de verdad, confirmadas contra una segunda fuente antes de que nadie tocara HubSpot.

Un detalle de esa corrección merece la pena copiarlo: el historial de etapas no se puede rellenar hacia atrás. Si reconstruís las etapas, todo lo anterior a la reconstrucción desaparece como serie temporal. Así que equivocarse con las etapas no solo cuesta el desorden de hoy, cuesta la pérdida permanente del historial que necesitaríais para medir la corrección. Construid las etapas antes de construir los informes.

Las etapas tienen criterios de entrada y ningún criterio de salida

Casi todos los portales que auditamos tienen alguna idea de qué hace entrar un deal en una etapa. Casi ninguno tiene una condición escrita de qué lo saca, aparte de ganarlo.

Gobernar el lifecycle se reduce a cinco reglas, y los criterios de salida son la que todo el mundo se salta: criterios de entrada, criterios de salida, lógica de reinicio, reglas de propiedad y automatización. Los criterios de salida son la regla que dice que un registro sale de una etapa porque se descalifica, se convierte o se pierde. Sin ella tenéis zombis por construcción, en cada etapa, para siempre.

Las señales son siempre las mismas. MQLs sin siguiente paso. Deals parados en Demo Complete durante meses. Un informe de win rate que marca más del 100 por ciento porque closed-lost nunca se usó bien. Contactos duplicados con distintos lifecycle stages. Si veis eso, vuestro lifecycle no está gobernado, está adivinado.

Los propios valores de las etapas están rotos por dentro

Este es invisible desde la interfaz, y es la razón por la que no me fío de un informe de pipeline hasta haber mirado los valores internos.

En un proyecto con HeyReach, el pipeline de Tier 2 tenía una etapa Closed Won con el valor interno equivocado. No la etiqueta equivocada, el valor interno equivocado, que es lo que de verdad leen los informes y la automatización. Arreglarlo supuso crear la etapa correcta, migrar los deals y borrar la antigua, y bloqueó todo lo que venía detrás: 3,917 deals migrados con historial desde 2023 no se podían segmentar para los informes históricos de ingresos hasta que la propia etapa fuera correcta.

Esa es la forma de este tipo de bug. El gráfico sigue mostrándose. Simplemente el número está mal, y lleva años mal. El mismo modo de fallo que guardar los ingresos en una propiedad de texto de una sola línea: HubSpot os ofrece COUNT en vez de SUM y el dashboard parece estar bien.

La construcción: siete pasos, en este orden

El orden importa más que cualquier paso concreto. Saltaos el paso uno y el resto es automatización sobre un proceso sin definir, que es como se acaba con un workflow que cierra deals vivos.

1. Escribid criterios de salida para cada etapa, con la persona que lleva el proceso

De cinco a siete etapas, no más. Para cada una, escribid dos cosas: qué tiene que ser cierto para que un deal entre y qué tiene que ser cierto para que salga. Para salir hay tres puertas, no una: ganado, perdido o descalificado. Descalificado no es perdido, y juntarlos destruye vuestra capacidad de distinguir un problema de precio de un problema de targeting.

Haced esto en una sala con la persona responsable del proceso y exigid una segunda fuente. En Tech Barcelona, el conjunto de etapas acordado solo quedó cerrado al cruzar la respuesta de la responsable del proceso con un tracker independiente del estado de los contratos. Dos fuentes que coinciden son un hecho. El recuerdo de una persona es una hipótesis.

2. Instrumentad los relojes antes de automatizar nada

No podéis ramificar sobre una actividad que no habéis derivado. Construid primero las propiedades y luego escribid la lógica contra las propiedades. Nunca contra la actividad en bruto.

El conjunto mínimo en el deal:

• last_buyer_activity_date, que solo se rellena con interacción bidireccional, para que un rep que envía un quinto seguimiento no reinicie el reloj
• date_entered_current_stage, y un days_in_current_stage derivado
• close_date_push_count, que incrementa un workflow que se dispara cuando se actualiza la fecha de cierre (HubSpot no tiene un contador nativo para esto, y los hilos de la comunidad que lo piden vienen de hace años)
• stale_flag y stale_reason, escritos por la lógica de detección, nunca por una persona

Esto replica el rastro de auditoría que consideramos innegociable en los cambios de propietario: owner_assigned_date, owner_assignment_reason, previous_owner. El principio se traslada tal cual. Tres propiedades convierten un deal estancado de una opinión en un informe.

3. Detectad con una vista en vivo, no con un CSV

Materializad el conjunto de deals estancados como una vista guardada de HubSpot con filtros reales, no como una exportación mensual que alguien limpia a mano. Un CSV estático es una foto de un problema. Una vista es un sistema.

Empezad con estas vistas y ponedlas delante de los managers, no en una carpeta:

• Atascados 30 días o más en la etapa
• Sin actividad bidireccional del comprador en 21 días
• Fecha de cierre aplazada 3 veces o más
• Fecha de cierre en el pasado, deal todavía abierto
• Deal abierto, sin tarea de siguiente paso, sin reunión agendada

La cuarta, por sí sola, suele encontrar una cantidad sorprendente de pipeline. Un deal con una fecha de cierre de hace tres meses no es una previsión, es un recibo.

4. Primero la salvaguarda, siempre

Este es el paso que todo el mundo se salta, y saltárselo es como acabáis quitando el propietario de una oportunidad viva o cerrando automáticamente un deal el día antes de la firma.

La rama de salvaguarda va la primera en el lienzo del workflow, antes de que se ejecute cualquier lógica de detección. Cualquier señal real del comprador congela el deal: una respuesta, una reunión agendada, una propuesta vista, una prueba iniciada, una factura emitida. La señal gana a cualquier reloj.

Aquí hay una restricción dura que viene de nuestro propio protocolo de limpieza de CRM. Nuestras exclusiones de no tocar durante cualquier trabajo de higiene son los clientes activos, los deals abiertos y todo lo vinculado a ingresos. Los deals abiertos están en esa lista a propósito. Así que un sistema que actúa sobre deals abiertos tiene que ganarse la excepción, y se la gana no cerrando nunca nada de forma automática. Lo que nos lleva al paso cinco.

5. Marcad para revisión, no cerréis automáticamente

La automatización marca. Las personas cierran. No es timidez, es la misma regla que aplicamos a la deduplicación: marcar para revisión los registros sin coincidencia en vez de forzar la fusión, porque una fusión insegura que sobrescribe los datos del primer toque es peor que una coincidencia perdida. Un deal vivo cerrado automáticamente es peor que uno estancado que se quedó una semana de más.

La mecánica que funciona: la marca crea una tarea para el propietario del deal con un plazo de 5 días laborables y una notificación al manager. El rep hace una de tres cosas. Aporta pruebas y el deal se queda, con las pruebas registradas. Lo pasa a un estado de nurture o de reciclaje. O lo cierra con un motivo.

Después, etiquetad, no borréis. Un deal closed-lost con motivo y caducidad es un activo. Fijad la caducidad igual que fijamos las caducidades de supresión, por ejemplo un closed-lost de los últimos 180 días queda excluido de la prospección y después vuelve a estar en juego automáticamente. Borrar el registro solo significa que vuelve el trimestre siguiente por otra vía y sin memoria.

6. Haced snapshots del pipeline para que el historial deje de moverse

Un CRM sobrescribe el historial por defecto. Editáis un registro hoy y cambia el número del trimestre pasado, lo que significa que vuestro historial de pipeline no es un registro, es una representación del estado actual.

Haced snapshots del pipeline fechados e inmutables al cierre de cada trimestre, y guardadlos en propiedades en vez de confiar en que un informe los reconstruya. Es la misma razón por la que guardamos Initial MRR y Matured MRR como propiedades separadas en vez de en un único campo que va cambiando. Sin snapshots podéis limpiar el pipeline y luego no ser capaces de demostrar que la limpieza funcionó, porque la línea base se movió con vosotros.

7. Reportad el número de estancados cada semana, por motivo

Un número en el mismo dashboard donde vive el informe de rendimiento de los reps: deals abiertos marcados como estancados, en número y en importe, desglosados por motivo.

Ese desglose es un diagnóstico, no un marcador. Si domina «sin actividad del comprador», tenéis un problema de seguimiento y de enrutado. Si domina «antigüedad en etapa» en una etapa concreta, esa etapa no tiene criterios de salida o se han fusionado dos etapas en una. Si domina «fecha de cierre aplazada», vuestros reps están gestionando una conversación de previsión, no un deal. Y si el total no para de subir, la detección funciona y la descalificación no.

Después, congelad las etiquetas de motivo. Una vez definido, no redefináis nunca un motivo; añadid los nuevos con etiquetas nuevas. Si redefinís una etiqueta, perdéis la comparabilidad semana a semana, que es lo único que hace que valga la pena leer el informe.

La auditoría de pipeline de 20 minutos que podéis hacer hoy

Cinco comprobaciones. Podéis hacerlas en una llamada de descubrimiento, y yo las hago.

1. Pedid a dos reps que definan por separado los criterios de salida de la misma etapa. Respuestas distintas significan que la etapa no existe como concepto, solo como valor de un desplegable.
2. Filtrad los deals abiertos con fecha de cierre en el pasado. Cualquier cifra por encima de un puñado significa que nadie es responsable de la higiene de la previsión.
3. Comprobad los valores internos que hay detrás de vuestras etapas Closed Won y Closed Lost, no las etiquetas. Verificadlos contra lo que de verdad leen vuestros informes.
4. Ordenad los deals abiertos por días en la etapa actual, de mayor a menor, y mirad los veinte primeros. Preguntad qué tendría que ser cierto para que cada uno se cerrara este trimestre.
5. Pedid el snapshot del pipeline del trimestre pasado. Si nadie puede presentar uno que no haya cambiado desde entonces, no tenéis línea base ni forma de medir ninguna corrección.

Si falláis dos o más, el problema es vuestro modelo de datos, no vuestra capa de reporting. Si falláis cuatro, dejad de construir dashboards hasta que las etapas estén reconstruidas, porque solo estaréis mostrando la misma ficción más rápido.

Dónde se rompe esto

Dos advertencias honestas, porque prefiero que lo instaléis bien a que lo instaléis con entusiasmo.

Los umbrales dependen del ciclo. Una regla de 21 días de inactividad es correcta para un ciclo de venta de 45 días y directamente perjudicial en una motion enterprise con un ciclo de 9 meses y largos parones de compras. Comparad los umbrales con vuestro propio historial de closed-won antes de fijarlos. No copiéis los míos.

Y cada vez que desplegamos algo así, encontramos casos límite en los días siguientes. Renovaciones que están inactivas con toda legitimidad. Deals en pausa por el calendario fiscal del comprador. Contratos plurianuales donde la siguiente actividad real está a once meses vista. Ejecutad la detección en modo solo marcar durante un ciclo completo antes de asociarle ninguna consecuencia, y meted todo dentro de un chequeo de salud semanal, porque un workflow que dejó de ejecutarse en silencio parece idéntico a uno que funciona.

La parte que no es un problema de HubSpot

Nada de esto va realmente de HubSpot. Va de si vuestro pipeline es un modelo de cómo se compra en vuestra empresa o un conjunto de valores de desplegable que alguien escribió una vez. Con la arquitectura correcta, la herramienta es un detalle. Con la arquitectura equivocada, ninguna herramienta lo salva.

Un deal estancado no es un mal registro. Es una previsión que ya presentasteis a vuestro consejo.

Si queréis saber cuánto de vuestro pipeline es ficción antes de la próxima reunión del consejo, nuestro GTM Maturity and Revenue Leak Assessment es un diagnóstico de 30 minutos sobre cinco áreas, y os da un nivel de madurez, vuestras tres principales fugas de ingresos en dólares y el módulo que arregla la mayor. El pipeline suele ser la fuga número cuatro, y suele ser la más barata de arreglar.

Si ya sabéis que el problema son las etapas, ese trabajo forma parte de nuestro Revenue Machine Analysis, donde la arquitectura del lifecycle, las definiciones de etapa, los criterios de salida y los dashboards que los leen se diseñan como un solo sistema en vez de como cinco tickets.