Si no es inspeccionable, no existe. (Cómo blindar tu pipeline con evidencia)

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:

¿Por qué mi CRM deja pasar deals sin evidencia?

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:

• Deal de Empresa A: no hay ninguna reunión registrada en el CRM.
• Deal de Empresa B: hay una reunión agendada para la semana que viene, pero el deal ya está en esa etapa.
• Deal de Empresa C: hay una nota que dice "hablé con el contacto por teléfono 5 minutos".

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.

¿Qué significa que una etapa sea inspeccionable?

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.

¿Es lo mismo que los criterios de entrada y salida?

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."

¿Por qué no basta con definir criterios?

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í:

• El criterio es la ley de tránsito: "no pases en rojo".
• La inspeccionabilidad es la cámara de fiscalización: registra si lo cumpliste y tiene consecuencias si no.

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.

¿Cómo hago que mi CRM bloquee los deals sin evidencia?

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.

• Para mover a "Reunión completada": debe existir una actividad de tipo reunión asociada al deal con fecha pasada.
• Para mover a "Propuesta revisada": debe existir un documento de propuesta adjunto y el campo "feedback del decisor" debe estar completo.
• Para mover a "Términos acordados": el campo "presupuesto confirmado" debe estar marcado como sí y el campo "próximo paso" debe tener una fecha futura.
• Para mover a "Contrato firmado": debe existir un documento de contrato adjunto.

Si falta cualquiera de estos elementos, el CRM bloquea el movimiento. Le dice al vendedor: "no pasas de aquí si no hiciste esto"

¿Los campos obligatorios hacen más lenta la venta?

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.

¿Cómo cambia la reunión de forecast con evidencia?

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.

¿Cómo hago inspeccionable mi pipeline paso a paso?

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.

¿Cómo configuro los campos obligatorios en mi CRM?

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.

¿Cómo se construye un pipeline que dice la verdad?

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.

¿Qué hago con los leads que todavía no califican?

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.