INITE Protocol: 6 etapas aplicadas en un deploy real del Q2-2026

Qué es este post y qué no es

El INITE Protocol es la metodología de 6 etapas detrás de cada deploy B2B SME que entrega INITE. Break, Hold, Track, Cut, Cast, Form. Los nombres son etiquetas de etapa y la mayoría de los lectores puede adivinar el sentido por la palabra. Lo que es más difícil de transmitir - y lo que cualquier overview de metodología con sabor a consultoría omite - es qué hace el equipo realmente en cada etapa, qué artefactos salen y qué decisiones se toman.

Este post llena ese vacío. Recorre un deploy del Q2-2026 en una firma de servicios profesionales de 60 personas, doce de ellas consultores que facturan (anonimizado; sector, escala y patrón de proceso preservados, nombres y cifras comercialmente sensibles removidos). Dos workflows en producción entregados en 19 días corridos desde el arranque de Cast, contra una construcción de $24K. El año uno más o menos empata. El retorno vive en el año dos. Esa es la forma que tiene de verdad una primera automatización, y es la forma que casi ningún caso de estudio quiere mostrar.

Cada número de abajo pertenece a este único engagement, y cada uno se deriva de otro número de esta misma página: los volúmenes salen de los sistemas, las horas de los volúmenes, el dinero de las horas a una tarifa cargada declarada. Donde un beneficio no se pudo precificar así, queda nombrado y fuera del retorno en lugar de estimado dentro de él. INITE no publica un promedio entre clientes, porque no hay uno medido que publicar. El protocolo en sí está documentado en lib/brand-canonical.ts (whatShipped), locales/<lang>/common/protocol.json, y el JSON-LD HowTo en components/StructuredData.tsx.

Etapa 1 - Break (Semana 1-2): Diagnosticar y Resetear

La etapa Break responde una pregunta: ¿hay aquí un proceso cuya matemática de automatización sobreviva al escrutinio? Si sí, seguimos. Si no, terminamos el engagement y reembolsamos el depósito del diagnóstico.

Qué hacemos. Entrevistas con stakeholders (CEO, COO, 1-2 operadores de frente - en este caso el socio que lleva la práctica, la office manager y 2 consultores sénior). Observación del proceso - acompañamos el trabajo real por 4-8 horas por workflow objetivo. Pull de datos - ingestamos 90 días de datos operativos de los sistemas existentes (CRM, herramienta de proyecto, billing, time tracking). Medición de baseline - instrumentamos el proceso actual con timing, throughput y conteos de error.

Artefactos producidos.

1. Mapa de proceso con marcadores de cuello de botella. Un diagrama swimlane de cada paso en el workflow objetivo, con throughput cuantificado, tasa de error y tiempo de ciclo en cada handoff. Para este deploy mapeamos 3 workflows candidatos. (a) Calificación de leads entrantes: 34 leads por semana, 22 minutos de tiempo del coordinador de operaciones cada uno para investigación, carga en CRM y ruteo, o sea 12,5 horas por semana, más 6 horas por semana de tiempo de consultor rehaciendo trabajo por leads mal ruteados. Primera respuesta mediana 38 horas; 24% de los leads no tuvo respuesta dentro de cinco días hábiles. (b) Actualizaciones de status de proyecto: 26 engagements activos, una nota por semana cada uno, 40 minutos de tiempo de consultor por nota, o sea 17,3 horas por semana. (c) Conciliación de facturas y horas: 8 horas por semana de la office manager con 22% de tasa de error.

2. Reporte de costo-del-caos. Las horas de arriba, precificadas a costo cargado: $95 la hora de consultor, $45 la del coordinador de operaciones y la office manager, que es lo que la hora le cuesta a la firma proveerla y no lo que aparece en la nómina. Calificación de leads $1.133 por semana, actualizaciones de status $1.647, conciliación $360. Total $3.140 por semana, anualizado sobre 48 semanas laborales en lugar de 52, porque las vacaciones y las semanas flojas no se automatizan: $151K al año. Ese es el número contra el que se mide toda afirmación posterior.

   Las 38 horas de primera respuesta y el 24% de leads que nunca tuvo respuesta no están adentro. Ambos son reales, y ambos valen probablemente más que las horas, pero convertirlos en dinero exige suponer una tasa de conversión y un valor de negocio, y un supuesto no es una medición. Quedan en la página como hallazgos y fuera del retorno.

3. Matriz de prioridad. Cada workflow candidato puntuado en viabilidad de automatización (técnica, 0-100) contra retorno (negocio, 0-100). La parte alta de la matriz es lo que se construye en Cast; la baja es explícitamente diferida.

