Dos working sessions esta semana, el mismo cliente, la misma sala, dos problemas distintos en la pizarra, y uno de ellos era un diagnóstico silencioso de pipeline con el que el equipo llevaba sentado un año. Su head of sales abrió la pipeline oficial de HubSpot, recorrió los deal stages, y luego le hizo a la sala una pregunta que quedó suspendida por un segundo. ¿Qué pasa con los cincuenta SQL que no hemos movido todavía? Nadie respondió, porque nadie tenía la respuesta. Cincuenta leads que habían tomado un sales meeting, pasado la qualificación inicial, y estaban en algún lugar de un contact record con un lifecycle stage de SQL, pero sin deal record. Invisibles para el forecast. Invisibles para el pipeline review. Invisibles para la conversación de capacity del próximo trimestre. Esa brecha es la decisión estructural más cara que existe en instancias HubSpot B2B SaaS de mid-stage en este momento, y no tiene nada que ver con HubSpot. Tiene que ver con cuándo decide usted que el deal empieza.
Por qué esto importa ahora
El readout de Jason Lemkin de enero sobre el 2026 sales reckoning fue directo sobre el cambio estructural en marcha: los equipos B2B AI-native están operando bancos de sales aproximadamente la mitad del tamaño de sus predecesores, y el outbound impulsado por IA está generando una cuarta parte de la nueva pipeline en su propia organización en noventa días. Ese es el cuadro macro dentro del cual aparece esta brecha. Los equipos de sales reducidos por IA agravan el problema estructural, ya no hay una capa SDR que cure a mano la brecha entre un MQL y un deal record, así que el AE es quien corre la discovery, y el AE tiene todos los incentivos para diferir la creación del deal hasta estar seguro de que es real. Multiplique eso por diez reps y un trimestre, y obtiene el cajón de cincuenta SQL. Los forecasts no son incorrectos porque el modelo de close date sea malo. Son incorrectos porque la pipeline no contiene los deals.
Dónde vive la SQL gap en HubSpot
El lifecycle de HubSpot tiene forma de contact-property: subscriber, lead, MQL, SQL, opportunity, customer. El deal es un objeto separado que se crea, por lo general, cuando el lifecycle del contact pasa a opportunity. La convención es razonable en principio y un desastre en la práctica, porque la definición operativa de opportunity en la mayoría de los equipos de sales es «tengo suficiente confianza para committearlo a la pipeline». Ese umbral de confianza es sano, pero alto. Un meeting booked no es opportunity. Una primera discovery call no es opportunity. Ni siquiera un follow-up demo es opportunity si el budget no ha sido validado. Por eso un lead real puede pasar cuatro a ocho semanas en el lifecycle stage SQL, en un contact record, sin deal adjunto. El AE está haciendo trabajo. El sistema no muestra nada.
El cajón de cincuenta SQL es el resultado. No es un fallo de proceso. Es la arquitectura funcionando como fue diseñada, aplicada a una sales motion que ya no encaja en el esquema. El costo no es visible hasta el pipeline review, cuando alguien pregunta qué pasa entre el número de MQL del marketing y el conteo de deals de la deal pipeline, y nadie puede producir el puente.
La sabiduría dominante es crear el deal más tarde
El consejo estándar, el Q&A de Lemkin en SaaStr sobre exactamente esta pregunta es la formulación más limpia, es esperar. Convierta un lead en opportunity solo cuando ICP, pain, engagement y buying intent estén todos confirmados. El razonamiento es sólido. Cree deals demasiado pronto y la pipeline se infla, las coverage ratios se distorsionan, el forecast se vuelve ruido, y los reps pierden la disciplina de tratar un deal como un compromiso real. La formulación específica de Lemkin es que convertir demasiado pronto atasca pipelines y desperdicia recursos de sales; convertir demasiado tarde pierde momentum. La mayoría de los CROs lee eso y elige el lado más seguro: tarde.
Elija tarde y protege la forecast accuracy, pero renuncia a dos cosas que necesita más en 2026: pipeline visibility, y AE accountability sobre el trabajo in-flight que todavía no cuenta como deal. Los cincuenta SQL en el cajón son exactamente el trabajo que el AE está haciendo. No están en el sistema. Por lo tanto el AE no es responsable de ellos, el head of sales no puede verlos, el forecast no puede valorarlos, y el modelo de ramp no puede hacer capacity planning contra ellos. Es un precio demasiado alto por una coverage ratio limpia.
El stage pre-pipeline: una tercera opción
Lo que yo recomendaría no es ni tarde ni temprano. Es ambos, separados por un filtro. Cree el deal al meeting booked: la señal más barata y confiable de que un AE comprometió tiempo y el prospect comprometió calendario, pero créelo en un deal stage llamado pre-pipeline, con una win probability por defecto de cero o cinco por ciento, que está filtrada fuera de cada reporte de forecast, widget de dashboard, cálculo de coverage y vista de weighted pipeline en la instancia. El deal existe para accountability, visibility y tracking. No existe para el forecast. Hasta que se gane su lugar en la pipeline pasando un exit criterion definido, no se agrega en ningún número de revenue en ningún lado.
Es la jugada keep-edit-delete aplicada a la arquitectura misma. La regla estándar «crear el deal a la qualificación» tenía adentro dos propósitos que hacían trabajos distintos: proteger el forecast del ruido, y reservar el deal record para el trabajo comprometido. El stage pre-pipeline mantiene el primer propósito intacto a través del filtrado, y edita el segundo diciendo que el deal record puede llevar trabajo no comprometido siempre que esté segregado. El forecast queda limpio. El cajón de cincuenta SQL deja de existir.
Tres guardrails
El stage pre-pipeline solo funciona si tres filtros son no-negociables desde el día uno. Si cualquiera de ellos es blando, el bloat regresa colándose en un trimestre, y el head of sales revierte el cambio.
Primero, todo reporte de forecast, widget de dashboard y cálculo de pipeline coverage debe filtrar el stage pre-pipeline como condición por defecto. No un filtro opt-in. Un default. Audite cada vista guardada, cada dashboard CRO, cada deck de weekly forecast meeting. Si un solo chart muestra pre-pipeline junto a pipeline qualified como la misma columna, ha perdido la disciplina que justifica la arquitectura.
Segundo, la win probability por defecto de pre-pipeline es cero o cinco por ciento, nunca más alta. Algunos equipos estiran a diez a treinta por ciento porque les parece más honesto. Resista. El punto es que el número de weighted pipeline no puede moverse según lo que esté en pre-pipeline. Cero es el más limpio, cinco es aceptable, cualquier cosa por encima invita a deals pre-pipeline a aparecer en proyecciones de revenue el momento en que alguien cambia un filtro.
Tercero, los deals pre-pipeline se auto-archivan con una regla dura de no-advance a noventa días. Un workflow de HubSpot revisa los deals pre-pipeline cada noche. Si el stage no ha cambiado en noventa días, el deal pasa a Closed Lost con un lost reason de «no advance from pre-pipeline». Sin excepciones, sin extensiones. El problema de zombie deals que arruina las pipelines en late-creation también arruina pre-pipeline si lo deja. La regla de noventa días es lo que mantiene a pre-pipeline visible y pequeño.
Un patrón del campo
Recientemente trabajamos con un equipo B2B SaaS Series B en DACH que corría una mid-market motion con un banco de AE pequeño y sin capa SDR. Cada pipeline review trimestral chocaba con la misma pared. El head of sales recorría la pipeline oficial, veinte o treinta deals de qualified hasta commit, y luego preguntaba al equipo por «los que no hemos movido formalmente todavía». La respuesta era siempre una variante de «estoy esperando la confirmación de budget», o «quiero asegurarme de que pasen la discovery limpios antes de abrir un deal». Los AEs no se equivocaban en ninguno de los dos puntos. Estaban aplicando la regla de late-creation tal como está escrita. El resultado era que aproximadamente la mitad del trabajo in-flight real del equipo estaba fuera del sistema. La pipeline coverage se veía flaca. El modelo de capacity del próximo trimestre decía que estábamos sub-aprovisionados. Ambas lecturas eran incorrectas; el equipo llevaba más pipeline de la que la instancia reportaba.
Añadimos un stage pre-pipeline como nuevo primer stage en la deal pipeline, lo defaulteamos a cero por ciento de win probability, y reescribimos cada vista de forecast para que lo filtrara fuera. El workflow meeting-booked ya estaba cableado a través de su herramienta de scheduling; lo extendimos para crear un deal pre-pipeline automáticamente y asociarlo al contact y a la company. Dentro de dos semanas, el conteo de deals visible para el equipo se duplicó. Dentro de tres semanas, el head of sales filtró a non-pre-pipeline y confirmó que el número de forecast no se había movido, esa era la prueba que queríamos pasar. Dos meses después, el pipeline review meeting se había reestructurado solo: la primera mitad corría la pipeline oficial como antes, la segunda mitad corría una lista pre-pipeline ordenada con una pregunta por deal, cuál es el próximo movimiento para sacar este de pre-pipeline. El cajón de cincuenta SQL dejó de existir. La conversación de capacity del próximo trimestre se movió de especulativa a específica.
Cómo cablear el stage pre-pipeline en HubSpot
- Añada un nuevo primer stage a su deal pipeline principal. Llámelo «pre-pipeline» o «engaged», el label importa menos que la disciplina de filtrado que viene después. Configure la win probability por defecto a cero por ciento. Mantenga el tipo de stage como open stage, no closed.
- Construya el workflow meeting-booked. Trigger: se reserva un meeting en el calendario de un sales rep a través de su herramienta de scheduling (la herramienta meetings nativa de HubSpot, o el scheduler que esté cableado). Enrollment criterion: el tipo de meeting es una conversación de sales, no un customer touchpoint. Actions, crear un deal en el stage pre-pipeline, asociarlo al contact y a su primary company, configurar deal owner al meeting host, configurar deal name a un string templated con nombre del contact y fecha del meeting.
- Audite cada reporte de forecast, widget de dashboard y cálculo de pipeline coverage en la instancia. Añada un filtro a cada uno: deal stage no es igual a pre-pipeline. Vistas por defecto, dashboards por defecto, decks de weekly forecast meeting, widgets de CRO summary. Todos. Si se salta uno solo, la disciplina que justifica la arquitectura empieza a tener fugas el día en que alguien muestra un chart en un board meeting.
- Construya un reporte separado de pre-pipeline review. Ordene por último engagement, luego por ICP fit score. Es el artefacto desde el cual los AEs y sus managers trabajan en la segunda mitad de los pipeline review meetings. Pregunta distinta por fila, no «está en camino a cerrar» sino «cuál es el próximo movimiento para sacar este de pre-pipeline».
- Defina el exit criterion. El mínimo que usamos es una discovery SPICED-validada: situation, pain e impact confirmados por escrito en el deal record o en una discovery note vinculada. Una vez confirmados esos tres, el deal avanza a su primer qualified stage (llámelo «qualified», «discovery complete» o como se llame su segundo stage en su instancia). El exit criterion es la diferencia entre un stage pre-pipeline limpio y una expansión lenta del problema de bloat que intentaba resolver.
- Construya el workflow auto-archive. Trigger: un workflow agendado diario. Filtro: deal stage igual a pre-pipeline AND fecha de último cambio de deal stage hace más de noventa días. Action, mover el deal a Closed Lost, configurar lost reason a «no advance from pre-pipeline», notificar al deal owner. Noventa días es el número correcto para la mayoría de las sales motions B2B SaaS mid-market. Para motions enterprise con ciclos de budget anuales, ciento veinte días es defendible. No más alto.
- Reestructure el pipeline review meeting. Primera mitad: pipeline oficial. Segunda mitad: pre-pipeline. Pregunta distinta. Cadencia distinta. Owner distinto de la conversación si tiene uno. La separación estructural en el meeting es lo que le enseña al equipo que la separación arquitectónica en el sistema es real, no un filtro caprichoso.
Dónde entra Checkpoint
La mayoría de nuestras implementaciones HubSpot que tocan la arquitectura de deal-stage terminan entregando una versión del stage pre-pipeline. No es una HubSpot best practice, la guidance oficial sigue defaulteando a la regla de late-creation, y no es un cambio de configuración de una línea. Es una decisión arquitectónica con tres guardrails que deben respetarse. El payoff es lo que aparece en el próximo pipeline review. Los cincuenta SQL calientes en el cajón se convierten en veinte deals pre-pipeline que usted puede ver, conversar y priorizar, mientras el número de forecast queda exactamente tan preciso como antes. Si su instancia de revenue operations tiene un cajón silencioso de SQL contra los que nadie está haciendo forecast y que nadie puede encontrar, el stage pre-pipeline es el cambio arquitectónico más pequeño que arregla el problema de visibility sin romper el forecast.
Fuentes
- Lemkin, Jason. «The 2026 Sales Reckoning: Why Your Traditional Sales Team Is About To Look Very Different.» SaaStr, enero de 2026. saastr.com
- Lemkin, Jason. «Dear SaaStr: At What Point Should a Lead Convert to an Opportunity?» SaaStr. saastr.com