En Revops LATAM esto lo escucho todo el tiempo: "Ya tenemos nuestro proceso comercial documentado, está en el CRM".
Abro el CRM. Miro el pipeline. Y lo que veo es una lista de tareas del vendedor disfrazada de proceso.
Llamar al prospecto. Agendar reunión. Tener la reunión. Enviar propuesta. Negociar. Firmar contrato.
Eso no es un proceso comercial. Es un checklist de actividades. Y el pipeline no es el lugar para ponerlo.
Si prefieres verlo en video, aquí lo explico:
El proceso comercial es mucho más grande que el pipeline. Incluye cómo generas demanda, cómo capturas leads, cómo los calificas, cómo los nutres si no están listos, cómo los vendes si sí lo están, y cómo los entregas después de la venta. El pipeline es solo un tramo de ese recorrido.
Cuando hablamos de diseñar el proceso comercial, mucha gente cree que eso significa crear un pipeline en el CRM con sus etapas y listo. Pero el pipeline es el tramo donde un prospecto que ya fue calificado avanza hacia la compra. Nada más.
Si metes en el pipeline a todo el que completó un formulario, a todo el que descargó un ebook, a todo el que pidió información, estás llenando tu pipeline de gente que no está lista para comprar. Y eso contamina todo: tu forecast, tus métricas, la carga de trabajo de tu equipo.
Pero eso es tema para otro capítulo de esta serie, porque meter leads no calificados al pipeline es un error tan común y tan dañino que merece su propio espacio. Hoy quiero enfocarme en algo más sutil y más profundo: cómo están diseñadas las etapas dentro de tu pipeline.
El error más común es que las etapas sean tareas del vendedor. Abre tu CRM ahora mismo y mira los nombres de las etapas de tu pipeline. Si se parecen a esto, tenemos un problema: Contactar prospecto → Agendar reunión → Realizar presentación → Enviar propuesta → Negociar términos → Cerrar contrato.
¿Qué tienen en común todas estas etapas? Son cosas que el vendedor tiene que hacer. Son actividades internas. Son un to-do list.
El problema con esto es que el pipeline se convierte en un espejo de las tareas del equipo comercial, no del avance real del prospecto hacia la compra. Y eso genera una desconexión brutal: el vendedor puede haber "enviado la propuesta" pero el prospecto ni siquiera la abrió. La etapa dice una cosa, la realidad dice otra.
¿Te suena familiar? Es exactamente el mismo problema que vimos en el post anterior sobre criterios de entrada y salida. Pero esta vez la raíz es más profunda: no es solo que faltan criterios, es que las etapas mismas están mal concebidas desde el inicio.
Acá está el cambio de mentalidad que lo transforma todo: las etapas de tu pipeline no deberían describir lo que el vendedor hace. Deberían describir lo que el comprador ya hizo. Lo que el prospecto ya experimentó, ya decidió, ya completó en su propio proceso de evaluación. Por eso las etapas deben estar en pasado.
No "Enviar propuesta". Sí "Propuesta revisada". No "Agendar reunión". Sí "Reunión completada". No "Negociar términos". Sí "Términos acordados". No "Cerrar contrato". Sí "Contrato firmado".
Parece un cambio cosmético. Pero no lo es.
Cuando la etapa dice "Enviar propuesta", el vendedor la lee como una instrucción. Es algo que él tiene que hacer. Entonces mueve el deal a esa etapa cuando manda el PDF, sin importar si el prospecto lo leyó, lo entendió, o lo tiró a la basura.
Cuando la etapa dice "Propuesta revisada", el vendedor entiende algo completamente diferente. No puede mover el deal ahí hasta que el prospecto haya revisado la propuesta. El nombre mismo de la etapa le está diciendo qué tiene que haber pasado del lado del comprador.
Es decir, el nombre de la etapa se convierte en un criterio de avance.
No necesitas un manual de 20 páginas explicándole al equipo cuándo mover un deal. Si la etapa dice "Reunión completada", todos entienden que el deal no llega ahí hasta que la reunión se haya hecho. Si dice "Necesidades documentadas", todos entienden que tiene que haber un registro concreto de lo que el prospecto necesita.
El pasado no es una preferencia gramatical. Es una decisión de diseño que protege la integridad de tu pipeline.
Si te detienes a pensarlo, un buen pipeline cuenta una historia. Pero no la historia de lo que hizo tu equipo de ventas, sino la historia de lo que vivió el comprador desde que fue calificado hasta que firmó. Algo así:
Cada etapa es un hito verificable en el recorrido del comprador. No una tarea del vendedor.
Lee cada etapa de tu pipeline en voz alta. Si suena como algo que el vendedor tiene que hacer, está mal. Si suena como algo que el prospecto ya experimentó, va por buen camino. Después pregúntate: ¿puedo verificar esto? ¿Hay algo en el CRM que me diga si esto realmente pasó?
Si la etapa dice "Reunión completada" pero no hay forma de comprobar que la reunión ocurrió, tienes un nombre bonito sin sustancia.
Las etapas deben ser verificables. Cada una debería tener un elemento en el CRM que confirme que ese hito efectivamente se cumplió. Si no está agendada la reunión en el sistema, el deal no se mueve. Si no está adjunta la propuesta revisada, el deal no avanza. Así de simple.
Piénsalo como alertas de "no pasas de aquí si no hiciste esto". El CRM se convierte en el guardián del proceso, no en un registro pasivo donde cada vendedor anota lo que quiere.
Pero cómo configurar eso de forma práctica, con campos obligatorios, automatizaciones y validaciones, es un tema que merece su propio espacio. Es lo que viene en el siguiente capítulo de esta serie.
En el artículo anterior hablamos de los criterios de entrada y salida de cada etapa. Hoy vimos que las etapas mismas tienen que estar bien diseñadas para que esos criterios funcionen. Son capas que se construyen una sobre otra.
Lo que viene: cómo hacer que cada etapa sea inspeccionable en el CRM. Campos obligatorios, evidencia trazable, y cómo cerrarle la puerta a los deals que quieren avanzar sin cumplir los criterios. También quiero abordar qué hacer con los leads que aún no califican para el pipeline, porque meterlos ahí solo porque llenaron un formulario es otro error que veo constantemente.
Proceso primero. Herramienta después.
Nos vemos en el próximo artículo de esta serie.