La calificación de leads puntúa más alto en retorno de lo que sus horas justifican por sí solas: es la menor de las dos líneas, $1.133 por semana contra $1.647. La puntuación es el único lugar donde al drop-off no precificado se le permite contar, porque la matriz es un ranking y no una suma, y un ranking puede cargar un juicio. El dinero de abajo no puede, y por eso ese mismo drop-off queda fuera de todas las cifras del resto del post. Decir cuál de las dos cosas está ocurriendo es toda la diferencia entre una matriz y una corazonada.

El tercer workflow no se construye en este engagement. Queda documentado como candidato de follow-up para un ciclo futuro, pero solo después de que la etapa Hold limpie los problemas de calidad de datos que lo hacen tanto menos viable como menos ROI hoy. El diferimiento honesto es parte de la metodología - no empaquetamos el malo para hacer el engagement más grande.

Decisión al final de Break. Los dos workflows que vale la pena construir cargan $2.780 por semana de los $3.140, o sea $133K al año. El modelo supuso que la automatización recuperaría el 60% de esas horas y no todas, porque las excepciones siguen siendo humanas: $70-85K al año. Construcción estimada en $24K, monitoreo y tuning en $750 al mes después. Los workflows entran en vivo al final del mes 3, así que el año uno recoge nueve meses de beneficio: unos $52K contra $33K de costo, un neto cerca de +$19K con payback alrededor del mes 9. El año dos, con solo el costo de soporte, queda cerca de +$61K. Decisión: avanzar a Hold.

A nadie en esa sala le pareció emocionante, que es la reacción correcta y la razón por la que se aprobó. Una primera automatización que se paga sola dentro de un año y compone después es un buen resultado normal. Una primera automatización a la que se le proyecta cuatro veces su costo en doce meses es un documento de venta.

Una etapa Break puede terminar aquí con un no. Si la aritmética con supuestos conservadores no hubiera quedado positiva - y el tercer workflow por sí solo no queda -, el depósito del diagnóstico vuelve y el engagement se detiene. Eso tiene que ser un desenlace real o nada de la medición de arriba significa algo.

Etapa 2 - Hold (Semana 2-3): Estabilizar y Arreglar

La etapa Hold responde: ¿se puede automatizar el proceso objetivo en su estado actual o necesita estabilización primero? Automatizar el caos es la forma más cara de hacer que sistemas lentos sigan siendo lentos para siempre; esta etapa detiene eso.

Qué hacemos. Para cada workflow que se construirá en Cast, identificamos las fuentes de datos upstream, reglas de validación y puntos de handoff que tienen que ser confiables para que la automatización funcione. Arreglamos los rotos. Documentamos los SOPs (procedimientos operativos estándar) para las versiones manuales de los pasos que permanecerán humanos - porque el nuevo workflow automatizado igual hará handoff a humanos en los bordes, y el lado humano tiene que ser consistente.

Artefactos producidos.

1. SOPs para workflows clave. Para este deploy: las reglas de triaje de email para leads entrantes (qué cuenta como lead calificado, qué se escala, qué se descarta - escrito por primera vez); la plantilla de actualización de status que el equipo venía improvisando; los requisitos de campos de datos para el CRM (cuáles son obligatorios al capturar el lead vs en la conversión).
2. Correcciones de calidad de datos. El CRM tenía tres valores de lead-source donde debería haber uno ("website", "web", "Website"). Los colapsamos. La herramienta de proyecto tenía 4 valores de status activos cuando el equipo solo usaba 3. Quitamos el muerto. El inbox de email tenía 14 reglas acretadas en 5 años, mitad muertas. Podamos a 6 reglas activas.
3. Correcciones manuales rápidas que ahorran tiempo inmediatamente. Dos de los cuellos de botella en el workflow de calificación de leads resultaron ser arreglables sin nada de AI - uno era una regla de reenvío de email que rutaba leads a un auto-responder de vacaciones; el otro era un bug de campo obligatorio en el CRM que forzaba a los consultores a reingresar los mismos datos dos veces. Ambos arreglados en Hold, antes de que comenzara Cast. Los ahorros de tiempo solo de Hold sumaron cerca de 6 horas por semana en el equipo - una victoria pequeña antes de que se entregara cualquier automatización, y esas horas están dentro de las cifras de la semana 12 de más abajo y no encima de ellas, porque la misma hora no se cuenta dos veces.

