Por lo general, cuando un revenue leader nos pide que arreglemos el forecast, el forecast no es el problema. Las etapas del pipeline subyacentes han dejado de significar lo mismo para los reps que mueven los deals a través de ellas. Discovery es la primera call de un rep y un mutual action plan firmado para otro. Closed Won es contrato firmado en un equipo y kickoff agendado en el otro. La aritmética de conversión es correcta y operativamente inútil, los números cuadran contra definiciones que nadie comparte.
Por qué importa ahora
La presión sobre las definiciones de las etapas ha empeorado, no mejorado, desde que la AI empezó a aparecer dentro del funnel. La pieza de Sinha, Shastri, Lorimer y Mantrala de septiembre en Harvard Business Review sobre equipos de ventas creciendo junto con la AI hizo el siguiente argumento: los equipos que avanzan son los que tratan la AI como una capa de coaching y orquestación sobre un proceso de ventas ya limpio, no como un sustituto de uno. Esa es la asimetría. Si las definiciones de sus etapas son ajustadas, el tooling agéntico acelera un sistema que ya funciona. Si están sueltas, la AI automatiza alegremente la deriva, enrutando deals contra una señal de etapa que ya significa tres cosas distintas.
El diagnóstico: «Closed Won» significa tres cosas distintas para tres reps
Ejecute un pequeño test en su propia instancia. Saque las últimas docenas de deals que pasaron de una etapa como propuesta-enviada a una como negociación, y pregunte a cada rep qué significaba esa transición. Obtendrá respuestas como: el pricing fue enviado; el pricing fue enviado y reconocido; el pricing fue enviado, reconocido y procurement está involucrado; el pricing fue enviado y el champion dijo verbalmente que sí. Cuatro realidades operativas, un valor de etapa, un modelo de forecast que las trata como equivalentes.
Esto no es un problema de disciplina del rep. Es un problema de definición. Los reps están haciendo lo que la gente siempre hace cuando un sistema da inputs ambiguos: rellenan la ambigüedad con su propia definición de trabajo, y luego el equipo optimiza alrededor del hueco. Por eso las pipeline reviews acaban sintiéndose como interrogatorios. El manager no está en realidad revisando el deal; está haciendo ingeniería inversa de lo que el rep quiso decir con la etapa.
La plantilla de criterios de entrada/salida en una página
El arreglo es pequeño y poco glamuroso. Cada etapa del pipeline obtiene cuatro líneas en una sola página compartida:
- Definición en una frase. Lo que esta etapa es, en un lenguaje que un nuevo rep pueda leer en su tercer día y aplicar de inmediato. Si no puede escribirla en una frase, la etapa hace dos trabajos y necesita partirse.
- Criterios de entrada. Aquello específico y verificable que tiene que ser cierto en el deal record para que la etapa se inicie. «Champion ha confirmado que existe presupuesto este año fiscal, capturado en la propiedad Budget Confirmed.»
- Criterios de salida. Aquello específico y verificable que tiene que ser cierto para que el deal salga de la etapa hacia adelante. Distinto de la entrada, esa es la idea.
- Owner. El rol responsable de la transición. A veces el AE; a veces el SE; a veces el deal desk. Nombrar al owner es lo que convierte la etapa en un paso de proceso en lugar de una etiqueta.
Esta es la plantilla completa. Cabe en una página. El coste no está en escribirla. El coste está en el desacuerdo que aflora mientras la escriben: por eso la plantilla solo funciona como workshop, no como documento entregado a una persona para que lo redacte sola.
Recorriéndolo en un deal: qué pasa en cada borde de etapa
Por ejemplo: un equipo B2B SaaS con el que trabajé recientemente tenía un pipeline de seis etapas. La etapa intermedia, llamémosla la etapa de evaluación, no tenía criterios de entrada y unos criterios de salida que coincidían con los de entrada de la siguiente etapa casi palabra por palabra. Funcionalmente, la etapa era un aparcamiento. Los deals vivían allí una mediana de tres semanas más que en cualquier otra etapa, y el equipo había aceptado en silencio que así funcionaba el medio del pipeline. Cuando ejecutamos el workshop de reescritura, en los primeros 20 minutos pasaron dos cosas. Los AEs se dieron cuenta de que usaban esa etapa para indicar que el deal se había estancado y no querían perderlo del forecast. El CRO se dio cuenta de que la etapa existía porque alguien hace cinco años quería un sitio para trackear POCs y nadie la había revisado desde entonces. La decisión fue directa una vez ambas cosas estuvieron en la misma página, partirla. Los POCs obtuvieron su propia etapa con su entrada y salida; la versión-aparcamiento de la etapa intermedia se borró.
Por eso importa el workshop. El artefacto al final es la página. El trabajo es la afloración.
Etapas que no se pueden definir
Algunas etapas sobreviven la reescritura limpiamente. Otras no. El patrón, tras ejecutar esto en suficientes instancias de HubSpot como para haber perdido la cuenta: alrededor de un tercio de las etapas necesitan ajuste de definición pero se mantienen; alrededor de un tercio necesitan partirse en dos porque hacen dos trabajos operativos distintos; el resto se fusionan o se borran. Si no puede escribir una definición en una frase en la sala, la etapa no es una etapa. Es un flag, y debería vivir como una propiedad en el deal record, no como una posición de pipeline.
Etapas operativas vs. de reporting
Por un lado, sus reps necesitan etapas que coincidan con lo que realmente hacen cada día: la forma de la acción, la siguiente call, el artefacto necesario para avanzar. Por otro lado, su CFO necesita etapas que se agreguen limpiamente en un modelo de forecast que aguante a nivel de board. Esas dos necesidades no siempre tienen la misma forma. La forma en que tiendo a resolverlo: mantener las etapas del pipeline operativas (orientadas al rep, con forma de acción, cuatro a seis) y usar una propiedad de forecast category separada, commit, most-likely, best-case, pipeline, que el manager posee. El rep mueve la deal stage; el manager asigna la forecast category. Campos distintos, owners distintos, sin pelea sobre lo que una sola columna debe significar.
Patrón de campo
Un equipo B2B SaaS de DACH en Series B vino a nosotros pidiendo ayuda con el forecasting. El problema declarado por el CRO era que el forecast ponderado fallaba por un margen significativo cada trimestre. El problema real, surgido en la primera sesión de trabajo, era que el pipeline de ocho etapas tenía tres etapas con criterios de salida solapados y una etapa que el equipo SDR usaba como cajón para leads no cualificados. Ejecutamos la reescritura como un workshop de dos horas con los AE leads, el SDR lead, el CRO y el RevOps lead en la sala. El output: pipeline reducido de ocho etapas a cinco; una etapa promovida a propiedad; una etapa partida porque POCs y pilotos pagados eran motions distintas. El modelo de forecast reconstruido contra la nueva arquitectura aterrizó dentro del diez por ciento del real al trimestre siguiente, no porque la matemática se hubiera vuelto más lista, sino porque los inputs por fin significaban algo.
Resolución: un playbook para la reescritura
Si está a punto de ejecutar esto en su propia instancia, el orden importa:
- Bloquee dos horas y meta a la gente correcta en la sala. AE leads, el lead SDR o BDR si su top of funnel es compartido, el CRO y quien posea RevOps. Sin espectadores. El desacuerdo es el trabajo.
- Recorra el pipeline actual etapa por etapa y lea las definiciones existentes en voz alta. Si no hay definición escrita, pídale a cada rep en la sala que escriba una en 60 segundos y compárenlas. Las divergencias son el diagnóstico.
- Para cada etapa, rellene las cuatro líneas. Definición, entrada, salida, owner. Si la sala no se pone de acuerdo en una definición de una frase en tres minutos, la etapa hace dos trabajos. Pártala.
- Marque cualquier etapa donde los criterios de entrada y salida coincidan. Eso no es una etapa; es una propiedad de deal disfrazada. Promuévala a propiedad y quítela del pipeline.
- Decida operativo vs. reporting ahora, no después. Las etapas del pipeline se mantienen orientadas al rep y con forma de acción. La forecast category se vuelve un campo separado del manager.
- Configure los cambios en HubSpot antes de que nadie salga de la sala. Nombres de etapa, criterios de entrada/salida capturados como propiedades requeridas o gates de workflow, asignaciones de owner. Si difiere la configuración, el acuerdo se descompone en una semana.
- Re-establezca la base del forecast contra la nueva arquitectura. Las tasas de conversión antiguas no se transfieren. Ejecute las próximas dos pipeline reviews contra las nuevas etapas antes de volver a confiar en el modelo.
Dónde entra Checkpoint
Las reescrituras de etapas de pipeline son una de las sesiones de trabajo más comunes que ejecutamos dentro de los compromisos de RevOps en Checkpoint: habitualmente en el primer mes, casi siempre antes de cualquier trabajo de forecasting o reporting. Si su forecast está fallando, la matemática de conversión no le inspira confianza, o sus reps están peleando sobre lo que significa una etapa en pipeline review, este es el workshop a ejecutar antes de gastar otro trimestre modelando sobre definiciones que nadie comparte.
Noah Charak