La mayoría de las instancias B2B de HubSpot que heredo tienen un pipeline que hace dos trabajos. El pipeline de deals registra el trabajo comercial del AE (discovery, calificación, propuesta, negociación) y además registra trabajo operativo que el AE no controla: generación de ofertas, validaciones de ajuste técnico, KYC, aprobación de contratos y, a veces, onboarding. El instinto de modelar todo eso como etapas del deal resulta ordenado en una pizarra. En un sistema de ingresos real produce un pipeline lento e imposible de proyectar, donde el AE es un coordinador y los datos son incorrectos.
Por qué importa ahora
Comprar en B2B no se ha vuelto más simple. En 2012, Brent Adamson, Matthew Dixon y Nick Toman sostuvieron en Harvard Business Review que la función tradicional del vendedor (descubrir necesidades y recomendar una solución) ya estaba siendo absorbida por áreas de compras sofisticadas y por un lado comprador que llega con sus propias respuestas. La versión de ese problema que veo en HubSpot en 2026 es estructural. En los procesos comerciales con mucho servicio (energía y utilities, industria regulada, hardware más onboarding), la decisión de compra depende de trabajo que ocurre fuera de la jornada del AE. Modelar ese trabajo como etapas del deal no vuelve al AE más estratégico. Convierte el pipeline de deals en un gestor de proyectos de la cola de otra persona.
El patrón: un workflow es de ventas, el otro es de operaciones
Una pregunta de diagnóstico útil para cada pipeline que reviso: ¿quién tiene que actuar para que esta etapa avance? Si la respuesta es sistemáticamente el AE, es una etapa de ventas. Si la respuesta es sistemáticamente otra persona (un deal desk, un equipo de ofertas, un revisor de cumplimiento, un líder de CS, un ingeniero de onboarding), es trabajo operativo, y el AE no tiene la capacidad de impulsarlo en un plazo que se pueda proyectar.
El error habitual es comprimir el trabajo operativo dentro del pipeline de deals como etapas del tipo «oferta en curso», «revisión de cumplimiento» o «a la espera de contrato». Entonces el AE es responsable de un pipeline que no puede mover. La precisión del forecast se desploma porque la antigüedad en cada etapa está dominada por el tiempo de cola en una función sobre la que el AE no tiene control operativo. Las tasas de conversión entre etapas dejan de significar algo, porque el ritmo al que los deals salen de una etapa de revisión de cumplimiento no tiene nada que ver con la ejecución comercial.
La arquitectura de dos pipelines
La arquitectura que recomendaría en HubSpot para cualquier proceso comercial condicionado por servicios son dos pipelines que funcionan en paralelo:
Pipeline de deals, a cargo del AE
Las etapas reflejan decisiones comerciales que el AE realmente impulsa: discovery, calificado, oferta, contratación, closed won, closed lost. Las transiciones de etapa dependen de evidencia que el AE puede controlar: un resumen de discovery registrado, un ajuste confirmado, una oferta solicitada, un contrato firmado recibido. El AE es proyectable en este pipeline porque cada etapa avanza con algo que él mismo puede hacer.
Pipeline de tickets, a cargo de RevOps o del equipo de operaciones
Debajo del deal hay un ticket en un pipeline separado, a cargo de la función que realiza el trabajo operativo: oferta solicitada, datos validados, oferta generada, cumplimiento aprobado, contrato enviado. Cada etapa representa trabajo que ese equipo efectivamente realiza. El ticket tiene sus propios SLAs, su propia cola, sus propios responsables y sus propios informes. RevOps o el equipo de ofertas es proyectable en este pipeline porque, de nuevo, cada etapa avanza con algo que puede hacer.
La compuerta entre ambos
El deal no puede llegar a Closed Won hasta que el ticket asociado esté cerrado. Esa compuerta es todo el sentido de la arquitectura. El AE no queda bloqueado para vender mientras el ticket está en curso; el deal puede permanecer en la etapa de contratación indefinidamente. Pero Closed Won, la etapa que determina las reservas, las comisiones y el forecast de ingresos, solo se activa cuando operaciones ha terminado su trabajo. El pipeline de deals pasa a reportar el rendimiento comercial. El pipeline de tickets reporta el rendimiento operativo. La compuerta garantiza que ambos sigan acoplados.
Compuertas de campos obligatorios y la capa de validación de datos
La arquitectura de dos pipelines solo se sostiene si el handoff entre el AE y operaciones es limpio. El punto de fallo más común es el momento en que el AE crea un ticket: el equipo de operaciones necesita un conjunto definido de datos (dirección del sitio, capacidad, especificaciones técnicas, entidad del cliente para el KYC, selección de la plantilla de contrato) y, la mayoría de las veces, no los recibe. La solución son compuertas de propiedades obligatorias en la etapa del deal que dispara la creación del ticket.
Lo que haría: definir los datos que el equipo de ofertas necesita antes de empezar. Hacer que esas propiedades sean obligatorias para mover el deal de calificado a oferta. El workflow que crea el ticket copia esas propiedades. La tarea del AE en el handoff es completar el formulario, no perseguir al equipo de ofertas para pedir novedades.
Los disparadores del handoff entre el AE y RevOps
La configuración técnica en HubSpot es sencilla. Un workflow basado en deals se dispara con el cambio a la etapa de oferta, crea un ticket en el pipeline de ofertas, coloca el ticket en su primera etapa, copia las propiedades obligatorias del deal y asocia el ticket con el deal y el contacto. Un workflow basado en tickets se dispara cuando el ticket llega a la etapa de cumplimiento aprobado y actualiza una propiedad del deal, algo como offer_status, que lee un panel orientado al AE. Cuando el ticket se cierra, un último workflow cambia una propiedad del deal que permite al AE mover el deal a Closed Won.
Nada de esto es exótico: son los mismos bloques de workflow que tiene cualquier instancia de HubSpot. Lo que importa es la decisión de arquitectura: el trabajo pertenece a su propio pipeline, el pipeline del AE está condicionado en lugar de bloqueado, y los dos sistemas se coordinan mediante un pequeño conjunto de propiedades con nombre.
Un patrón visto en el terreno
Una pyme energética alemana con un proceso de hardware más onboarding llegó a nosotros con un único pipeline de deals de once etapas. Aproximadamente la mitad de esas etapas eran operativas: oferta en curso, revisión técnica, KYC, revisión del contrato, firma. Los forecasts de los AE eran poco fiables porque, en cualquier trimestre, la mayor parte de la antigüedad en etapa era tiempo de cola en operaciones. La solución fue un pipeline de deals con etapas de ventas a cargo del AE y un pipeline de tickets separado con etapas operativas a cargo del equipo de ofertas. Un workflow de deal a ticket se ejecutaba en la transición de etapa con validación de campos obligatorios; la compuerta de Closed Won era una propiedad del deal que se actualizaba al cerrarse el ticket. Después del cambio, el equipo de ofertas tuvo su propia cola y sus propios SLAs, el forecast del AE empezó a comportarse como un forecast, y la revisión semanal del pipeline pasó de «dónde está mi oferta» a «cuál es el siguiente paso comercial».
Resolución: el playbook de los dos pipelines
Si hoy gestiona en HubSpot un proceso comercial condicionado por servicios, este es el orden en que yo ejecutaría el cambio:
- Audite su pipeline de deals actual. Para cada etapa, pregúntese si el AE es dueño de la acción que la hace avanzar. Haga una lista de las etapas que no pasan la prueba: son trabajo operativo en el pipeline equivocado.
- Diseñe el pipeline de tickets paralelo. Las etapas reflejan lo que el equipo de operaciones realmente hace, en el lenguaje que realmente usa. Los responsables, los SLAs y la asignación de cola se definen por etapa.
- Defina las propiedades del handoff de deal a ticket. El conjunto mínimo de datos que el equipo de operaciones necesita antes de poder empezar. Hágalas obligatorias para avanzar en la etapa del deal que dispara la creación del ticket.
- Construya los workflows. Un workflow crea el ticket en la transición de etapa y copia las propiedades. Un segundo workflow actualiza el deal cuando el ticket llega a un punto de control relevante. Un tercero cierra el ciclo cuando el ticket se cierra.
- Condicione la etapa Closed Won al cierre del ticket. El deal no puede pasar a Closed Won a menos que el ticket asociado esté cerrado. Aplíquelo con una regla de validación o una verificación de propiedad obligatoria.
- Reconstruya los paneles sobre el nuevo límite. El forecast del AE y los informes de conversión se ejecutan sobre el pipeline de deals. El rendimiento operativo, el cumplimiento de SLAs y la antigüedad de la cola se ejecutan sobre el pipeline de tickets. Deje de reportar ambos desde el mismo gráfico.
- Capacite al equipo de AEs en el nuevo modelo. La objeción más común es que el AE «no puede ver qué pasa con la oferta». La respuesta es un panel del lado del deal alimentado por las propiedades del ticket, no volver a un solo pipeline.
Haga estas siete cosas y el cambio toma unas pocas semanas; el forecast empieza a ser honesto en un trimestre. Si se salta el primer paso, diseñará un pipeline paralelo con el mismo problema de límites que el que está reemplazando.
Dónde interviene Checkpoint
La mayoría de los pipelines de HubSpot que rediseñamos en Checkpoint tienen esta patología: un pipeline de ventas que hace trabajo operativo, un forecast que no se comporta como tal y un equipo que ha dejado de confiar en los datos. La solución rara vez es una propiedad nueva o un panel más inteligente. Es una decisión de arquitectura sobre qué trabajo pertenece a qué pipeline, a cargo de qué función y condicionado por qué evidencia. Esa decisión se sitúa en la frontera entre RevOps y las operaciones de customer success. Si su pipeline carga con trabajo operativo que no puede proyectar, esa es la conversación que conviene tener.
Harmeet Obhrai