Hold es la etapa que la mayoría de las metodologías de "piloto AI" se saltan, y es la etapa que determina si el eventual workflow Cast tendrá inputs estables contra los cuales trabajar. Un workflow conducido por LLM que recibe valores de lead-source inconsistentes, valores de status ambiguos y emails ruteados al inbox equivocado producirá basura y el equipo culpará al AI. La etapa Hold asegura que el sustrato esté limpio.

Etapa 3 - Track (Semana 3-4): Medir y Analizar

La etapa Track responde: ¿cómo se ve realmente el proceso en producción instrumentada, no en el mapa basado en entrevistas que dibujamos en Break?

Qué hacemos. Instrumentamos cada paso del workflow con logging de eventos con timestamp - típicamente un middleware liviano que registra eventos del proceso (lead recibido, lead calificado, lead convertido, actualización de status enviada, etc.) con timing, identidad y desenlace. Recolectamos 2-3 semanas de datos sobre el proceso ahora-estabilizado de Hold. Encontramos patrones que el mapa estático perdió.

Artefactos producidos.

1. Dashboard de KPI (métricas en vivo). Un dashboard en tiempo real de los KPIs por workflow que se rastrearán a través de Cast y Form. Para este deploy: tiempo de ciclo por workflow, throughput por consultor, tasa de intervención (con qué frecuencia el operador sobre-escribe una decisión automatizada) y tasa de error. El dashboard se enciende en Track y queda encendido en todas las etapas subsecuentes - el equipo lo ve a diario.
2. Reporte de análisis de patrones. Los hallazgos no-obvios de los datos instrumentados. Para este deploy, tres hallazgos se destacaron. (a) 31% de los leads entrantes llegaban entre las 18h y las 8h hora local - el workflow manual no tenía a nadie en turno entonces y esos leads quedaban 12-16 horas antes de la primera respuesta (un hecho que el equipo no había medido porque nadie estaba mirando fuera de horario). (b) La mayoría de las actualizaciones de status salía en un solo lote el viernes por la tarde, que es por qué los clientes vivían el reporte como a ráfagas y no como semanal, y por qué nadie dentro de la firma lo había notado: desde adentro se siente como un ritmo semanal. (c) Los dos consultores que escribían las actualizaciones más largas eran también los dos con mayor tasa de renovación en sus engagements. Dos consultores no son una muestra y no prueban nada; alcanzó igual para decidir no ajustar la automatización hacia la brevedad, que es el tipo de llamada que un dashboard no puede hacer por vos.
3. Puntuaciones de viabilidad de automatización por paso del proceso. Una evaluación línea por línea de qué pasos en cada workflow son buenos candidatos a automatización (alto volumen, inputs bien definidos, criterios de éxito claros) vs cuáles deben quedar humanos (bajo volumen, inputs ambiguos, juicios). Para este deploy, la calificación de leads puntuó 82/100 (altamente automatizable), la generación del primer borrador de actualización de status puntuó 76/100 (automatizable con revisión human-in-loop), y el envío final orientado al cliente puntuó 38/100 (debe quedar humano, incluso después de borradores AI).

Track es lo que convierte la hipótesis de la etapa Break ("este proceso se ve lento y propenso a errores") en especificación de la etapa Cast ("este workflow tiene estos cuellos específicos en estos pasos específicos, con esta forma de datos específica"). Un equipo que se salta Track entrega un Cast que arregla la cosa equivocada.

Etapa 4 - Cut (Mes 2): Simplificar y Eliminar

La etapa Cut responde: ¿qué pasos en el proceso no deberían existir en absoluto, antes de que cualquiera de ellos se automatice?

Qué hacemos. Tomamos el mapa de proceso ahora-instrumentado de Track y caminamos paso a paso. Para cada paso, preguntamos: ¿este paso agrega valor, o es tejido cicatricial de un problema que ya no existe? Eliminamos los que no agregan. Fusionamos pasos duplicados. Reordenamos pasos donde el orden es arbitrario. Preparamos el proceso limpio como especificación para Cast.

Artefactos producidos.

