Hay dos formas de arruinar un pipeline con el número de etapas.
La primera es tener muy pocas. Tan pocas que no puedes distinguir en qué punto real del proceso está cada deal, y el pipeline se convierte en un semáforo de dos colores: abierto o cerrado.
La segunda es tener demasiadas. Tan detalladas que nadie las actualiza, los deals se quedan estancados por semanas en etapas intermedias que nadie entiende bien, y el CRM empieza a reflejar la parálisis del equipo en lugar del avance real del comprador.
Los dos extremos producen el mismo resultado: un pipeline que no te dice la verdad.
Si prefieres verlo en video, aquí lo explico:
Con muy pocas etapas, no puedes hacer forecast real. No puedes detectar dónde se estancan los deals. No puedes saber si el problema está en la calificación, en la propuesta, o en la negociación. Solo ves un gran bloque de "en proceso" que mezcla todo.
Hay equipos que trabajan con algo así: Prospecto → En proceso → Cerrado.
Suena limpio. Suena ágil. El problema es que "en proceso" puede significar cualquier cosa. Puede ser un deal que tuvo una reunión de descubrimiento hace dos semanas y no ha avanzado, o puede ser un deal donde el decisor ya revisó la propuesta y están negociando términos. Para el sistema, son lo mismo. Para la realidad del negocio, no tienen nada que ver.
Un pipeline con muy pocas etapas no es ágil. Es ciego.
Más etapas no es más visibilidad. Es más ruido. Datos inútiles. Conversiones entre etapas que no reflejan nada real. Reportes que el gerente deja de creer porque nunca cuadran con lo que le dicen los vendedores en la reunión de pipeline.
En el otro extremo están los pipelines hiperesquematizados. Los he visto con doce, quince, hasta dieciocho etapas. Alguien, en algún momento, pensó que más detalle era mejor visibilidad.
El problema es que un vendedor con quince etapas deja de razonar sobre en cuál está el deal y empieza a adivinar. O peor, empieza a saltarse etapas. El deal pasa de "Descubrimiento completado" directamente a "Contrato enviado" sin pasar por "Propuesta revisada" ni "Términos acordados", porque el vendedor no vio la diferencia o simplemente no quiso hacer clic cuatro veces.
El rango que funciona para la mayoría de los equipos B2B con ciclos de venta medios es entre cinco y siete etapas. No porque sea un número mágico, sino porque es el rango donde puedes tener suficiente granularidad para diagnosticar el pipeline y suficiente simplicidad para que el equipo lo mantenga actualizado.
La respuesta honesta: depende. Pero no depende de tu preferencia personal ni de la plantilla que viene por defecto en tu CRM. Depende de dos cosas.
Primero, la complejidad real de tu proceso de compra. No tu proceso de venta, el proceso de compra del comprador. Si tu cliente típico tarda dos semanas en decidir, no necesitas doce etapas. Si tu cliente pasa por evaluación técnica, comité de compras, legal y finanzas antes de firmar, probablemente sí necesitas más puntos de control.
Segundo, tu capacidad de exigir evidencia en cada etapa. Esto conecta directamente con lo que vimos en el tercer artículo de esta serie. Cada etapa que agregas es una etapa donde tienes que poder definir qué evidencia demuestra que el hito se cumplió. Si no puedes definir la evidencia, no necesitas la etapa. Es una etapa fantasma.
Una buena regla práctica: si ves que más del 60% de tus deals están estancados en la misma etapa durante semanas, no es un problema de ventas. Es un problema de diseño del pipeline. O esa etapa no tiene criterios claros de salida, o no refleja un hito real del proceso de compra.
El objetivo de tener etapas bien definidas no es solo tener un pipeline "prolijo". Es poder diagnosticar. Si tu pipeline tiene las etapas correctas, puedes responder estas preguntas con datos:
Si no puedes responder esas preguntas, una de dos cosas está pasando: o tienes muy pocas etapas para ver el detalle, o tienes tantas que nadie las actualiza consistentemente.
Hay un tipo de etapa que aparece mucho en los pipelines que auditamos en Revops LATAM y que destruye la visibilidad de una forma particular. La llamo "etapa de cortesía". Son etapas que existen para darle al vendedor un lugar donde poner deals que no avanzan pero tampoco quiere perder.
"Esperando respuesta del cliente." "En evaluación interna." "Pendiente de presupuesto."
Esas no son etapas. Son sala de espera. Y la sala de espera de un pipeline es donde los deals van a morir lentamente mientras inflan tu forecast.
Si en tu pipeline existe una etapa cuya función real es "guardar deals que no sé qué hacer con ellos", tienes que eliminarla. Un deal que lleva tres semanas sin movimiento verificable no está "en evaluación". Está perdido, y lo que tiene que pasar es que lo descalifiques o definas un próximo paso concreto con fecha.
No. Cuando defines las etapas de tu pipeline, hay un principio que simplifica todo: cada etapa debe representar un solo hito del proceso de compra. No dos. No un hito y medio. Si tienes una etapa que se llama "Reunión de descubrimiento y envío de propuesta", tienes dos etapas mezcladas en una.
Y eso genera un problema específico: el deal entra a esa etapa cuando terminó la reunión, pero sale cuando se envió la propuesta. Entonces tienes deals que "están" en esa etapa pero en realidad están esperando que suceda algo completamente distinto a lo que ya sucedió.
Una etapa, un hito. Claro, verificable, en pasado.
Esto va directo al corazón del diseño del pipeline: si hay deals que pasan por esa etapa y deals que no, la etapa no debería existir como etapa. Una etapa del pipeline es un hito que el 100% de los deals tiene que atravesar. No el 80%. No "la mayoría". Todos.
Si tienes una etapa que se llama "Demo técnica" pero hay deals que cierran sin demo técnica porque el comprador ya conocía el producto, esa etapa no es una etapa del pipeline. Es una actividad opcional. Y las actividades opcionales tienen su lugar en las tareas del CRM, en los playbooks de venta, en los checklists del vendedor. No en las etapas del pipeline.
El test es simple: ¿puede un deal llegar a Cerrado sin pasar por esta etapa? Si la respuesta es sí, sácala del pipeline. No significa que esa actividad desaparezca. Significa que no tiene que ser una etapa universal. Puede ser un campo, una tarea, una nota. Pero no un paso obligatorio en el recorrido.
Cuando permites etapas opcionales, el pipeline deja de ser un modelo del proceso de compra y se convierte en un árbol de decisiones que nadie puede leer de la misma forma. Cada vendedor empieza a omitir las etapas que no aplican a su deal "porque este cliente era distinto", y pierdes toda la capacidad de comparar deals, medir conversiones y diagnosticar dónde se rompe el proceso.
Es una pregunta que aparece con frecuencia: "Tenemos deals pequeños que cierran en dos semanas y deals grandes que tardan seis meses. ¿Usamos el mismo pipeline?" La respuesta generalmente es no. Si el proceso de compra es suficientemente distinto, necesitas pipelines separados.
No porque las etapas sean conceptualmente diferentes, sino porque la granularidad que necesitas para gestionar un deal de $2,000 es distinta a la que necesitas para gestionar uno de $200,000.
Un deal pequeño puede vivir perfectamente en un pipeline de cuatro o cinco etapas. Uno enterprise, donde el comprador pasa por evaluación técnica, legal y aprobación de directorio, probablemente necesita más puntos de control.
La clave es no forzar a todos los deals a pasar por el mismo embudo cuando los procesos de compra son estructuralmente distintos. Eso también contamina el forecast, porque mezcla velocidades y tasas de conversión que no son comparables.
Cinco capas: criterios de entrada y salida, etapas en pasado, inspeccionabilidad, calificación previa y el número correcto de etapas. Sin estas cinco capas, el CRM amplifica el desorden. Con las cinco, amplifica el proceso. Esta serie lleva cinco artículos construyendo un pipeline sólido desde los cimientos:
Capa 1 (primer artículo): Criterios de entrada y salida. La regla de qué tiene que pasar para que un deal avance.
Capa 2 (segundo artículo): Etapas como hitos del comprador, en pasado. El nombre mismo de la etapa como criterio.
Capa 3 (tercer artículo): Inspeccionabilidad. La evidencia obligatoria que convierte la regla en algo verificable.
Capa 4 (cuarto artículo): Calificación antes del pipeline. Dos pistas separadas para no contaminar el forecast desde el día uno.
Capa 5 (este artículo): El número correcto de etapas. Suficiente granularidad para diagnosticar, suficiente simplicidad para que el equipo lo mantenga vivo. Y ninguna etapa que se pueda saltar.
Proceso primero. Herramienta después.
Nos vemos en el próximo artículo de esta serie.