En cinco semanas los convertí en un sistema que toma decisiones con mi criterio en 8 de cada 10 casos al primer intento.
Una nota: en este caso soy el experto y el arquitecto a la vez. Lo publico porque demuestra el proceso completo, incluido lo que falló por el camino. No porque sea la mejor prueba de Encode. La mejor prueba será tu caso, donde yo soy solo el arquitecto.
Y una indicación de lectura: yo era eso que en tu empresa llamas el top performer. El que resuelve lo que nadie más resuelve y no sabe explicarte cómo. Lee este caso poniéndole la cara de tu mejor vendedor, de tu jefe de operaciones o del técnico que lleva quince años. La historia es la misma. Solo cambia el nombre.
Vendí tecnología empresarial durante 20 años. Vodafone, Factorial, Personio, Typeform. Operaciones de cinco y seis cifras donde cada decisión de criterio movía el resultado.
Durante esos años construí tres métodos propios:
Para descifrar qué piensa un cliente cuando dice «déjame pensarlo». Cuatro dimensiones: lo que dice, lo que quiere, lo que teme, lo que cree.
Para evaluar si una operación es real o estoy perdiendo el tiempo. Sin esperanza, solo evidencia.
Para obtener información sensible sin hacer preguntas directas que levanten defensas en el cliente.
Cada método funcionaba por separado. El valor real estaba en combinarlos. La decisión de «ahora cambio de cualificación a análisis mental porque el cliente acaba de decir algo que revela un miedo» no estaba escrita en ninguna parte. Vivía en mi cabeza.
Podía explicar cada método. Lo que no podía explicar era cuándo usar cuál, ni cómo combinarlos.
Lo intenté durante años. Manuales que quedaban incompletos. Formaciones donde la gente entendía la teoría pero no la aplicaba como yo. Un ChatGPT entrenado con mis materiales que sonaba bien pero no pensaba como yo.
En mis propias notas durante el proceso:
«Mi mayor frustración era que no podía codificarlo. Cuando lo ponía en papel siempre salía incompleto. Unas partes quedaban sin terminar. Otras que sí comunicaba no se entendían correctamente.» Eso es la Regla del 70%, en mi propio caso.
Si esto le pasaba al experto intentando transmitirse a sí mismo, con todo el interés del mundo en conseguirlo, calcula lo que captura el manual de onboarding que tu empresa escribió sobre alguien que además tiene cosas mejores que hacer.
Después de años de manuales fallidos, entendí dos cosas:
Primera: documentar y codificar no son lo mismo. Documentar es escribir lo que sabes. Codificar es escribir lo que decides cuando pasa algo. «Si el cliente dice X, hago Y. Si pasa Z, hago lo contrario. Si aparece algo que no encaja en ninguna regla, paro y pregunto.»
Segunda: mis tres métodos no eran tres archivos. Eran un solo sistema con piezas que se activaban en secuencia según lo que pasaba en la conversación.
Esa segunda cosa es la que nunca había podido escribir. Porque no la sabía conscientemente. La ejecutaba.
El proyecto que sigue es lo que pasó cuando intenté extraerla.
Lo que sigue es lo que pasó en mi propio caso. No es el manual de cómo se hace un Diagnosis, un Build o un Expertise OS. Eso vive en otra página. Aquí cuento lo que aprendí cuando el método se aplicó a sí mismo.
Empecé por la pregunta más incómoda: ¿cuándo uso cada método y por qué?
La dificultad específica de este caso: cuando eres el experto y el arquitecto a la vez, tu sesgo de confirmación es el mayor riesgo. Tiendes a documentar lo que crees que haces, no lo que haces. Esa fue la primera evidencia que tuve de por qué los manuales que había escrito antes salían incompletos.
El resultado de la semana 1 fue un mapa. No tres archivos separados, sino una arquitectura con siete puntos de conexión entre métodos y nueve situaciones distintas donde activaba uno u otro. Esos números nunca habían sido escritos. Eran intuición.
Eso es lo que Diagnosis entrega hoy: el Mapa de Criterio Crítico. La parte de tu experto que nadie ha visto nunca escrita, empezando por él.
Para forzar las decisiones que tomaba automáticamente, necesitaba escenarios que no me dieran tiempo a racionalizar. La diferencia entre preguntar:
«¿Qué haces cuando una operación se estanca?»
Y poner sobre la mesa:
«Tu operación lleva 3 semanas parada. Tu contacto interno no responde. La revisión de forecast es el viernes y tu jefe pregunta si la incluye como comprometida.»
La primera produce respuesta de manual. La segunda produce el protocolo real.
En este caso lo hizo un colaborador externo, no yo. Era la única forma de neutralizar el sesgo. Si me preguntaba a mí mismo, sabía las respuestas. Si me ponía a otro a presionarme, salían las decisiones que de verdad tomo.
En tu empresa, ese testigo externo soy yo. Tu experto no puede autoextraerse, y quien trabaja con él a diario tampoco puede: conoce demasiado bien las respuestas de manual.
De ahí salieron nueve protocolos completos y las siete conexiones entre métodos quedaron documentadas por primera vez.
Tres capas:
El Motor de Decisión lee la situación y decide qué protocolo activar. El usuario describe el caso en lenguaje normal. El sistema elige.
Las Reglas y la Matriz de Excepciones contienen la lógica detallada de cada método y los casos donde las reglas normales no aplican. Esto es lo que separa la forma de trabajar de tu experto de cualquier plantilla genérica de su sector.
Las Instrucciones de Operación explican cómo usarlo. Una página. Tres pasos. Escritas para el equipo, no para el experto.
Pasé el sistema por diez situaciones reales. La pregunta no era «¿es razonable?». Era: ¿es lo que yo habría hecho? No parecido. Idéntico.
Ocho de diez pasaron al primer intento.
Los dos que fallaron son los que cuento en el siguiente bloque.
Esperaba que fallaran más. Que solo dos de diez necesitaran corrección me sorprendió. Y confirmó algo que no había escrito antes: el proceso de extracción había capturado más de lo que yo creía tener documentado.
Pero esos dos importan más que los ocho que pasaron.
Una operación donde dos de mis principios entraban en conflicto: cualificar agresivamente para no perder tiempo, y mantener la conversación abierta para no cerrar prematuramente. El sistema no sabía cuál priorizar. Yo, en vivo, lo decido sin pensar. Pero la regla que lo gobierna no estaba escrita.
Una situación donde el cliente decía algo que activaba un protocolo de extracción de información, pero el contexto pedía pausar ese protocolo y pasar a análisis mental. La transición no estaba codificada porque, hasta entonces, ni yo sabía que la hacía.
Los corregí. Los retesté. Pasaron.
Ese es el tipo de criterio que solo sale bajo presión. No lo descubres escribiendo documentación. Lo descubres cuando algo rompe las reglas.
Para que el caso no termine siendo solo afirmaciones sobre lo que el sistema hace, lo que sigue es una de las once reglas auditables del Motor de Decisión, citada tal cual está escrita en el archivo.
MEDDICC indica qué información falta para cualificar un deal. Pero preguntar directamente «¿quién decide?» o «¿cuál es el presupuesto?» pone al contacto en modo interrogatorio y reduce el acceso futuro.
Para cada elemento MEDDICC pendiente de validar, el sistema selecciona la técnica de elicitation correspondiente:
Excepción: cuando hay rapport establecido y el tema no es sensible (más de tres interacciones, conversación informal en curso, o el contacto ya ha compartido información delicada), las preguntas directas son aceptables. La elicitation es el método primario en las primeras interacciones, no una prohibición universal.
Esa regla concreta, en mi cabeza, era una decisión instantánea sin formular. En el archivo son catorce líneas auditables que cualquier modelo puede ejecutar.
La diferencia entre lo que pensaba que hacía y lo que hago es exactamente eso. Y eso es lo que se codifica.
Ahora piensa en la Regla 7 de tu director comercial. Existe. La aplica todas las semanas. No está escrita en ninguna parte. Cada experto tiene entre 8 y 30 reglas como esta. Ninguna está escrita.
| Antes | Después |
|---|---|
| 45-60 minutos para diagnosticar una operación | Menos de 2 minutos |
| 3 métodos aislados, cada uno por su cuenta | 1 sistema integrado |
| 0 protocolos documentados | 9 protocolos completos |
| Conexiones entre métodos solo en mi cabeza | 7 conexiones documentadas |
| Reglas tácitas, invisibles | 11 principios auditables |
En tres meses de uso diario: revisiones de operación en dos minutos donde antes necesitaba cuarenta y cinco. Preparación de reuniones documentada y reproducible. Diagnosis de operaciones paradas que propone una acción concreta basada en el bloqueo real, no «hacer seguimiento».
¿Es perfecto? No. Hay situaciones donde mi intuición humana añade algo que el sistema no captura. Pero en ocho de cada diez casos, el resultado es el que yo habría dado. Esos ocho liberan mi tiempo para enfocarme en los dos que requieren criterio en vivo.
Y esa es la aritmética que importa en una empresa: el motor no sustituye al experto. Le quita de encima los ocho casos de cada diez que no le necesitan, y deja su criterio disponible para quien todavía no lo tiene. El vendedor que entra nuevo no espera 18 meses para pensar como el veterano: consulta cómo decide el veterano desde el primer día.
La primera arquitectura eran tres métodos, nueve protocolos y siete conexiones. Hoy el motor va por su versión 4.1: cinco métodos, once protocolos y nueve conexiones.
Después de aquellas cinco semanas incorporé dos métodos más. Y esta vez no eran míos: un sistema de venta por enseñanza y un sistema completo de gestión de objeciones, con su propia secuencia (prevenir, cualificar, triar, responder). Metodología de otros autores, conectada con la mía.
Ninguna de las dos ampliaciones exigió reconstruir nada. Las reglas nuevas se conectaron a las existentes, las siete conexiones originales siguen intactas, y el sistema entero se recalibró contra la batería completa de casos de test: 53 de 53. Prueba en vivo de la tercera garantía: el sistema se recalibra cuando algo cambia. Aquí cambió el propio criterio.
Esa es la diferencia entre documentar y codificar, medida en el tiempo. Un manual se reescribe cada vez que el criterio cambia. Un sistema codificado se amplía. Y un motor que absorbe métodos ajenos sin romperse puede absorber el de tu segunda persona clave, y el de la tercera.
En las empresas, esa mecánica tiene nombre: Expertise OS.
Después de esta primera arquitectura apliqué el mismo proceso a cuatro cuerpos de obra publicados en el mundo hispano: lujo, copywriting, ventas B2B y comunicación de alto impacto. Trabajé sobre material publicado de los autores, sin contacto comercial con ellos. El objetivo era auditar si la arquitectura sostenía criterio ajeno con la misma limpieza con la que sostenía el mío.
Cada una pasó el mismo umbral: ocho de cada diez decisiones replicadas correctamente.
El criterio de un vendedor enterprise no tiene nada de especial. Es criterio: decisiones condicionadas que se toman bajo presión. El de tu jefe de operaciones, tu responsable técnico o tu mejor vendedor se extrae con la misma mecánica.
Por eso hoy Encode se aplica a empresas.