1. Flujos de proceso enjutos. La versión limpia de cada workflow objetivo, lista para automatización. Para este deploy, el workflow de calificación de leads pasó de 11 pasos a 6. Cinco pasos eliminados: una entrada de datos duplicada (el CRM se actualizaba dos veces por razones de compatibilidad legacy que ya no eran ciertas hacía 18 meses), una aprobación redundante de gerente (añadida durante un problema de calidad anterior que se había resuelto), dos emails de seguimiento de status que nadie leía (medimos open rates - 4% y 7%), y una exportación manual de datos que alimentaba un reporte que nadie corría ya.
2. Pasos redundantes eliminados - conteo y categorías. A lo largo de los 2 workflows objetivo, 9 pasos eliminados de 22 - 41%. Es una proporción alta, y la razón es específica más que típica: la firma no había hecho una revisión de procesos en 4 años y el tejido cicatricial se había acumulado. Categorías: 4 entradas de datos duplicadas, 2 aprobaciones redundantes, 2 notificaciones muertas, 1 alimentación manual a un reporte muerto.
3. Especificaciones listas para automatización. Para cada paso que permanece y va a automatizarse, una spec escrita - forma de datos de entrada, criterios de éxito, manejo de errores, camino de escalación, métricas de monitoreo. Ese es el artefacto contra el cual construye Cast, y la prueba de su extensión es si el responsable de operaciones va a leerla entera de una sentada en lugar de hojearla. Ambas specs aquí pasaron esa prueba. Las specs escritas previenen el modo de falla más común de Cast, que es el equipo de ingeniería construyendo algo que no calza con lo que el equipo de operaciones acordó en Track.

Cut es la etapa que la mayoría de las iniciativas "vamos a agregar AI" lideradas por CTO se saltan porque nadie quiere pelear con el equipo sobre eliminar su paso de estimación. Peleamos. La matemática gana; las decisiones de eliminación se escriben con el volumen por paso de Track anexado como evidencia. Un equipo que no Corta termina automatizando el caos y bloqueándolo.

Etapa 5 - Cast (Mes 2-3): Construir e Implementar

La etapa Cast responde: ¿los workflows especificados se despliegan a producción y sobreviven al contacto con usuarios reales?

Qué hacemos. Construimos cada workflow contra la especificación congelada en Cut. Desplegamos a producción - no un entorno de demo, no un sandbox, el entorno real con los usuarios reales. Cableamos monitoreo antes del lanzamiento. Integramos con las herramientas existentes que el equipo ya usa - el CRM, el inbox, la herramienta de proyecto - en lugar de reemplazarlas.

