Caso de Estudio
El Sistema Funcionaba.Nadie lo Usó.
Construimos un sistema de IA que hacía exactamente lo que habíamos acordado. A la semana, el equipo del cliente seguía copiando contactos a mano en una hoja de cálculo. Publicamos este caso porque el error no fue técnico y porque cambió el orden en el que trabajamos.
Antes
No era un Problemade Tecnología
Los contactos entraban por varias vías y, antes de que alguien pudiera contestar, había que hacer tres cosas a mano: decidir si el contacto valía la pena, averiguar quién era y de qué empresa, y escribir la respuesta. Tres tareas pequeñas que, multiplicadas, se comen la mañana. Y mientras se comen la mañana, el contacto espera.
Nadie nos pidió inteligencia artificial. Lo que nos pidieron fue dejar de elegir entre contestar rápido y contestar bien. Ese era el encargo, y ese sigue siendo el orden: primero el problema, después la herramienta.
La Entrega
El Sistema queConstruimos
Un sistema que se sentaba encima del CRM y del correo que ya usaban, sin cambiarles de herramienta. Leía los contactos nuevos, los clasificaba por intención, los enriquecía con datos de la empresa y respondía. Cada paso dejaba registro, así que todo era medible desde el primer día.
En la entrega funcionaba.
No es un matiz de cortesía: es el dato que hace que este caso valga la pena contarlo. Si el sistema hubiera fallado, la lección sería técnica y aburrida. No falló.
Una Semana Después
Lo que Pasóa la Semana
No hubo incidencia. No hubo queja. No hubo una llamada diciendo que algo no iba.
A la semana el sistema seguía ejecutándose y no había nadie dentro. El equipo comercial seguía abriendo el CRM cada mañana, copiando los contactos a mano y pegándolos en la hoja de cálculo de siempre, donde los clasificaba, los buscaba y los contestaba como llevaba haciéndolo desde antes de que apareciéramos.
La hoja de cálculo ganó.
Lo difícil de una no adopción es que no se parece a un fallo. Los registros estaban en verde, el cliente estaba contento y el trabajo se seguía haciendo dos veces. Un sistema caído se detecta en minutos. Un sistema que nadie usa puede tardar meses en detectarse, y para entonces ya has facturado.
El Diagnóstico
Hablamos con el Dueño,No con el Equipo
El dueño nos contó el proceso como él cree que es, y lo contó de buena fe. Las personas que lo hacen cada día lo conocen de otra manera: saben qué contactos hay que mirar dos veces, qué correo no se manda un viernes y en qué casos la respuesta correcta es no responder todavía. Ese conocimiento no está en ningún documento y no se descubre en una reunión con dirección.
Y tenían dos cosas que nosotros no habíamos preguntado. La primera, desconfianza: una IA contestando en su nombre a contactos de los que responden ellos. La segunda, una necesidad concreta y razonable — ver durante un tiempo qué decidía el sistema antes de dejarle decidir solo.
Si tu nombre va en el correo que sale, quieres leer el correo que sale.
Las Señales que No Leímos
- 01
Todas nuestras reuniones fueron con la misma persona, y esa persona no iba a tocar el sistema ni un día.
- 02
El proceso que estábamos sustituyendo nos lo describió quien lo paga, no quien lo hace.
- 03
Nadie nos pidió un paso de revisión. Tampoco nadie nos dijo que no lo necesitaba: no lo preguntamos.
- 04
Leímos «al cliente le ha encantado» como «el equipo lo va a usar». Son dos frases distintas y las dijo la misma persona.
Lo que Cambiamos
Cambiamos el Orden,No la Tecnología
La parte técnica de aquel proyecto la volveríamos a construir igual. Lo que va delante es lo que cambió. Antes eran dos conversaciones: entender el problema con quien paga y luego construir. Ahora son tres, en este orden y no en otro.
Primero, con quien va a usar el sistema.
Con la pantalla delante y sin dirección en la sala. No pedimos que nos «expliquen el proceso»: pedimos que lo hagan mientras miramos. Cuatro preguntas que hoy no nos saltamos:
- ¿Cómo lo haces hoy, paso a paso, con la pantalla delante?
- ¿Qué parte de esto te da igual que la haga una máquina, y qué parte no?
- Si el sistema se equivoca, ¿quién da la cara?
- ¿Qué tendrías que ver para dejar de revisarlo?
Después, con quien lo paga.
Con el proceso ya escrito y corregido por quien lo hace. Aquí se decide alcance, plazo y precio cerrado, y aquí se resuelven las discrepancias entre cómo dirección cree que funciona el proceso y cómo funciona. Esa conversación es incómoda una vez, o es una no adopción después.
Solo entonces abrimos la herramienta.
Y la elegimos con lo que hemos oído en las dos conversaciones anteriores, no antes de tenerlas. Es la misma regla que ya teníamos escrita y que aquel proyecto nos obligó a aplicar de verdad: primero entendemos el problema, después elegimos la herramienta. No recomendamos IA donde no hace falta.
Y entregamos con el paso de revisión encendido.
No es una conversación, es una decisión de diseño. El sistema propone y una persona aprueba, corrige o descarta antes de que nada salga. No es una versión recortada del sistema: es la primera fase del sistema. El automático no es el punto de partida, es el punto de llegada — y la fecha la pone el equipo, no nosotros.
Después
Aquí Iría el Porcentajeque No Tenemos
No lo tenemos autorizado y no lo vamos a estimar. Lo que sí podemos decir es qué cambió en la forma de entregar: el sistema volvió a entrar por la bandeja de revisión, con el equipo dentro y decidiendo, y con un criterio de salida acordado con ellos antes de encenderlo. Y desde entonces medimos la adopción, no solo la ejecución: cuántas sugerencias se aprueban sin cambios, cuántas se corrigen, cuántas se descartan y cuánta gente entra cada día.
Cuánto tardó el equipo en pedir que apagáramos el primer tramo de revisión, qué parte del proceso está hoy en automático y si la hoja de cálculo sigue abierta son cosas que sabemos y que no vamos a publicar sin permiso del cliente.
Preferimos un caso sin cifras a un caso con cifras que no podríamos defender en una llamada.
El Método
Lo que ComprobamosAntes de Construir
Esto no es propiedad de nadie. Si vas a automatizar un proceso que hoy hace una persona, sirve igual con nosotros que sin nosotros. Y el punto 7 es el que habría cazado este caso.
- 01
Habla con quien lo hace, con la pantalla delante.
No con quien te lo puede describir. Con quien lo hace.
- 02
Escribe el proceso como te lo ha contado esa persona, y que ella lo corrija.
Por escrito. Las correcciones son el mapa real; el primer documento nunca lo es.
- 03
Pregunta quién da la cara si el sistema se equivoca.
Quien da la cara tiene derecho de veto, esté o no en el organigrama del proyecto.
- 04
Define, antes de construir, qué tendría que ver esa persona para dejar de revisar.
Si no hay criterio de salida acordado, la revisión se convierte en trabajo extra permanente y el sistema se abandona.
- 05
Entrega con revisión, no con automático.
La confianza se gana viendo aciertos, y para verlos hay que poder mirarlos.
- 06
Apaga la revisión por tramos, y que lo pida el equipo.
Un tramo cada vez, y siempre reversible. Si hay que volver a encenderla, se enciende.
- 07
A las dos semanas, comprueba si el proceso viejo sigue vivo.
Busca la hoja de cálculo, el cuaderno, el grupo de WhatsApp. Si el proceso viejo sigue vivo, el sistema no se ha adoptado — funcione o no. Esto se mira, no se pregunta: a la pregunta la gente contesta que sí.
La Prueba
No te Fíes.Ábrela por Dentro
El sistema con el que trabajamos está publicado en abierto, con licencia MIT, porque también lo usan los alumnos de nuestro programa de formación. Nos viene bien que esté ahí: significa que puedes auditar cómo trabajamos antes de contratarnos, en vez de creerte un caso anonimizado escrito por nosotros.
github.com/pauberenguer/ai-agency-osPúblico · MIT · publicado 27 ago 2026- 111
- skills en cinco pilares: sistema, clientes, entrega, resultados, operaciones
- 10
- subagentes con su encargo escrito: auditor, analista, estratega, redactor, revisor…
- 23
- comandos de operación: /auditoria, /propuesta, /informe, /doctor…
- 6
- comprobaciones automáticas en cada cambio, incluida «sin secretos»
- 2
- hooks de calidad que revisan el material antes de que salga
- 1.042
- ficheros. Ninguno oculto: es el repositorio entero
Si prefieres no fiarte tampoco de estas cifras, cuéntalas tú:
# clona y cuenta — treinta segundos
git clone --depth 1 https://github.com/pauberenguer/ai-agency-os.git
cd ai-agency-os
find skills-library -name SKILL.md | wc -l # skills
ls .claude/agents | wc -l # subagentes
ls .claude/commands | wc -l # comandosY si solo vas a abrir un fichero, abre .claude/agents/auditor.md. Es el encargo que le damos al subagente que audita webs de clientes, y su tercera regla es esta:
«Solo hallazgos con evidencia. Si no puedes verificar algo, lo marcas [no verificable sin acceso] — jamás lo inventas.»
Esa regla, escrita para una máquina, es la misma con la que está escrita esta página: cada cifra que has leído se puede comprobar, y las que no, no están. Hay incluso un hook, .claude/hooks/entregable-gate.sh, que revisa cada documento antes de que salga hacia un cliente y avisa si encuentra un hueco sin rellenar, un «TODO» o texto de relleno. Lo escribimos porque nos hacía falta.
Este caso costó dinero y confianza, y lo publicamos porque el criterio que salió de él vale más que el proyecto. Si estás a punto de automatizar algo que hoy hace una persona, el punto 7 es gratis: mira si la hoja de cálculo sigue abierta.
NorthScale — consultora de IA, automatización y desarrollo a medida. Auditoría de 30-45 minutos, sin compromiso: northscale.es/auditoria. Si vemos que no podemos ayudarte, te lo decimos.
Caso anonimizado. Sin cifras de cliente sin autorización. Sin capturas sin anonimizar.