Por qué la etapa del pipeline no coincide con el avance real de la venta
La etapa del pipeline es una etiqueta de gestión propia. El avance de compra es el grado en que se han cumplido las condiciones dentro de la organización del cliente.
Son dos cosas distintas:
- la etapa se actualiza con las acciones propias (se envió la propuesta, se entregó la oferta);
- el avance de compra solo se mueve con las decisiones del cliente (la validación técnica terminó, el importe quedó presupuestado).
«En propuesta» significa que se entregó una propuesta. No significa que el cliente la haya evaluado, ni que el circuito de aprobación se haya puesto en marcha. Lo mismo ocurre con la probabilidad de cierre: refleja la sensación de quien lleva la operación, no lo que ha quedado resuelto del otro lado.
La etapa es una etiqueta. El avance necesita evidencia.
A continuación, por qué se separan las dos cosas y cómo asociar evidencia a cada etapa.
Qué indica una etapa y qué no indica
| Lo que indica la etapa | Lo que no indica |
|---|---|
| Qué ha hecho el equipo comercial | Qué ha quedado cerrado en la organización del cliente |
| La clasificación interna de la operación | Qué áreas han emitido una decisión |
| Una referencia de fecha prevista de cierre | Cuántas condiciones siguen abiertas |
| La unidad de reporte interno | Si está identificado quien tiene que aprobar |
El problema no está en la etapa. Como instrumento para gestionar la actividad propia, funciona. Aparece cuando se lee como sustituto del avance del cliente.
Por qué divergen
1. La actualización depende del lado propio
Una etapa avanza normalmente cuando se entrega algo. Se envía la propuesta y pasa a «en propuesta»; se entrega la oferta y pasa a «negociación». Con ese diseño, la etapa puede avanzar sin que el cliente haya hecho absolutamente nada.
2. La probabilidad se apoya en una impresión
El porcentaje de cierre suele asignarse a partir de la percepción de quien lleva la operación: hay buena reacción, hubo comentarios favorables.
La impresión no carece de valor: la observación de quien estuvo en la reunión contiene información. Pero la impresión y el cumplimiento de condiciones son dos informaciones distintas. Al comprimirlas en un único porcentaje, se pierden las dos.
3. La etapa es una sola línea
El avance del cliente ocurre en paralelo. El área usuaria terminó, sistemas está revisando, con compras no hay contacto y la inversión no se ha presentado. Cuatro estados simultáneos que no caben en un único valor de etapa. Al intentarlo, el valor acaba representando al área más avanzada o a la última con la que se habló.
Gestión por pipeline frente a gestión por avance de compra
| Gestión por pipeline | Gestión por avance de compra (Sales Opportunity Intelligence) | |
|---|---|---|
| Unidad de gestión | Un valor de etapa por oportunidad | Estado de cumplimiento por condición |
| Se actualiza cuando | Actúa el equipo comercial | El cliente cierra una decisión |
| Base del avance | Lo que introduce el vendedor | Hechos registrados en las interacciones |
| Estados representables | Una posición en una línea | Estados distintos por área |
| Detección del estancamiento | Tiempo desde la última actualización | Condiciones que siguen abiertas |
| Base de la probabilidad | Experiencia e intuición | Número y tipo de condiciones cumplidas |
| Explicación al responsable | Etapa y fecha prevista | Qué condiciones faltan |
| Cuando no avanza, se sabe | Que no avanza | Por qué no avanza |
La columna derecha no sustituye a la izquierda. Es una capa de evidencia debajo de ella. La etapa se mantiene como lenguaje común del equipo; lo que se añade es la base que la justifica.
Por qué la probabilidad de cierre no mejora
Cuando la previsión falla, el intento habitual es endurecer los criterios: el 80 % exige tal cosa, el 50 % tal otra.
Pero afinar los porcentajes no cambia nada mientras quien los determina sea la impresión. En muchas configuraciones de CRM el porcentaje se asigna además de forma automática según la etapa, de modo que no añade información alguna: es la misma etiqueta expresada en otra escala.
Lo que hay que cambiar no es la definición del porcentaje, sino poder escribir con condiciones qué justifica ese nivel.
| Definición habitual | Definición basada en condiciones |
|---|---|
| Alta probabilidad de cierre | Evaluación del área usuaria cerrada, validación técnica completada, importe presupuestado, aprobador identificado |
| En evaluación, buena perspectiva | Evaluación del área usuaria cerrada, validación técnica en curso, respaldo presupuestario sin confirmar |
| Fase informativa | Contacto con una sola área, ninguna condición cerrada |
La columna derecha se puede verificar por cuenta propia. Si después se le pone una etiqueta de probabilidad, esa etiqueta tiene una base detrás.
Hay un efecto secundario útil: permite comparar operaciones entre sí. Ante dos oportunidades con la misma probabilidad, la impresión no dice cuál es más sólida. El recuento de condiciones cumplidas, sí.
Ejemplo: una operación detenida en «en propuesta»
Nota: escenario hipotético creado para ilustrar el método. No corresponde a ninguna institución real.
Operación: implantación de un sistema de gestión en una institución universitaria. Etapa en el CRM: «en propuesta». Probabilidad asignada: 50 %. Cinco semanas desde la última actualización.
Lo que indica la etapa Propuesta entregada. Contacto periódico con el interlocutor.
El avance de compra real
| Condición | Estado |
|---|---|
| Evaluación funcional del área administrativa | Completada |
| Validación técnica del área de sistemas | Sin completar (método de integración con el sistema existente sin definir) |
| Adecuación a las normas internas de seguridad de la información | Sin iniciar (responsable sin identificar) |
| Dotación presupuestaria | Tratamiento en el ejercicio siguiente sin confirmar |
| Aprobación | Aprobador sin identificar |
De cinco condiciones, hay una cumplida. Ni la etapa ni el 50 % reflejan ese desglose.
Lo que está ocurriendo Sin la validación técnica, las condiciones posteriores no se mueven. Como el contacto con el interlocutor continúa, el CRM sigue registrando actividad. La actividad parece suficiente, la etapa y la probabilidad no cambian, y el tiempo pasa.
Decisión vista solo desde el pipeline «Cinco semanas sin movimiento. ¿Bajamos la probabilidad o planteamos un descuento?»
Decisión vista desde las condiciones «Una de cinco condiciones cumplida. El cuello de botella es la validación técnica. No hay acuerdo sobre los puntos a revisar ni sobre el plazo: eso es lo primero que hay que fijar.»
La misma operación, dos unidades de lectura, dos acciones distintas. Cómo distinguir qué frena una operación se desarrolla en por qué se estancan las oportunidades B2B.
No eliminar las etapas: darles base
En la práctica, un vendedor no puede cambiar por su cuenta la configuración del pipeline de su empresa: es la unidad de gestión del equipo.
La salida realista es mantener la etapa y sostener debajo una capa de condiciones.
Cómo hacerlo
1. Definir qué evidencia justifica cada etapa
| Etapa | Evidencia que la justifica |
|---|---|
| En propuesta | Propuesta entregada y reacción del área usuaria recogida |
| Validación técnica | Responsable técnico identificado y puntos a revisar compartidos |
| Ajuste final | Condiciones técnicas y presupuestarias cumplidas, aprobador identificado |
| Cierre previsto | Solicitud interna presentada y condiciones acordadas |
2. No avanzar de etapa sin esa evidencia
Haber entregado la propuesta mantiene la operación en «en propuesta» hasta que se recoja una reacción. Las etapas avanzan más despacio, pero el significado de haber avanzado se vuelve exacto.
3. Llevar aparte las condiciones abiertas de cada operación
La etapa es un valor único; las condiciones son varias. Cómo redactarlas se trata en cómo entender las unidades de decisión.
Cómo cambia el reporte al responsable
El efecto práctico de gestionar por condiciones se nota en la calidad del reporte.
Reportando por etapa
«La operación está en propuesta. La sensación es buena. Creo que el mes que viene se mueve.»
Ante eso, el responsable solo puede preguntar si es seguro y cuándo cierra. Ambas respuestas serán conjeturas.
Reportando por condiciones
«Una de cinco condiciones cumplida. El cuello de botella es la validación técnica: los puntos a revisar ya están compartidos, falta acordar el plazo de respuesta. Esta semana lo fijo.»
Este segundo reporte contiene hechos verificables, una acción siguiente y un plazo. El responsable puede además saber dónde puede ayudar.
No se gestiona para reportar. Poder explicar la situación y tenerla bajo control son la misma cosa.
Lo que hay detrás de la etiqueta — el enfoque de VINEQRA
VINEQRA es un CRM con IA para iOS diseñado para el vendedor individual que lleva operaciones largas con varios interlocutores.
Un CRM funciona, en gran medida, como sistema de registro: qué ocurrió, qué actividad se anotó, en qué etapa está la oportunidad. Son funciones necesarias para la gestión de una organización.
Lo que VINEQRA intenta añadir es la capa que va encima: el razonamiento sobre lo registrado.
| Lo que responde un sistema de registro | Lo que VINEQRA intenta responder |
|---|---|
| Qué ocurrió | Qué indica el contexto acumulado |
| En qué etapa está | Qué condiciones siguen abiertas |
| Con quién se ha hablado | Qué interlocutor o decisión hace falta a continuación |
| Cuándo fue la última actividad | Qué conviene considerar como siguiente paso |
El contexto se organiza así:
Interacciones + interlocutores + puntos de decisión + bloqueadores → siguiente mejor acción (Next Best Action)
(VINEQRA Opportunity Context Model)
El análisis por IA correspondiente puede ejecutarse en el propio dispositivo mediante el modelo de lenguaje del sistema, a través de Apple Foundation Models.
Y un principio de partida:
VINEQRA propone. Quien decide es el vendedor.
Conviene precisar algo: esto no significa que los CRM existentes carezcan de gestión de etapas o de interlocutores. Muchos la incorporan. La diferencia está en si un vendedor individual puede tener el contexto de sus operaciones en una forma utilizable para razonar sobre ellas.
Preguntas frecuentes
¿Hay que dejar de usar las etapas? No. Funcionan como unidad de gestión del equipo. Lo necesario es no leerlas como sustituto del avance del cliente y definir qué evidencia justifica cada una.
¿Qué porcentaje de probabilidad conviene dar? Más que afinar el número, ayuda poder expresar con condiciones qué lo sostiene. «Tres de cinco condiciones cumplidas; faltan presupuesto y aprobación» es más útil, para uno mismo y para el responsable, que «70 %».
¿Hasta dónde se puede conocer el estado de las condiciones del cliente? Nunca del todo. Tiene valor mantener explícitamente lo que no se conoce. Una operación con muchos desconocidos no está necesariamente parada: está sin visibilidad, y lo que necesita no es más propuesta, sino confirmación.
Si la etapa no avanza, internamente se valora peor. A corto plazo, sí. A cambio, mover etapas sin base produce operaciones que no se pueden explicar cuando se pierden. Gestionando por condiciones, el motivo de la pérdida se puede exponer como hecho.
¿Mejora la fiabilidad de la previsión? La gestión por condiciones no garantiza la previsión: las circunstancias del cliente cambian por factores externos. Lo que sí mejora es poder identificar el motivo cuando la previsión falla.
Leer la operación por evidencia, no por etiqueta
La etapa y la probabilidad existen para la gestión interna y cumplen su función. El problema aparece al usarlas sin advertir que no describen lo que ocurre del lado del cliente.
La etapa es una etiqueta. El avance necesita evidencia.
VINEQRA vincula las interacciones registradas con los interlocutores y los puntos de decisión, y señala las condiciones que permanecen abiertas.
Ver lo que hay detrás de la etapa. → Descargar VINEQRA en App Store