Para deploys que se sientan sobre el ecosystem Inite (ver el post compañero sobre el runtime compartido @inite/*), la etapa Cast reusa @inite/assistant para el runner LLM, @inite/inbox para cualquier superficie de conversación, @inite/api-kit para el patrón de wrapper de request, @inite/incidents para el camino de escalación human-in-loop, y @inite/security para enmascarado de PII en el audit log. La infraestructura reusada comprime Cast de "construir todo" a "configurar la mayor parte y escribir la lógica de dominio". Para este deploy, el workflow de calificación de leads se entregó en 8 días corridos de spec congelada a leads reales en vivo.

Artefactos producidos.

1. 1-3 workflows automatizados en producción. Para este deploy: (a) workflow de calificación de leads en vivo en CRM + inbox de email - 100% de los leads entrantes ahora fluyen por el triaje AI, con operator-override disponible en cualquier paso; (b) workflow de actualización de status de proyecto en vivo en la herramienta de proyecto + email - genera borradores de actualización que el consultor revisa y envía. Ambos workflows entraron a producción en 19 días corridos desde el inicio de Cast.
2. Integración con las herramientas existentes de la firma. Sin nuevo dashboard para que el equipo aprenda. El workflow de leads aparece como reglas de automatización y comentarios generados por AI dentro del CRM existente. El workflow de actualización de status aparece como borradores en el flujo de email-compose existente. Las herramientas diarias del equipo no cambian; el AI es plomería invisible adentro de ellas. La adopción es el asesino silencioso de los pilotos; construir dentro del set de herramientas existente del equipo es como Cast lo evita. Usamos el patrón de registry de herramientas de @inite/assistant para exponer los workflows a cualquier agente que necesite llamarlos - incluyendo los agentes MCP-compatibles que el CTO de la firma usa para code review.
3. Entrenamiento del equipo y handover. Una sesión en vivo de 90 minutos por workflow con el equipo que lo operará, más un runbook escrito (3-5 páginas) por workflow cubriendo: cómo corre el workflow normalmente, qué métricas de monitoreo mirar, qué hacer cuando dispara una alerta, quién dentro es dueño del workflow, cómo escalar a nosotros. El runbook es el puente a Form.

Cast es también donde los chequeos de preparación para agentes de navegador se aplican a cualquier superficie orientada al operador que el workflow expone - porque si un agente AI va a manejar las herramientas de la firma para ayudar a humanos, las herramientas mismas tienen que ser legibles por agentes. Este es un detalle pequeño pero cada vez más importante en los deploys de 2026.

Etapa 6 - Form (Mes 3-6): Optimizar y Escalar

La etapa Form responde: ¿el workflow desplegado sobrevive 12 meses de uso real, y el equipo acumula una capacidad en lugar de recibir un proyecto puntual?

Qué hacemos. Vemos el tráfico de producción los primeros 90 días. Ajustamos el workflow contra datos reales, no asumidos. Escalamos a workflows adicionales en la misma plataforma. Pasamos la propiedad operativa a un dueño interno identificado.

Artefactos producidos.

1. Dashboard de monitoreo de performance. El dashboard de KPI de Track, ahora cableado a los workflows de producción y mirado a diario por el dueño interno. Mediciones de la semana 12 contra la línea de base que el operador firmó al final de Track: primera respuesta mediana a un lead entrante de 38 horas a 1,4 horas; leads sin respuesta dentro de cinco días hábiles de 24% a 9%; tiempo del coordinador de operaciones en manejo de leads de 12,5 a 3,5 horas por semana; tiempo de consultor en actualizaciones de status de 17,3 a 5,2 horas por semana; retrabajo de consultor por leads mal ruteados de 6 a 1,5 horas por semana. Las excepciones siguen yendo a una persona, que es por qué ninguna de esas cifras llega a cero y por qué conviene leer con cuidado una propuesta que prometa cero.
2. Optimización con base en datos de uso real. Cuatro rondas de tuning en los primeros 90 días. Semana 3: el clasificador marcaba demasiado fácil como no calificados a los leads borderline, así que se movió el threshold y el coordinador de operaciones dejó de tener que revisar cada mañana la pila descartada. Semana 6: los borradores se leían genéricos, así que entró retrieval de contexto por cliente desde la herramienta de proyecto. Semana 9: el camino de escalación hacía tanto ruido que la gente había empezado a ignorarlo, así que se le puso un gate de confianza delante. Semana 12: el log de overrides mostró tres tipos de lead que nunca deben auto-calificar, y esos pasaron a ser reglas duras. Nada de esto se podía hacer antes del go-live, porque ninguno de esos datos existía.
3. Plan de escala para la próxima ola de automatización. Con la plataforma viva, el ancho de banda del equipo se abre. Documentamos 4 candidatos de follow-on para el próximo ciclo: el workflow de conciliación de invoice/time diferido en Break (ahora viable porque Hold limpió los datos); una automatización de client-onboarding; un asistente de redacción de propuestas; una automatización de quarterly-business-review. Cada uno puntuado en la misma matriz viabilidad × ROI usada en Break. La firma eligió 2 para correr en Q3-2026; los estamos scopeando como un engagement separado.

El handover es la parte más difícil de Form. El dueño interno recibe acceso root a la config del workflow, al dashboard de monitoreo, al registry de prompts y al runbook de escalación. Quedamos disponibles en check-in trimestral el primer año, pero la responsabilidad operativa es de ellos. Los workflows sin un dueño interno identificado con presupuesto para tuning son los que silenciosamente se apagan en 6 meses. Rehusamos entregar Cast sin Form, y rehusamos llamar Form completo sin el dueño interno.

Cuánto costó el deploy y qué produjo

Las horas recuperadas cerraron en $95K al año contra unos $70-85K modelados. Esa es la dirección en la que una estimación debe fallar, y es la razón por la que el modelo supuso 60% de recuperación y no 90%.

La mejora en el drop-off no está en ninguna de esas cifras. Un cuarto de los leads entrantes quedando sin respuesta, bajando a menos de un décimo, con los tamaños de negocio de esta firma vale casi con seguridad más que todas las horas de la tabla juntas. Queda afuera porque nadie midió a qué convertían esos leads, y un número construido sobre una tasa de conversión supuesta habría vuelto imposible de falsar la tabla entera. Si la firma instrumenta eso el año que viene, pasa a ser una medición y entra.

Los números son de este deploy y de nada más. No hay un promedio publicado de INITE contra el cual contrastarlos, y no debería haberlo hasta que se mida sobre una muestra que valga la pena citar.

Qué es el protocolo en una frase

El INITE Protocol es como se ve una metodología cuando se construye al revés desde la pregunta "¿el workflow sobrevivió 12 meses de uso real?". Break / Hold / Track aseguran que la matemática es real. Cut asegura que el sustrato vale ser automatizado. Cast entrega software grado-producción contra un proceso limpio. Form hace que el cambio pegue. Saltarse cualquiera de las seis es como muere el dinero de la consultoría AI. Seguir las seis es como un workflow sigue corriendo el trimestre siguiente a que nos vamos.

Si tu matemática sobrevivió en Break, tu equipo es dueño de Form. Todo lo del medio es ingeniería.