Diagnóstico del bloqueo operativo en el departamento de IT, evidencia asociada e hipótesis de solución para la Fase 2.
Hallazgos e hipótesis de solución
01
Resumen ejecutivo
El cuello de botella en IT es un problema estructural, no de desempeño del equipo.
Lo observado confirma la existencia del bloqueo operativo, pero redirige su causa raíz. El equipo no está sub-performando: el modelo actual concentra conocimiento crítico en una sola persona y canaliza hacia IT tareas que no requieren un perfil de desarrollador.
Hallazgos principales
01Bus factor igual a 1. El 100% del contexto de negocio y del mapa de integración del stack reside en una sola persona del equipo.
02Tareas ruteadas al recurso equivocado. Envío de marketing outbound y gestión integral del CRM se ejecutan desde IT, sin requerir perfil técnico.
03Dos prácticas multiplican el costo de cada cambio: fragmentación de estilos CSS por formulario y duplicación de cursos por campaña.
04Equipo en riesgo de salida. Saturación sostenida y fricción crónica con los departamentos que solicitan tareas.
Hipótesis de solución — Fase 2
AReasignar la operación de marketing y CRM fuera de IT, vía capacitación dirigida y manuales.
BConsolidar el contenido duplicado para eliminar el multiplicador en Hyros, CRM y estilos.
CConstruir un sistema de documentación que habilite la transferencia autónoma de tareas y lleve el bus factor a ≥ 2.
DRedimensionar el alcance del rol de IT a su forma estructuralmente correcta, dado que la organización no produce desarrollo propio.
Implicación ejecutiva
Si el volumen operativo de IT se reduce ~80%, la capacidad técnica senior queda liberada para trabajo de mayor valor estratégico (consolidación de stack, mejoras de plataforma, nuevos proyectos internos), y la discusión sobre metodologías de planificación se vuelve innecesaria por reducción natural del volumen.
02
Alcance del encargo
Marco del trabajo y metodología.
01 — Mandato
Resolver el bloqueo operativo del departamento de IT.
02 — Formato
Consultoría externa, entregas incrementales.
03 — Horizonte
60 días, dos fases.
Fase 1: diagnóstico. Fase 2: ejecución.
04 — Outcome esperado
Mayor eficiencia en ejecución de tareas diarias.
Replanteo inicial
La propuesta original contemplaba la absorción full-time de las responsabilidades del líder técnico. La observación directa evidenció que el bloqueo no proviene del desempeño del equipo sino del diseño de responsabilidades y procesos. Se redefine el engagement a un rol de consultoría externa de 2 meses.
Metodología aplicada
Observación directa del flujo de tareas, entrevistas con el departamento de IT y managers de áreas solicitantes, revisión del stack técnico (6 sistemas integrados) y mapeo de dependencias de conocimiento.
03
Diagnóstico · Hallazgos
Cuatro hallazgos principales, con evidencia e implicación.
Nota editorialLas tareas, ejemplos y responsabilidades específicas citadas a lo largo de este diagnóstico son ilustrativas del análisis y fueron seleccionadas por su relevancia para los hallazgos. No pretenden inventariar ni describir exhaustivamente el trabajo que el departamento realiza hoy ni el que realizará a futuro.
HALLAZGO 01Riesgo estructural
Todo el conocimiento del stack reside en una sola persona.
El stack de la academia se compone de seis sistemas integrados entre sí. La lógica de integración, los puntos de falla y el contexto de negocio asociado a cada flujo están concentrados en una única persona del departamento.
Evidencia
6 sistemas integrados entre sí (Kajabi, GoHighLevel, Zapier, Monday, WordPress, Hyros)
La documentación disponible no describe los procesos con la profundidad necesaria para habilitar la transferencia autónoma de tareas
Ante cualquier cambio, integración o incidente del stack, la dependencia operativa recae sobre el perfil senior
Implicación
Ante una ausencia prolongada, no existe continuidad operativa. El riesgo no se ha materializado, pero tampoco está mitigado.
HALLAZGO 02Ruteo de tareas
IT ejecuta tareas operativas que no requieren perfil de desarrollador.
Dos bloques de responsabilidades asignados hoy al departamento de IT no tienen componente técnico real. Su ubicación actual absorbe capacidad de un recurso escaso sin generar valor marginal proporcional.
Evidencia
Envío de mensajes de marketing outbound
Gestión integral del CRM (GoHighLevel)
Configuración de tags de tracking (Hyros) por cada campaña
Implicación
El recurso técnico senior queda atado a operación no técnica, lo que desplaza en cola las tareas que sí requieren su perfil.
HALLAZGO 03Procesos no escalables
Dos prácticas actuales generan un costo marginal creciente por campaña.
La fragmentación de CSS y la duplicación de cursos por campaña introducen un multiplicador en cada cambio: lo que debería ser una modificación puntual requiere intervención en múltiples ubicaciones.
Evidencia
CSS fragmentado: cada formulario tiene estilos propios; un cambio global requiere intervención manual en N lugares
Duplicación de cursos: cada campaña genera un curso duplicado, que a su vez requiere un nuevo tag de Hyros, una configuración de CRM y una URL
Sin una convención de versionado o parametrización, no hay forma de diferenciar campañas sin duplicar el activo
Implicación
El costo marginal de lanzar la campaña N+1 crece linealmente con el número de campañas previas. El sistema se vuelve más lento con el tiempo, no más rápido.
HALLAZGO 04Capital humano
El equipo está saturado, con intención de salida y fricción inter-departamental.
El síntoma que originó la búsqueda externa es también un indicador de riesgo. Si la salida se materializa antes o durante la intervención, el bus factor descrito en el Hallazgo 01 se convierte en evento operativo.
Evidencia
Saturación sostenida reportada por el departamento de IT
La intención de contratación externa full-time se activó por la percepción de salida inminente
Los solicitantes no dimensionan el esfuerzo real de las tareas ("cambiar un color no debería tomar tanto")
Discusiones crónicas de plazo entre IT y otros departamentos
Implicación
La estabilidad del equipo durante la intervención está asegurada vía acuerdo directo con la dirección. La retención post-intervención depende del rediseño del rol propuesto en la Fase 2.
04
Evidencia visual
Arquitectura del cuello de botella.
Exhibit 01Múltiples áreas de la organización canalizan tareas hacia un único punto técnico.
NotaLas áreas y tipos de demanda citados son ilustrativos del patrón de convergencia; no representan la totalidad ni la complejidad de los pedidos que recibe el departamento.
Fuente: Observación directa del flujo de tareas · Fase 1 de consultoría
Exhibit 02El stack técnico se compone de seis sistemas integrados; el conocimiento de todos ellos reside en una sola persona.
Fuente: Mapeo de stack y revisión de documentación interna
05
Diagnóstico · Desagregación
Las cuatro fuentes del cuello de botella.
Desagregadas por tipo, origen y naturaleza: dos fuentes corresponden a ruteo incorrecto de tareas; las otras dos, a decisiones técnicas heredadas que generan un multiplicador.
01
Envío de marketing outbound
Tipo
Ruteo incorrecto
Ejecutor actual
Departamento de IT
Ejecutor objetivo
Marketing u operador con capacitación
Componente técnico
Ninguno sustancial
02
Gestión integral del CRM
Tipo
Ruteo incorrecto
Ejecutor actual
Departamento de IT
Ejecutor objetivo
Perfil asistente u operador interno
Componente técnico
Configuración puntual, no desarrollo
03
Fragmentación de estilos CSS
Tipo
Deuda técnica
Síntoma
Estilos por formulario, no sistema global
Efecto
Un cambio = N intervenciones
Mitigación
Sistema de estilos centralizado
04
Duplicación de cursos × tags de Hyros
Tipo
Decisión estructural
Síntoma
Un curso duplicado por campaña
Efecto compuesto
+1 tag Hyros, +1 CRM, +1 URL por duplicado
Mitigación
Unificación + parametrización (UTM / tags)
Nota
Las cuatro fuentes identificadas corresponden a los principales bloqueos observados durante la Fase 1, no a un inventario exhaustivo del trabajo del departamento. Los ejecutores objetivo y las mitigaciones propuestas son puntos de partida a validar en las próximas semanas, no decisiones finales.
Exhibit 03El efecto multiplicador de la duplicación: cada campaña añade activos adicionales en tres sistemas distintos.
NotaLos artefactos listados son ilustrativos del efecto multiplicador y fueron seleccionados para evidenciar el costo marginal; no representan la totalidad de las actividades derivadas de una campaña.
Lectura: cada nueva campaña genera cuatro artefactos en tres sistemas distintos, todos configurados manualmente
06
Fase 2 · En exploración
Cuatro frentes de trabajo para el rediseño operativo.
Las siguientes hipótesis están en evaluación durante las próximas 2–3 semanas. Se presentan con su premisa y la pregunta abierta asociada.
A
Reasignación de la operación de marketing y CRM
Las responsabilidades operativas que hoy ejecuta IT (envío de mensajes, gestión de CRM, configuración de tags) pueden migrar a un perfil no-técnico mediante manuales dirigidos y capacitación acotada.
Pregunta abierta
¿Existe un perfil dentro de la organización capaz de absorber estas tareas, o se requiere la incorporación de un rol asistente?
B
Consolidación del contenido duplicado
Es viable unificar cursos físicos y diferenciar campañas mediante tags y UTM parameters en lugar de duplicación. Esta unificación elimina el multiplicador documentado en Hyros, CRM y estilos.
Pregunta abierta
¿Qué limitaciones impone Kajabi al tracking granular por campaña sobre un único curso unificado?
C
Sistema de documentación habilitante
La documentación existe pero no está estructurada para habilitar la transferencia autónoma de tareas. Objetivo: construir un sistema de procesos documentados que lleve el bus factor de 1 a ≥ 2 al cierre del engagement.
Pregunta abierta
¿Qué procesos se priorizan primero para maximizar el impacto sobre el bus factor?
D
Redimensionamiento del alcance de IT
El alcance estructural del departamento es integración de herramientas, mantenimiento técnico y proyectos de mejora del stack. Reducido el volumen operativo no-dev, la capacidad técnica disponible se redirige hacia trabajo de mayor valor: consolidación de deuda técnica, optimización del stack y nuevos proyectos internos.
Implicación colateral
La adopción de metodologías de planificación pesadas deja de ser necesaria. El rediseño del alcance es el que resuelve el problema de planificación, no una nueva herramienta.
Exhibit 04Redimensionamiento del alcance de IT: estado actual versus estado objetivo tras la Fase 2.
NotaLas tareas listadas son ilustrativas del rediseño de alcance propuesto; no representan la totalidad ni la complejidad del trabajo que el departamento realiza hoy ni del que realizará a futuro.
Lectura: las tareas no-dev migran fuera de IT; las dev permanecen dentro de un alcance redimensionado
07
Marco de medición
Métricas de éxito para la intervención.
El volumen total de tickets resueltos se descarta como indicador: la intervención reduce ese volumen intencionalmente. El marco se concentra en velocidad, riesgo estructural y capital humano.
Métrica
Definición
Instrumento
Frecuencia
Lead time por ticketVelocidad end-to-end
Tiempo total desde la creación del ticket hasta su entrega. Incluye el wait time.
Monday / registro manual
Semanal · pre/post
Wait time por ticketDiagnóstico de cola
Tiempo entre la creación del ticket y el momento en que se trabaja activamente. Expone si el problema es capacidad o priorización.
Monday / registro manual
Semanal · pre/post
Cobertura de documentaciónBus factor
Porcentaje de procesos críticos con manual escrito y al menos una segunda persona entrenada para ejecutarlos.
Auditoría interna
T0 y T+60
eNPS del equipo de ITCapital humano
Score compuesto a partir de una encuesta de 5 preguntas. Delta pre/post es la lectura principal.
Encuesta (ver abajo)
T0 y T+60
Nota metodológica
Con un equipo de dos personas, el score numérico de eNPS es ruidoso. El valor principal proviene del delta entre mediciones y, especialmente, de la respuesta cualitativa de la pregunta 5.
Instrumento · eNPS del equipo de IT
Encuesta de cinco preguntas.
Aplicada en T0 (baseline) y en T+60 (cierre de engagement). Las preguntas 1 a 4 usan escala 0–10; la pregunta 5 es abierta.
01¿Qué tan probable es que recomiendes trabajar en el equipo de IT de Hundred Academy a un colega del rubro?Escala 0–10
02¿Qué tan claro sentís que es el alcance y las prioridades de tu rol en el día a día?Escala 0–10
03¿Qué tan sostenible sentís tu carga de trabajo actual en el mediano plazo (6+ meses)?Escala 0–10
04¿Qué tan reconocido sentís que es el esfuerzo técnico real de tus tareas por parte de quienes las solicitan?Escala 0–10
05Si pudieras cambiar una sola cosa del funcionamiento del equipo de IT, ¿cuál sería?Respuesta abierta
08
Agenda del engagement
Modo de trabajo, preguntas en exploración y fase de cierre.
Preguntas en exploración
Se resuelven a medida que los ciclos iterativos avanzan sobre cada frente. Condicionan decisiones estructurales, no el calendario del trabajo.
Q1¿Quién consume hoy los reportes de Hyros?
Determina si forma parte del bloque de tareas mal ruteadas o si ya está correctamente ubicada.
Q2¿Existe un perfil interno capaz de absorber la operación de marketing y CRM?
Alternativa: incorporación de un perfil asistente con ruta orgánica de crecimiento.
Q3¿Cuál es el sistema de priorización más adecuado al nuevo volumen redimensionado?
Hipótesis actual: un sistema ligero es suficiente una vez reducido el 80% del volumen.
Q4¿Qué limitaciones impone Kajabi al tracking granular sobre un único curso unificado?
Condición técnica previa a la consolidación de contenido duplicado.
Modo de trabajo
El engagement se ejecuta en ciclos iterativos sobre cada tarea del departamento de IT, no en fases secuenciales en cascada. Cada tarea atraviesa el mismo ciclo de forma independiente.
01Evaluación de la tareaObservación directa de cada tipo de tarea que entra al departamento: quién la solicita, quién la ejecuta, qué esfuerzo requiere, si está correctamente ubicada.
02Documentación del hallazgoRegistro del estado observado y del diagnóstico aplicable, en un formato que pueda ser consumido por otros equipos.
03Aplicación de la soluciónReasignación, consolidación, automatización, documentación o rediseño, según el tipo de hallazgo.
04Registro del progresoActualización continua del avance y comunicación informal de novedades a la dirección, sin estructura de reporte formal.
Fase de cierre · T+60
Handoff formal al finalizar el engagement.
Al término de los 60 días se entrega un handoff estructurado que consolida el trabajo realizado, documenta el cambio logrado y deja identificados los siguientes pasos posibles.
01
Documentación consolidada
Entrega organizada de todos los manuales, procesos y artefactos generados de forma incremental durante los ciclos iterativos. La dirección y los equipos reciben un único repositorio ordenado.
02
Estado pre / post
Reporte comparativo del departamento antes y después de la intervención: métricas baseline vs. T+60, tareas migradas, cobertura de documentación, eNPS del equipo.
03
Puntos de continuidad
Identificación de frentes que exceden el alcance de 60 días y pueden trabajarse más adelante, con prioridad estimada y esfuerzo asociado para futuras decisiones.
§
Cadencia del engagement
La entrega se estructura en incrementos, no en un único documento al cierre. El presente reporte formaliza el diagnóstico inicial; las comunicaciones subsiguientes adoptarán el formato apropiado a su contenido — notas de avance, documentación de procesos, reportes puntuales — culminando en el handoff formal de la fase de cierre.
Fin del reporte.
Preparado por
José Belisario
Consultor externo
Entrega de cierre
T+60 · Handoff formal
Documentación consolidada + estados pre/post
Hundred Academy
Volumen 02Mayo 2026
Reporte de consultoría Volumen 02 — Matriz operativa
Inventario, clasificación y plan de cinco semanas.
Visibilización completa del trabajo que hoy ejecuta el departamento de IT, su naturaleza real, y un plan de acción priorizado para ejecutar durante el solapamiento del relevo.
Matriz de tareas + plan de ejecución
01
Marco del volumen
Por qué este documento existe en este momento.
El diagnóstico inicial identificó un problema estructural. Esta matriz lo aterriza al inventario concreto de tareas y propone un plan ejecutable de cinco semanas: una de preparación con la senior sola, seguidas de cuatro semanas de solapamiento con la persona nueva que la reemplaza.
Lo que este volumen hace
01Visibiliza la operación completa de IT en una sola tabla, separando lo que es trabajo técnico real de lo que llegó al área por defecto.
02Clasifica cada tarea según una decisión accionable: mantener, delegar, automatizar, estandarizar o eliminar.
03Ordena la ejecución en cinco semanas, anclada al solapamiento con el perfil senior antes de su salida.
04Distingue lo que es decisión organizacional (de la gerencia) de lo que es trabajo de ejecución (de IT).
05Plantea la rearquitectura de la atribución en Kajabi como entregable dentro del scope del plan, condicionada a la aprobación de gerencia para incorporarse al cronograma semanal.
Lo que este volumen no resuelve
AEl rediseño del flujo de iniciativas para que IT participe en la definición técnica desde el inicio, no únicamente en la ejecución. Se propone el mecanismo, pero su adopción requiere apoyo desde gerencia.
BLa reasignación efectiva de tareas RevOps fuera de IT. Identificadas, pero su ejecución depende de decisiones de organigrama que exceden el alcance técnico.
CLa adaptación de la planificación operativa al equipo interno. Se nombra y desarrolla como cambio organizacional necesario, pero su ejecución excede el horizonte de cinco semanas.
Premisa de diseño del plan
El primer objetivo del plan no es reducir carga ni introducir mejoras. Es preservar la operación capturando el conocimiento que se va con el perfil senior. Toda mejora estructural se ejecuta después de que el conocimiento esté escrito.
02
Foto operativa actual
Distribución de tiempo del equipo de IT por categoría.
Equipo
2 personas
Senior + junior. Ambas en proceso de salida.
Relevo
1 persona
Una persona nueva, llega en S02 del plan.
Documentación
20%
Cobertura estimada de procesos críticos.
Bus factor
1
Conocimiento concentrado en perfil saliente.
Cubos operativos
6
Más sub-categorías escondidas dentro de "soporte".
Nuevas integraciones
25%
Mantenimiento incl. bola de nieve Kajabi
25%
Soporte transversal
15%
Notificaciones / newsletters contaminado por filtros de ofertas
LecturaEl naranja marca cubos cuya naturaleza real es operación de revenue, marketing o paraguas — actualmente absorbidos por IT. El azul marca trabajo técnico legítimo del área.
03
Inventario clasificado
Matriz de tareas con clasificación accionable.
Cada tarea se clasifica por su naturaleza real — técnica, de operaciones de revenue, marketing, o capturada por el patrón paraguas — y por la decisión que corresponde tomar en cada caso.
Convenciones de la matriz
MantenerTrabajo técnico legítimo de IT que debe permanecer en el área, en algunos casos con runbook documentado.
DelegarLa tarea no es técnica. Debe migrar a Marketing, RevOps interino o al área que la origina, con capacitación si hace falta.
AutomatizarEjecutable por script, monitoreo programado o integración. Esfuerzo bajo, recupero permanente.
EstandarizarExiste hoy de forma artesanal. Necesita documentación o gate de proceso para que sea repetible y auditable.
EliminarLa tarea no debería existir. Producto de una decisión arquitectónica errónea o de inercia organizacional.
NATURALEZA — ITTrabajo técnico real: infraestructura, integraciones, accesos, automatización a nivel de sistema.
NATURALEZA — REVOPSOperación del CRM, atribución, segmentación, reportes comerciales. Rol que la organización no nombra.
NATURALEZA — MKT OPSPlantillas, scheduling de envíos, mantenimiento de funnels y assets de campaña.
PARAGUASTarea sin componente técnico real, absorbida por IT porque no tiene dueño natural en otra área.
A
Soporte transversal
~15% del tiempo
Configuración de cuentas y accesosGmail, Kajabi, GoHighLevel, Slack — onboarding y permisos por sistema. Hoy en zona gris; en la práctica el asistente del dueño la opera por disponibilidad. Debe formalizarse fuera de IT con runbook estandarizado.
NaturalezaParaguas
AcciónDelegar
Prioridad
Alta — formalizar fuera de IT antes del relevo
Corrección de links de trackingHyros — links que dejan de funcionar y se descubren cuando ya hay un problema.
NaturalezaIT real
AcciónAutomatizar
Prioridad
Baja — good-to-have, hoy se atiende solo cuando hay error
Creación de ofertas en KajabiUna oferta nueva por cada vendedor o canal de origen para resolver atribución.
NaturalezaRevOps
AcciónEliminar
Prioridad
Crítica estructural
Listas inteligentes en CRM (GHL)Filtros por oferta para segmentación. Cada nueva oferta multiplica el mantenimiento de filtros.
NaturalezaRevOps
AcciónDelegar
Prioridad
Media — depende de resolver atribución
Workflows y funnels en GHLConfiguración de secuencias de comunicación, automatizaciones de seguimiento, lógica de pipeline.
NaturalezaRevOps
AcciónEstandarizar
Prioridad
Alta — alto consumo, requiere runbook estandarizado
B
Nuevas integraciones
~25% del tiempo
Construcción de integraciones nuevas
NaturalezaIT real
AcciónMantener
Prioridad
Alta — núcleo del rol técnico de IT
Validación post-entrega
NaturalezaRevOps
AcciónEstandarizar
Prioridad
Alta — cierra el loop de aprendizaje
C
Notificaciones y newsletters
~10% del tiempo
Schedulear envíos de plantillas existentesLas plantillas ya están creadas. La tarea es ejecutar el envío en la fecha correcta con la audiencia correcta.
NaturalezaMkt Ops
AcciónDelegar
Prioridad
Media — capacitar a marketing en la herramienta
Mantenimiento de filtros por ofertaCada nueva oferta de Kajabi obliga a actualizar segmentos en email y push. Síntoma del problema de atribución.
NaturalezaRevOps
AcciónEliminar
Prioridad
Estructural — desaparece al resolver atribución
D
Reportes
~10% del tiempo
Reportes recurrentes (semanales)Conciliación manual de resultados de campañas de email enviadas desde CRM y Kajabi. Kajabi no expone bulk export — extracción email por email. Sin componente técnico, pero requiere capacitación previa.
NaturalezaRevOps
AcciónDelegar
Prioridad
Baja — recurrente, predecible
E
Webinar mensual
~15% del tiempo
Actualización de fechas y workflowsConfigurar el ciclo del próximo webinar — landing, secuencia de emails, segmentación.
NaturalezaMkt Ops
AcciónEstandarizar
Prioridad
Alta — alta visibilidad de evento
F
Mantenimiento de estructura existente
~25% del tiempo
Bola de nieve de ofertas KajabiCrear ofertas + actualizar filtros en CRM, email y notificaciones. Crece monotónicamente: nunca decrece. Mecanismo de atribución que debería resolverse con UTMs, Hyros o cupones por vendedor.
NaturalezaParaguas / RevOps
AcciónEliminar
Prioridad
Crítica estructural — palanca de mayor impacto
Mantenimiento de Zaps en Zapier
NaturalezaIT real
AcciónEstandarizar
Prioridad
Alta — documentar antes de relevo
WordPress — actualizaciones de variables y coreVariables globales del itinerario de webinars + parches de seguridad y plugins.
NaturalezaIT real
AcciónMantener
Prioridad
Baja — bajo dolor, bajo esfuerzo
Estandarización de CSSReplicar cambios visuales en múltiples ubicaciones. No es trabajo recurrente, pero cada cambio es costoso.
NaturalezaMkt Ops / Frontend
AcciónEstandarizar
Prioridad
Baja — recupero acumulado por cada cambio
Contador del millón en homeActualización semanal manual del valor de ingresos generados por estudiantes hacia el objetivo de USD 1M.
NaturalezaParaguas
AcciónAutomatizar
Prioridad
Baja — quick win simbólico
G
Tareas IT que no figuraban en los cubos declarados
No estimado
Tickets con plataformas externasSoporte técnico con Kajabi, GHL, Hyros, JustCall. Volumen bajo pero requiere contexto técnico.
NaturalezaIT real
AcciónMantener
Prioridad
Baja — bajo volumen, IT por naturaleza
Soporte internoHerramientas y pequeños incidentes.
NaturalezaIT real
AcciónMantener
Prioridad
Media — interrupciones distribuidas
Offboarding de accesosHoy sin runbook y en zona gris. En la práctica el asistente del dueño ya opera parte por disponibilidad. Debe quedar fuera de IT con procedimiento estandarizado. Crítico dado que los dos miembros salientes son los que tienen accesos más amplios de la organización.
NaturalezaParaguas
AcciónDelegar
Prioridad
Crítica — riesgo de seguridad inmediato
Deuda técnica conocidaRiesgo heredado para la persona que entra.
NaturalezaIT real
AcciónEstandarizar
Prioridad
Media — registrar antes que resolver
Respuesta a incidentes fuera de hora
NaturalezaIT real
AcciónMantener
Prioridad
Media — mínimo: alertas para sistemas críticos
Conclusión de la matriz
Aproximadamente el 60–70% del trabajo actual del departamento es operación de RevOps, Marketing Ops o tareas paraguas sin componente técnico. La mayor palanca de tiempo no está en automatizar lo que IT hace, sino en sacar de IT lo que nunca debió entrar — y resolver la decisión arquitectónica que multiplica el costo de cada cambio.
04
Plan de acción · 5 semanas
Ejecución priorizada por riesgo, no por preferencia.
El plan se ancla al solapamiento con el perfil senior. La primera semana arranca con la senior en solitario para que la persona nueva, al llegar en S02, encuentre material preparado. Cualquier mejora estructural depende de capturar primero el conocimiento que está por irse — optimizar antes de documentar es invertir el orden.
Semana 01
Captura inicial · senior sola
Semana 02
Llega el nuevo · runbooks
Semana 03
Rediseño del flujo de decisión
Semana 04
Migración RevOps + quick wins
Semana 05
Cierre del traspaso · última con senior
Solapamiento senior + nuevo
S01 senior sola · S02–S05 con el nuevo
01Semana 01 · Senior sola
Mitigación de riesgo de continuidad
Capturar el conocimiento tribal antes que llegue el nuevo.
La persona nueva todavía no se incorporó. No introducir mejoras ni tocar la arquitectura. El único objetivo es que cuando llegue en S02 encuentre un documento por cada flujo crítico que hoy vive solo en la cabeza del perfil senior.
Bloqueador críticoLa documentación capturada esta semana es prerrequisito del resto del plan. Asignar tiempo protegido a la senior, sin tareas operativas nuevas.
01
Inventario escrito de los 5–6 Zapier vivos
Por cada Zap: qué hace, qué lo dispara, qué sistemas conecta, qué falla típica tiene, cómo se diagnostica. Una página por Zap.
Owner · Senior
02
Mapa de la arquitectura de atribución actual
Las ofertas vivas de Kajabi, qué representa cada una, qué filtros del CRM dependen de cuáles, qué newsletters apuntan a qué segmentos. Diagrama en una hoja.
Owner · Senior
03
Inventario de workflows críticos en GHL
Cuáles son los workflows activos, cuáles están dormidos, cuáles tocar y cuáles no, cuáles fueron pedidos puntuales que siguen vivos.
Owner · Senior
04
Runbook completo de gestión de accesos
Inventario de cuentas por sistema y procedimientos de onboarding y offboarding. Documentado para que la operación quede en el asistente del dueño, no en IT. Incluye la revocación de la senior y la junior como caso de uso inmediato.
Owner · Senior + Asistente del dueño + Gerencia
05
Catálogo de fallas silenciosas conocidas
Las que el equipo ya sabe que existen pero no monitorean. Por cada una: cómo se manifiesta, cómo se diagnostica, cómo se resuelve.
Owner · Senior
06
Lista de deuda técnica conocida
Registro mínimo: qué problemas hay identificados, qué se decidió ignorar, qué riesgos persisten. Sin priorización todavía.
Owner · Senior
Riesgo si no se ejecuta
La salida del perfil senior se produce sin transferencia escrita. La operación pierde capacidad de diagnosticar fallas, mantener integraciones existentes y responder a cambios futuros del stack. Costo no recuperable.
Entregable S01
Carpeta de documentación viva con cobertura ≥ 60% de los flujos críticos no documentados, lista para que la persona nueva la encuentre al incorporarse en S02.
02Semana 02 · Llega el nuevo
Runbooks ejecutables
Que el nuevo pueda operar las tareas críticas en solitario.
La persona nueva se incorpora con la documentación de S01 ya disponible. El conocimiento capturado se convierte en runbooks paso a paso: el nuevo ejecuta tareas reales con la senior observando — no al revés.
ModalidadSombra invertida: el nuevo opera, la senior corrige y documenta lo que falta.
01
Onboarding técnico de la persona nueva
Lectura del diagnóstico (Vol. 01), esta matriz y la documentación capturada en S01. Acceso de solo lectura a todas las plataformas: Kajabi, GHL, Hyros, Zapier, WordPress, Monday. La provisión de accesos la opera el asistente del dueño, no IT.
Owner · Asistente del dueño + Senior + Nuevo
02
Runbook del ciclo de webinar mensual
Qué hay que actualizar, en qué orden, qué validar antes de publicar. Diagrama del flujo end-to-end.
Owner · Nuevo (con Senior)
03
Runbook de notificaciones y newsletters
Cómo schedulear, qué filtros usar, cómo verificar entrega. Preparado para que sea delegable a marketing más adelante.
Owner · Nuevo (con Senior)
04
Primera ejecución autónoma del nuevo
El nuevo ejecuta una tarea crítica de principio a fin con la senior solo presenciando. Identificar gaps en los runbooks creados.
Owner · Nuevo
Entregable S02
Dos runbooks operativos del núcleo de IT validados por uso real, con la persona nueva ya operando bajo modalidad de sombra invertida. La gestión de accesos queda fuera del scope de IT, operada por el asistente del dueño con runbook propio creado en S01.
03Semana 03
Decisiones organizacionales
IT pasa de brazo ejecutor a socio de decisión técnica.
El plan sale del ámbito ejecutivo de IT y entra al organizacional. Lo que se decide acá es cómo se va a definir cada iniciativa de aquí en adelante: si IT participa desde el problema o si solo recibe la solución a construir.
Decisión de gerenciaEl rediseño propuesto requiere que toda iniciativa pase por una conversación previa donde se comparta el objetivo de negocio antes que la solución técnica. Sin apoyo formal de gerencia, el flujo actual continúa.
01
Definir el flujo de iniciativas: intent antes que solución
Toda nueva iniciativa se conversa antes de construirse. Lo que se comparte con IT es el objetivo de negocio (qué problema se quiere resolver, qué métrica define éxito, qué hipótesis se está probando), no la solución técnica ya elegida. IT aporta criterio sobre el cómo y propone una validación mínima — piloto, prueba con muestra, ejercicio manual — antes de comprometer construcción. Aplicado a la próxima iniciativa entrante.
Owner · Gerencia + IT
02
Canal único de pedidos
Dejar de aceptar pedidos directos al equipo de IT. Toda solicitud pasa primero por la gerente de operaciones. Comunicado interno que lo formalice.
Owner · Gerencia
03
Plan de migración de tareas RevOps
Lista priorizada de qué tareas salen de IT, hacia quién, en qué plazo. Identificar quién absorbe (rol nuevo, persona existente con capacidad, o externo).
Owner · Gerencia
04
Decisión sobre la rearquitectura de atribución
Aprobación formal del cambio de mecanismo de atribución (sección 05). Si se aprueba, la rearquitectura se incorpora al cronograma del plan; si se posterga, queda como entregable nombrado pero fuera de la planificación. Asignar dueño de la decisión en ambos casos.
Owner · CEO + Gerencia
05
Validación de runbooks operativos
Cierre de gaps de los runbooks de S02. Casos reales ejecutados por el nuevo bajo observación; correcciones incorporadas en línea.
Owner · Senior + Nuevo
Entregable S03
Tres decisiones organizacionales formalizadas por gerencia: nuevo flujo de definición de iniciativas, canal único de pedidos, postura sobre atribución. Sin estas, el plan no escala.
04Semana 04
Migración RevOps + quick wins
Empezar a sacar tareas de IT mientras la senior aún está.
Las decisiones organizacionales de S03 entran en ejecución. La primera tarea sale efectivamente del área de IT y se delega. Si queda margen de tiempo, se incorporan los tres quick wins de observabilidad, marcados como opcionales.
HitoPrimera tarea reasignada efectivamente fuera de IT (newsletters a marketing). Backlog de deuda técnica priorizado.
01
Capacitación a marketing en envío de newsletters
Usar el runbook de S02 para entrenar a una persona de marketing. Primer envío ejecutado por marketing, no por IT, con la senior y el nuevo de respaldo.
Owner · Marketing + Nuevo
02
Designación de RevOps interino
Identificar quién absorbe formalmente — aunque sea parcialmente — las listas inteligentes y la segmentación. Puede ser persona existente con capacidad, no necesariamente un perfil nuevo. La operación se facilita una vez resuelto el problema de atribución en Kajabi (sección 05): hoy cada nueva oferta multiplica el mantenimiento de filtros.
Owner · Gerencia
03
Backlog priorizado de deuda técnica
Tomar la lista de S01 y priorizar por riesgo × esfuerzo. Identificar las 2–3 que conviene resolver en el siguiente trimestre.
Owner · Nuevo
04
Health check automático de links de Hyros opcional
Good-to-have, no entregable definitivo. Si queda tiempo: script programado que valida links periódicamente y alerta cuando uno deja de responder. Esfuerzo: medio día.
Owner · Nuevo
05
Monitoreo básico de Zapier opcional
Good-to-have, no entregable definitivo. Si queda tiempo: alertas a Slack o email cuando un Zap falla. Cubre el 2% de fallas silenciosas con las que hoy se vive. Esfuerzo: 1 día.
Owner · Nuevo
06
Automatización del contador del millón opcional
Good-to-have, no entregable definitivo. Si queda tiempo: script que actualiza el valor en home a partir de la fuente de datos correcta. Elimina una tarea semanal manual. Esfuerzo: medio día.
Owner · Nuevo
Entregable S04
Una tarea efectivamente reasignada fuera de IT (newsletters). RevOps interino designado por gerencia. Backlog de deuda técnica priorizado. Quick wins de observabilidad: solo si queda tiempo.
05Semana 05 · Última con senior
Cierre del traspaso
Cerrar el solapamiento y dejar la operación firmada.
Última semana con la senior presente. Foco en validar el traspaso con un ciclo real bajo observación, formalizar el cierre, revocar accesos y dejar la agenda del siguiente volumen abierta.
ValidaciónEl nuevo ejecuta un ciclo completo de webinar mensual con la senior solo de respaldo. Gaps detectados se cierran antes de la salida.
01
Webinar mensual ejecutado por el nuevo
Ciclo completo operado por la persona nueva, con la senior solo de respaldo. Test real de la documentación con margen para corregir antes de su salida.
Owner · Nuevo (con Senior de respaldo)
02
Reunión de cierre del traspaso
Senior + nuevo + gerencia. Revisar todo lo documentado, listar gaps conocidos sin resolver, formalizar el handoff.
Owner · Senior + Gerencia
03
Revocación completa de accesos de la senior
Aplicar el procedimiento de offboarding del runbook de accesos creado en S01. Validar revocación efectiva en cada sistema. Ejecutado al final de la semana.
Owner · Asistente del dueño + Gerencia
04
Definición de bolsa de horas residual de la senior
Acordar disponibilidad post-salida para consultas puntuales en las primeras 4–8 semanas. Reduce riesgo si emerge un gap no detectado.
Owner · Gerencia
05
Retrospectiva de las cinco semanas
Qué funcionó, qué quedó pendiente, qué riesgos persisten. Un documento corto, no una reunión larga.
Owner · Nuevo + Gerencia
06
Definir Vol. 03 — agenda post-estabilización
Si la operación sostiene autonomía, qué se aborda después: ¿adaptación de la planificación operativa? ¿automatización de reportes? ¿consolidación de stack? Próximos pasos en una hoja.
Owner · Consultor + Gerencia
Entregable S05
Traspaso formal cerrado, accesos de la senior revocados, bolsa de horas residual acordada por escrito. Vol. 03 con agenda definida para el siguiente ciclo.
Las palancas de mayor impacto
Dos secciones donde la decisión de gerencia define cómo continúa el plan.
La rearquitectura de la atribución en Kajabi (sección 05) está dentro del scope del plan, pero su entrada al cronograma semanal depende de la aprobación formal de gerencia. La adaptación de la planificación al equipo interno (sección 06) excede el horizonte de las cinco semanas y es trabajo del Vol. 03. Las dos secciones siguientes desarrollan cada una: qué requiere, qué decisión la activa, y por qué importa hacerlas visibles ahora.
05
Dentro del scope · pendiente de aprobación de gerencia
Resolver la atribución por ofertas duplicadas en Kajabi.
El diagnóstico identificó que existe un catálogo creciente de ofertas del mismo curso en Kajabi, usadas como mecanismo de atribución de ventas. Es la decisión arquitectónica que más tiempo libera de IT a mediano plazo. Su ejecución queda dentro del scope del plan, condicionada a la aprobación formal de gerencia: una vez aprobada se incorpora al cronograma semanal; hasta entonces se mantiene nombrada y dimensionada, sin entrar a la planificación.
Lo que está pasando hoy
01Cada nuevo canal o vendedor se resuelve creando una oferta nueva en Kajabi. La oferta existe solo para diferenciar el origen de la venta.
02El catálogo de ofertas crece en cada ciclo. Cada incorporación de canal o vendedor suma una entrada al inventario, y nada del proceso actual lo frena.
03Cada oferta arrastra configuración satélite — filtros del CRM, segmentos, links — que recae en IT por defecto.
04El reporte de ventas se construye agregando ofertas, no canales ni vendedores. Conciliar atribución consume tiempo recurrente y requiere conocimiento histórico.
Lo que requeriría resolverlo
AReemplazar la atribución por oferta con un mecanismo nativo de tracking: UTMs en links, Hyros como fuente única, o cupones por canal o vendedor. Explorar cuál encaja con la operación actual antes de comprometer construcción.
BRediseñar el reporte de ventas para que su input sea la nueva fuente de atribución, no el catálogo de ofertas. Cambia cómo se reporta — el dato y la decisión que se toma sobre él no cambian.
CAcuerdo formal de gerencia para no crear ofertas nuevas como mecanismo de atribución. Sin esa decisión, cualquier solución técnica se erosiona en el ciclo siguiente.
DDecidir el corte histórico: migrar el inventario actual al nuevo modelo, o aceptar que el cambio aplica desde una fecha específica hacia adelante.
Decisión que activa esta línea
La complejidad técnica de la rearquitectura es manejable; el desafío central es organizacional. Adoptar un mecanismo de atribución distinto al que hoy alimenta el reporte de ventas requiere alineamiento explícito de gerencia. La aprobación formal de ese cambio es la condición que habilita su incorporación al cronograma del plan. Sin esa decisión, la rearquitectura permanece como entregable enunciado y la operación continúa generando nuevas ofertas en cada ciclo.
06
Más allá del horizonte · cambio organizacional
Adaptar la planificación al área de IT como departamento interno.
El cambio de modalidad — de un perfil senior tercerizado por objetivos a un equipo interno con jornada acotada — todavía no fue absorbido por la planificación operativa de la empresa. La consecuencia inmediata es que el equipo trabaja por encima de su jornada para sostener los ritmos previos. La consecuencia a mediano plazo es desgaste y riesgo de salida.
PUNTO 01Carga de reuniones
El tiempo neto disponible para operar es menor del que la planificación supone.
El equipo asiste a una cantidad significativa de reuniones que consumen buena parte de la jornada disponible para ejecutar tareas. En paralelo, se espera autogestión del tiempo por departamento — sin un mecanismo que reconcilie ambas demandas.
Implicación
La capacidad efectiva para tareas técnicas se reduce sin que la planificación lo refleje. La carga se compensa extendiendo la jornada, no recalibrando los compromisos de entrega.
PUNTO 02Cadencia diaria sin dependencias
La planificación opera en ciclos diarios sin contemplar el tiempo real de las tareas técnicas.
Un objetivo del día puede ser "actualizar X imagen", y se espera que IT lo ejecute en la misma jornada — sin importar a qué hora se libere el insumo previo. Si diseño entrega la imagen al final del día, se espera que IT actualice al final del día.
Implicación
Las dependencias entre áreas (diseño → IT, marketing → IT) no están consideradas en la cadencia. IT actúa como búfer al final de la cola, absorbiendo el costo de lo que las áreas anteriores no completaron a tiempo.
PUNTO 03Cambio de modalidad sin ajuste
Las expectativas de entrega no se ajustaron al cambio de tercerizado a interno.
El perfil senior anterior trabajaba como tercerizado y cobraba por objetivo: cualquier cantidad de horas era aceptable dentro de su contrato. El equipo actual es interno, con jornada de ocho horas — pero las expectativas de entrega siguen calibradas al ritmo anterior.
Implicación
El cambio contractual no fue absorbido por la planificación. Hoy se sostienen los ritmos anteriores extendiendo la jornada, lo que es la causa directa del desgaste reportado y del riesgo de salida del equipo.
Lo que abre esta sección
Esto no se resuelve con documentación ni con automatización: es un ajuste de cómo el resto de la organización pide trabajo a IT. Es una conversación de gerencia — análoga a la del flujo de iniciativas (S03), pero específica de la cadencia operativa diaria. Material para Vol. 03.
Fin del volumen 02.
Preparado por
José Belisario
Consultor externo
Próximo volumen
Vol. 03 — Cierre de gestión
Inventario de lo realizado y estado del traspaso
Hundred Academy
Volumen 03Junio 2026
Reporte de consultoría Volumen 03 — Cierre de gestión
El cuello de botella, destrabado.
Inventario del trabajo realizado durante el acuerdo y el estado en que queda la operación al cierre: más liviana, documentada y operada por el equipo nuevo, sin dependencia del perfil saliente.
Inventario de cierre
01
Cierre del acuerdo
Lo que el acuerdo deja resuelto.
Este volumen inventaría el trabajo realizado durante el acuerdo y el estado en que queda la operación al cierre. El diagnóstico inicial identificó un cuello de botella: el flujo de tareas que llegaba a IT saturaba al equipo y se apoyaba en el conocimiento de un único perfil. Al cierre, ese flujo bajó de forma sostenida, el conocimiento crítico quedó documentado, y la operación pasó a manos del equipo nuevo.
En una línea
El problema que motivó el acuerdo quedó resuelto: el cuello de botella está destrabado y la operación ya no depende del perfil que la sostenía.
02
Lo realizado
Lo que queda hecho.
A
Traspaso y continuidad operativa
Conocimiento documentado
Documentación de la operación críticaInventario de workflows de GoHighLevel, runbook del ciclo de webinar mensual y runbook de notificaciones y newsletters. La operación que vivía en la cabeza del perfil senior quedó escrita y ejecutable.
EstadoEjecutado
Onboarding y primera operación autónoma del perfil nuevoEl perfil entrante se incorporó sobre la documentación capturada y ejecutó tareas críticas de punta a punta de forma autónoma, con respaldo del perfil saliente.
EstadoEjecutado
Migración de tareas RevOps fuera de ITLa organización incorporó un perfil dedicado de RevOps que absorbió esas tareas y los envíos de newsletters. El flujo de pedidos hacia IT bajó de forma sostenida.
EstadoEjecutado
Reunión de cierre del traspasoRevisión de lo documentado y formalización del handoff con el equipo nuevo y gerencia.
EstadoEjecutado
B
Construcciones e iniciativas técnicas
Entregado en el período
Integración JustCall ↔ GoHighLevelHabilita a los vendedores un canal de comunicación directa con sus prospectos desde el propio CRM.
EstadoEjecutado
Pipeline de carga de videos — Backblaze B2Script, interfaz e infraestructura para la carga de videos del programa de becas, integrada en GoHighLevel: el enlace queda embebido en el formulario y los operarios no necesitan entrar a Backblaze.
EstadoEjecutado
Diagnóstico de operaciones de ITAnálisis de causa raíz del cuello de botella, evidencia de soporte y marco de medición. Es el cuerpo de los volúmenes 01 y 02 de este reporte.
EstadoEjecutado
Resultado
Con las tareas de RevOps fuera del área, IT quedó como un departamento que una sola persona sostiene sin sobrecarga.
03
Estado de cierre
Cómo queda la operación.
Equipo IT
1 persona
Un solo perfil sostiene el área sin sobrecarga.
Continuidad
Autónoma
La operación la sostiene el equipo nuevo por su cuenta.
Documentación
Cubierta
Flujos críticos escritos y validados por uso real.
Relevo
Cerrado
El equipo nuevo absorbió la operación sin incidencias.
Naturaleza de IT
Técnica
Con RevOps fuera del área, IT quedó concentrado en trabajo técnico real.
El perfil nuevo se incorporó y opera la totalidad de la operación. Los perfiles senior y junior salieron, y el equipo entrante absorbió el trabajo sin incidencias.
Decisiones de la organización
La rearquitectura de la atribución en Kajabi, planteada en el volumen anterior, quedó sin ejecutar por decisión de la organización: la estrategia propuesta aislaba el impacto al propio Kajabi, pero se optó por mantener el estado actual. El mantenimiento que esto genera ya no recae sobre IT; salió del área junto con las tareas de RevOps.
Recomendación · métricas finales
Sobre los entregables de medición previstos —lead time y wait time por ticket, eNPS del equipo de IT— la recomendación es no ejecutarlos. Fueron pensados para evaluar la operación del equipo original; con el cambio de equipo y la delegación de tareas a otras áreas, los números no serían comparables ni representativos. El objetivo que esas métricas debían verificar —destrabar el flujo que era el cuello de botella— ya está cumplido.
Activo técnico transferido
Trabajando sobre la unificación del CSS de formularios y surveys de GoHighLevel se identificó un mecanismo para centralizar todo el CSS de ambos temas de color, claro y oscuro. La parte difícil —descubrir cómo hacerlo— ya está resuelta; lo que resta es ejecución. El conocimiento ya se transfirió al equipo en una llamada grabada, disponible para consulta cuando la organización decida ejecutarlo.