El SOP existe, esta documentado, y no ejecuta nada#
El Codigo Reforma tenia 47 pasos escritos en Notion. Pago del cliente, research del sector, buyer persona, creatividades iniciales, configuración de cuentas publicitarias, welcome email, kickoff. Todo documentado con detalle.
Y sin embargo, cada alta nueva requeria a tres personas con el Notion abierto, tomando decisiones que ya estaban implicitamente en el propio SOP pero que nadie había codificado como reglas ejecutables.
El problema no era "el onboarding es lento". Era más específico: el SOP existe, esta documentado, y no hace nada. Y las consecuencias van más alla de la operativa interna. Según el [Gainsight 2024 Customer Success Index](�PH0� el 73% de los equipos de Customer Success identifican la prevención de churn en las primeras semanas como la principal oportunidad de automatización, precisamente porque el periodo de onboarding es cuando la relación con el cliente es más fragil.
Ese patrón produce tres consecuencias medibles:
Velocidad dependiente de disponibilidad. Si una de las tres personas estaba ocupada, el onboarding se pausaba. El cliente nuevo esperaba. El equipo sabia que era un problema y no había forma de resolverlo sin contratar.
Criterio no transferible. Cuando cambiaba el criterio de captación, había que reentrenar al equipo. No actualizar un sistema: reentrenar personas. El conocimiento estaba en sus cabezas, no en el proceso. Según [Gallup]([The State of AI de McKinsey](agendar un diagnóstico operativo
de marzo de 2025: instalan herramientas sin codificar el criterio que las hace útiles.
La diferencia no es de herramienta. Un flujo de automatización conecta pasos. La Codificación de Criterio extrae el criterio del equipo, lo deja auditable, y delega ejecución al agente con escalación explicita.
La instalación duro seis semanas. Los tres pasos canonicos del framework se mapearon así sobre el caso documentado.
Paso 1 · Backtest Operativo (semanas 1, 2 y 3) reemplazar a un empleado cuesta entre la mitad y el doble de su salario anual, y eso sin contar el conocimiento tacito que se lleva consigo.
Techo estructural. La capacidad de crecer no la marcaba la demanda sino las horas humanas disponibles para onboardings. Con la operativa en ese estado, el máximo razonable era 5-8 clientes nuevos al mes antes de que la calidad del proceso empezara a degradarse.
La pregunta correcta no era "como hacemos el onboarding más rápido". Era "como convertimos este SOP en algo que ejecute sin depender de que las personas correctas estén disponibles al mismo tiempo".
Se resuelve con ---
Codificación de Criterio: el método con tres pasos que aplicamos en cada instalación#
Cuando analizamos el onboarding de El Codigo Reforma, identificamos algo que los 47 pasos del SOP no capturaban: el contexto operativo del equipo.
No era solo "crear carpeta en Notion" o "enviar email de bienvenida". Era saber que en clientes con ticket premium había que escalar al founder para la primera sesión de extracción. Que en verticals atipicos había que generar un brief extra antes de empezar con los creativos.
Que si el buyer persona tenia más de tres segmentos diferenciados, el plan de captación necesitaba validación antes de activarse.
Ese criterio no estaba en ningun documento. Vivia en las cabezas de las tres personas que ejecutaban el onboarding.
A esto lo llamamos Codificación de Criterio: el proceso por el que extraemos el criterio operativo implicito del founder y su equipo, lo traducimos a reglas ejecutables auditables, y lo entregamos a un agente que opera con escalación humana solo por excepción. No es fine-tuning de modelo. No es RAG genérico. Es metodología de extracción de SOPs implicitos.
Lo aplicamos siempre en tres pasos secuenciales:
- Backtest Operativo. Validar el criterio codificado contra 20-50 casos históricos antes de tocar producción.
- Calibración Humana. 2-4 semanas de output revisado al 100% por el equipo, con feedback estructurado que afina las reglas.
- Régimen Autonomo. Estado estable. El agente opera con 95% sin intervención. El humano supervisa por excepción.
Tres componentes hacen posible este nivel de autonomía:
- Extracción del criterio operativo, no el ideal. El equipo describe lo que deberia pasar. Hay que observar lo que pasa. La diferencia suele ser donde vive el tiempo perdido.
- Codificación auditable. Cada decisión del agente queda registrada. Si en tres meses el criterio cambia, se actualiza una regla y el sistema lo aplica al siguiente cliente. Sin reentrenar a nadie.
- Políticas de escalación explicitas. El agente no es autonomo al 100%. Sabe cuando hay un caso fuera de umbral, lo identifica y escala al humano con contexto suficiente para que la decisión sea rápida.
Con estos tres componentes en su lugar, el agente no necesita supervisión constante. La necesita por excepción. Si quieres saber si el patrón encaja en tu operativa actual, puedes pedir un diagnóstico de viabilidad y revisamos contigo el SOP existente.
Por que las soluciones habituales no resuelven esto#
La respuesta instintiva ante un proceso lento suele ser contratar más personas, implementar un software de gestión de proyectos, o montar un flujo de automatización con herramientas como n8n o Zapier. Las tres funcionan a medias. Las tres tienen el mismo defecto de fondo: no codifican el criterio, solo mueven datos o aaden capacidad de ejecución manual.
Contratar resuelve el cuello de botella temporalmente. La persona nueva necesita aprender el criterio del equipo. Durante ese aprendizaje, la calidad baja. Y cuando la persona se va, el conocimiento se va con ella. El techo sube pero la fragilidad no desaparece.
Software de gestión (ClickUp, Asana, Notion mejorado) da visibilidad y estructura. Pero el proceso sigue necesitando que alguien ejecute cada paso. Hay checklists, hay asignaciones, hay calendarios. No hay ejecución autonoma.
Flujos de automatización conectan herramientas y mueven datos entre sistemas. Pueden disparar un email cuando llega un pago, crear una carpeta en Drive, enviar una notificación en Slack. Pero no toman decisiones. No saben cuando un cliente tiene un vertical atipico y hay que ajustar el plan de captación. No saben cuando escalar al humano y cuando seguir solos.
Se rompen ante cualquier caso que no este explicitamente mapeado. Es el mismo patrón que explica por que más del 80% de las organizaciones no ven impacto tangible en su EBIT después de implementar IA generativa, según el informe [The State of AI de McKinsey](agendar un diagnóstico operativo
de marzo de 2025: instalan herramientas sin codificar el criterio que las hace útiles.
La diferencia no es de herramienta. Un flujo de automatización conecta pasos. La Codificación de Criterio extrae el criterio del equipo, lo deja auditable, y delega ejecución al agente con escalación explicita.
La instalación duro seis semanas. Los tres pasos canonicos del framework se mapearon así sobre el caso documentado.
Paso 1 · Backtest Operativo (semanas 1, 2 y 3)
Revisamos 40 onboardings cerrados de los últimos 6 meses. Entrevistamos al founder, a ops y a dos client managers. Mapeamos el contexto operativo: cuando subir precio, cuando escalar una decisión, cuando pausar el proceso.
El hallazgo más importante: había 11 puntos de fricción que concentraban el 70% del tiempo perdido en cada onboarding. Todos eran decisiones que el equipo tomaba de forma intuitiva y que no estaban documentadas en ningun sitio.
Los 47 pasos del SOP se tradujeron a reglas ejecutables con traza. Cada decisión del agente queda registrada y es reversible. Se definieron políticas de escalación por tipo de caso: volumen atipico, vertical nueva, ticket premium.
La validación final se hizo contra 12 casos históricos. El agente producia los mismos outputs que había producido el equipo en esos 12 casos. Donde había diferencia, se refinaba la regla hasta que los outputs coincidian. Aquí se cometio un error que costo dos semanas más adelante: 12 casos no fueron suficientes para cubrir verticales atipicas.
La regla canonica del framework pide 20-50. Volveremos a esto.
Paso 2 · Calibración Humana (semanas 4 y 5)
El agente se conecto sobre las herramientas que ya usaban: Stripe para verificación de pago, HubSpot para creación de contacto y deal, Gmail y Calendar para bienvenida y agenda de kickoff, Notion para carpeta del cliente y plan de activación, Slack para supervisión humana por hilos, Meta Ads para cargas iniciales de creatividad.
Cero migraciones. Sin forzar al equipo a cambiar tooling. El agente opera sobre el stack existente, no requiere uno nuevo.
Los primeros 15 onboardings corrieron con validación humana en cada output. El umbral de consistencia se definio antes de empezar: número de decisiones correctas consecutivas necesarias para reducir la supervisión a excepción.
En esta fase se afinaron 8 reglas que el backtest no había detectado y se incorporaron las verticales nuevas a las políticas de escalación.
Paso 3 · Régimen Autonomo (desde la semana 6)
A partir de la semana 6, el agente corrio autonomo con escalación por motivo escrito. Desde entonces, el founder recibe un informe semanal de desempeño generado por el propio sistema. Cada caso escalado lleva razón explicita y contexto suficiente para decisión rápida.
El sistema no es estático. Cuando aparece un patrón nuevo recurrente, se incorpora como regla. Cuando el founder cambia un criterio, se actualiza una línea y el siguiente cliente lo recibe. La empresa deja de depender de que las personas correctas estén disponibles al mismo tiempo.
Resultados cuantificados: 90 días en régimen autonomo#
Los números que siguen corresponden a los 90 días posteriores a la consolidación del sistema, comparados contra los 90 días previos a la instalación. Todos proceden de la operación en activo de El Codigo Reforma.
Tiempo por cliente nuevo: de 3 semanas a 30 minutos desde firma hasta que el agente entrega el plan ejecutable.
Personas involucradas: de 3 personas coordinando en paralelo a 1 persona revisando outputs generados por el agente.
Autonomía del sistema: del 0% (cada paso requeria decisión humana con el SOP en pantalla) al 95% (el agente escala al humano solo cuando el criterio lo pide).
Coste operativo mensual del proceso: reducción del 66%. Un FTE liberado. Dos personas reasignadas a expansión de cuenta.
Techo de crecimiento: de 5-8 clientes nuevos al mes sin romper la operativa a capacidad para 100 o más clientes al mes sin ampliar equipo.
Ventas: crecimiento superior al 300% en los 90 días posteriores a la instalación. La relación causal directa es que el equipo que antes coordinaba onboardings paso a trabajar en captación y expansión de cartera.
La cita del founder, en sus propias palabras: "Teniamos un onboarding que tardaba 3 semanas con 3 personas dedicadas. Ahora tarda 30 minutos con 1 persona supervisando. El 95% del proceso es automático. Hemos multiplicado por 20 la capacidad sin contratar."
Lo que no funciono: honestidad sobre el proceso#
Ningun sistema de esta complejidad llega a régimen autonomo sin fricciones. Estas fueron las tres principales en este caso.
El backtest inicial fue corto. Los 12 casos históricos que usamos cubrian los patrones más comunes, pero no los atipicos. La regla canonica del framework pide 20-50 y la incumplimos por presión de calendario. En los primeros 15 onboardings con supervisión aparecieron 3 casos con verticales que no estaban en el backtest.
Requirieron intervención humana y refinamiento de las políticas de escalación. Esto sumo dos semanas que el plan inicial no contemplaba. La calibración humana absorbio el coste, pero el equipo esperaba más autonomía desde la semana 4 y se llevo una primera impresión más tibia de la esperada.
La extracción de contexto operativo fue más larga de lo previsto. Se estimo inicialmente 3 días de entrevistas. Se convirtio en 5. En el patrón que hemos observado en empresas 7-8 cifras, el contexto operativo del founder no es lo que el founder cree que hace: es lo que hace cuando nadie mira. Esa diferencia requiere observación, no solo entrevistas.
La integración con Meta Ads fue la más fragil. Las APIs de Meta cambian con frecuencia. En el periodo analizado hubo un cambio en la estructura de permisos que requirio un ajuste de la integración. El resto del stack (Stripe, HubSpot, Google Workspace, Notion, Slack) fue estable.
Estas fricciones no invalidan los resultados. Forman parte del proceso, y nombrarlas sirve para que quien lo replique tenga expectativas calibradas.
Codificación de Criterio aplicada en otros procesos#
El framework no es exclusivo del onboarding de cliente. La capa que hoy se rompe en la mayoría de empresas medianas es la primera: el criterio vive en cabezas, no en el sistema. Resolverlo no es contratar más personas, ni añadir otra herramienta de gestión, ni probar otro GPT genérico.
Lo hemos aplicado en nuestro propio onboarding de un cliente nuevo en la primera semana. Cuando un lead cualificado entra al funnel, hay un set de pasos que antes ejecutaba Albert manualmente: validación del fit del ICP, generación del briefing inicial, propuesta de slot de diagnóstico, prep de la llamada con contexto del prospecto.
El contexto operativo de "que prospecto vale la llamada y cual no" estaba en su cabeza. Codificarlo en reglas redujo la primera fase a minutos y libero la atención para las llamadas de cierre.
El mismo patrón se aplica con la misma lógica en:
- Onboarding de proveedor o partner.
- Renovación anual de contrato con cliente existente.
- Entrega de informe periodico (mensual, trimestral) con personalización según cliente.
- Activación de un nuevo producto o servicio en cuenta existente.
- Recuperación de clientes en riesgo de churn con criterio de intervención explicito.
Cada uno de estos procesos tiene un SOP que existe en alguna forma y un contexto operativo que vive en cabezas. El framework opera siempre igual: extraer, codificar, validar contra histórico, calibrar con humano, llegar a régimen autonomo.
Para quien NO funciona Codificación de Criterio#
Antes de proponer este framework a una empresa, comprobamos cinco filtros. Si no se cumplen, lo decimos. El coste de instalación no se justifica y es mejor invertir en otras cosas.
Empresas con un solo operador del proceso y sin previsión de crecimiento. Si el onboarding lo ejecuta solo el founder y la demanda es estable, el ROI llega tarde. La instalación se justifica cuando hay coordinación entre 2 o más personas o cuando la demanda crece más rápido que la capacidad de ejecución manual.
Procesos sin SOP documentado. Codificar exige algo que codificar. Si el proceso vive solo en intuición sin pasos repetibles, primero hay que escribir el SOP. Esa fase no es Codificación de Criterio, es ingenieria operativa básica.
Empresas con criterio operativo todavia inestable. Si el equipo cambia el criterio cada dos meses porque el negocio aún está encontrando su modelo, codificar es prematuro. El sistema no debe perseguir un blanco móvil: hay que esperar a que el criterio se estabilice y luego instalar.
Founders que no quieren delegar criterio. Hay perfiles que disfrutan ejecutando ellos cada decisión operativa. La instalación exige que el founder ceda criterio al sistema con confianza. Si esa cesión no esta sobre la mesa, el agente nunca llega a régimen autonomo y la inversión se desperdicia.
Empresas por debajo de 7 cifras de facturación. En empresas más pequeñas el coste de instalación es desproporcionado al volumen de procesos repetidos. La metodología funciona, pero es el momento equivocado.
Si tu empresa cumple los cinco filtros de exclusión, este framework no es para ti hoy. Si los cumple en 6-12 meses, lo será entonces.
Para empresas que sí encajan, el patrón es claro. Si por el contrario tu operativa encaja con los criterios de instalación, agendar un diagnóstico operativo es el siguiente paso. Revisamos el SOP existente, mapeamos el contexto operativo y decidimos si la instalación tiene sentido en tu empresa antes de proponer nada más.
