En los dos artículos anteriores de esta serie vimos dos cosas fundamentales. Primero, que cada etapa de tu pipeline necesita criterios de entrada y salida. Segundo, que esas etapas deben reflejar el viaje del comprador, no las tareas de tu vendedor, y por eso van en pasado.
Pero hay un tercer problema que aparece incluso cuando ya hiciste todo eso bien.
Puedes tener las etapas perfectamente nombradas. Puedes tener los criterios documentados en un manual que todo el mundo leyó. Y aun así, un vendedor puede mover un deal de etapa sin que nada de eso se haya cumplido.
¿Por qué? Porque el CRM se lo permite.
Si no hay nada en la herramienta que obligue a demostrar que el criterio se cumplió, el criterio es una sugerencia. Y las sugerencias en ventas tienen una tasa de cumplimiento cercana a cero cuando hay presión por cerrar el mes.
Si prefieres verlo en video, aquí lo explico:
Porque el sistema no le exige al vendedor demostrar que el hito se cumplió antes de mover el deal. Imagina que tu pipeline tiene una etapa que dice "Reunión completada". Es un buen nombre. Está en pasado. Refleja un hito del comprador. Tiene criterio de entrada claro.
Pero cuando abres el CRM y miras los deals en esa etapa, te encuentras con esto:
Tres deals en la misma etapa. Ninguno cumple realmente el criterio. Pero el CRM no dijo nada. Los dejó pasar. El problema no es el vendedor. El problema es el sistema.
Significa algo muy concreto: que puedas abrir cualquier deal en cualquier etapa y verificar, sin preguntarle al vendedor, si el hito realmente se cumplió. No es "confío en que lo hizo". Es "puedo comprobarlo yo mismo en el CRM". La inspeccionabilidad elimina la ambigüedad.
Si la etapa dice "Reunión completada", debería haber una reunión registrada con fecha, asistentes y notas. Si no la hay, el deal no debería poder estar en esa etapa.
Si la etapa dice "Propuesta revisada", debería haber un registro de que la propuesta fue enviada al decisor y que hubo una respuesta. No basta con que el vendedor diga "sí, la vio".
Si la etapa dice "Contrato firmado", debería haber un documento adjunto. No una nota que dice "me confirmó por WhatsApp que va".
La inspeccionabilidad convierte cada etapa en algo que puedes auditar, no en algo que tienes que creer.
Si seguiste el primer artículo de esta serie, probablemente te estés preguntando: ¿esto no es lo mismo que ya vimos? La respuesta corta es no. Se complementan, pero resuelven problemas distintos. Los criterios de entrada y salida responden a la pregunta "qué tiene que pasar".
Son la regla. "Para entrar a Propuesta, el decisor debe haber sido identificado y el alcance debe estar definido."
La inspeccionabilidad responde a otra pregunta: "cómo sé que realmente pasó". Es la evidencia y el mecanismo que obliga a cumplir la regla. "El campo 'Nombre del decisor' es obligatorio para mover a Propuesta. Si está vacío, el deal no se mueve."
Puedes tener un criterio perfecto que diga "el decisor debe haber revisado la propuesta". Eso es claro. Pero si no hay nada en el CRM que lo demuestre, dependes de que el vendedor te diga la verdad. Y bajo presión de cierre, la verdad es lo primero que se flexibiliza.
Piénsalo así:
Sin la cámara, la ley es una sugerencia. Sin inspeccionabilidad, el criterio es un buen deseo. Lo que hicimos en el primer artículo fue escribir las reglas. Lo que estamos haciendo ahora es instalar las cámaras.
Acá es donde todo lo que hemos visto en la serie se conecta. En el primer artículo definimos las reglas. En el segundo rediseñamos las etapas. Ahora el tercer paso es convertir el CRM en el guardián que hace cumplir esas reglas con evidencia obligatoria.
Con campos obligatorios por etapa. La idea es simple: antes de que un deal pueda moverse a la siguiente etapa, el CRM le exige al vendedor completar cierta información. Si no la completa, el deal no se mueve. No hay excusa, no hay excepción, no hay "después lo lleno".
Es el equivalente digital de una puerta con llave. La llave es la evidencia.
Si falta cualquiera de estos elementos, el CRM bloquea el movimiento. Le dice al vendedor: "no pasas de aquí si no hiciste esto"
Esta es la objeción que siempre aparece. Y la respuesta es: sí, va a hacer más lento mover deals en el CRM. Pero no va a hacer más lento vender. Un pipeline más lento pero real es infinitamente más valioso que un pipeline rápido pero ficticio.
Lo que va a hacer es eliminar los deals que se movían sin sustancia. Los que avanzaban en el sistema pero no en la realidad. Los que inflaban el pipeline y después desaparecían al final del trimestre.
Piénsalo así: si tienes 40 deals en "Propuesta" pero solo 8 realmente tienen una propuesta revisada por el decisor, tu pipeline no tiene 40 oportunidades. Tiene 8. Los otros 32 son ruido que distorsiona todo lo que construyes encima.
Cuando implementas campos obligatorios, tu pipeline se "achica". Pero lo que queda es real. Y con datos reales puedes tomar decisiones reales: dónde enfocar al equipo, qué deals priorizar, cuánto vas a cerrar este mes.
Sin inspeccionabilidad, la reunión de forecast es un acto de fe. Le preguntas al vendedor "cómo va este deal" y dependes 100% de su interpretación. No tienes forma de validar lo que te dice sin entrar deal por deal y hacer preguntas incómodas.
Con inspeccionabilidad, abres el CRM y la historia se cuenta sola. Cada deal tiene la evidencia de por qué está donde está. Si dice "Propuesta revisada", puedes ver la propuesta, puedes ver quién la recibió, puedes ver el feedback. No hay nada que interpretar.
La reunión de forecast pasa de "cuéntame cómo va" a "veamos qué dicen los datos". Y eso cambia todo: la conversación, la cultura, y los resultados.
Se hace en cinco pasos: tomar las etapas, definir la evidencia de cada una, configurar campos obligatorios por etapa, comunicar el cambio al equipo y revisar el cumplimiento las primeras semanas. Si llegaste hasta acá y quieres empezar a hacer tu pipeline inspeccionable, acá van los pasos concretos.
Paso 1: Toma las etapas de tu pipeline (que ya deberían estar en pasado y con criterios definidos si seguiste los artículos anteriores).
Paso 2: Para cada etapa, define qué elemento en el CRM sirve como evidencia. Puede ser una actividad registrada, un campo completado, un documento adjunto, una propiedad marcada. Algo que exista en el sistema y que cualquiera pueda verificar.
Paso 3: Configura campos obligatorios por etapa. La mayoría de los CRMs modernos permiten esto. En HubSpot, el CRM con el que trabajamos en Revops LATAM, son las propiedades condicionales por etapa del pipeline. En Salesforce son los validation rules. En Pipedrive son los campos requeridos por fase. La herramienta cambia, el principio es el mismo.
Paso 4: Comunica el cambio al equipo. No como un castigo ni como burocracia nueva. Como una mejora que protege a todos: al vendedor de que le cuestionen sus deals, al gerente de que tome decisiones con datos falsos, y a la empresa de que el forecast sea ficción.
Paso 5: Revisa el cumplimiento las primeras semanas. Vas a encontrar resistencia. Vas a escuchar "esto me hace perder tiempo". Mantente firme. Cuando el equipo vea que el forecast empieza a cumplirse y que las reuniones de pipeline se vuelven productivas en vez de interrogatorios, la resistencia desaparece sola.
Un pipeline que dice la verdad se construye en tres capas: criterios de entrada y salida, etapas diseñadas como hitos del comprador, e inspeccionabilidad. La regla sin evidencia es una sugerencia. La evidencia sin mecanismo es opcional. Las tres capas juntas son un pipeline que dice la verdad.
Si has seguido la serie completa, ya tienes una imagen clara de cómo se construye:
Capa 1 (primer artículo): Los criterios de entrada y salida. La regla que define qué tiene que pasar para que un deal entre y salga de cada etapa.
Capa 2 (segundo artículo): Las etapas diseñadas como hitos del comprador. Nombradas en pasado para reflejar lo que el prospecto ya experimentó, no lo que el vendedor tiene que hacer.
Capa 3 (este artículo): La inspeccionabilidad. La evidencia obligatoria en el CRM que convierte las reglas en algo verificable y los hitos en algo que no se puede falsificar.
Todavía hay errores que quiero abordar en esta serie. El próximo: qué hacer con los leads que no califican para el pipeline. Porque meterlos ahí solo porque llenaron un formulario o pidieron información es otro error que veo constantemente, y contamina todo lo que acabamos de construir: el forecast, las métricas y la carga de trabajo del equipo.
Si te llega un lead que todavía no tiene dolor identificado, que no sabe si tiene presupuesto, que no tiene claro qué quiere, ese lead no va al pipeline. Va a otro lugar. Pero eso lo desarrollamos en el próximo artículo de esta serie.
Proceso primero. Herramienta después.