Claude para Negocios

El problema real de una agencia pequeña

En un equipo de tres a veinte personas, casi nunca falta talento. Lo que falta es proceso escrito. La auditoría que el cliente paga bien se hace bien porque la hace una persona concreta, y esa persona lleva cuatro años haciéndola. Sabe qué mirar primero, sabe qué preguntas hacerle al cliente antes de empezar, sabe qué hallazgo no vale la pena reportar porque genera ruido, y sabe cómo se redacta la recomendación para que el cliente la apruebe en lugar de discutirla. Nada de eso está en ningún documento. Está en su cabeza.

Esto produce tres síntomas que cualquiera que dirija una empresa pequeña reconoce. El primero es que la calidad es inconsistente: el mismo servicio, vendido al mismo precio, sale distinto según quién lo ejecute esa semana. El segundo es que incorporar a alguien es caro de verdad, no en salario sino en tiempo del equipo senior, que deja de facturar para explicar por tercera vez lo mismo. El tercero es que el negocio no escala: para hacer el doble de trabajo hace falta el doble de gente, y cada persona nueva tarda meses en llegar al nivel de la anterior.

La conclusión que se saca demasiado rápido es que la solución es documentar mejor. Y sí, en parte lo es, pero los manuales de procedimiento tienen un problema conocido: nadie los lee. Se escriben una vez, se guardan en una carpeta compartida y se desactualizan en tres meses. El documento existe pero no cambia el comportamiento de nadie, porque leerlo cuesta más que preguntarle al compañero de al lado.

Aquí es donde Claude cambia el cálculo, y conviene ser exacto sobre por qué. No es una forma de reducir plantilla. Es una forma de externalizar el procedimiento: convertir el conocimiento tácito en algo que se ejecuta, no en algo que se archiva. La diferencia entre un manual y un sistema es que el sistema se usa porque usarlo es el camino más rápido, no el más virtuoso.

De SOP a Skill: el procedimiento que se ejecuta

Una Skill es una carpeta con un archivo SKILL.md que Claude carga cuando la tarea lo requiere. El mecanismo importa: en el contexto solo vive la descripción, una línea que dice de qué trata la Skill, y el archivo completo se lee únicamente cuando el trabajo lo pide. Se llama divulgación progresiva y resuelve el problema clásico de los manuales, que es que todo el manual pesa aunque solo necesites una página.

Para una agencia esto se traduce en una regla simple: una Skill por entregable recurrente. No una Skill genérica de "cómo trabajamos", sino una por cada cosa que se vende más de tres veces. La auditoría técnica, el reporte mensual de resultados, el brief creativo, la propuesta comercial, el informe de cierre de proyecto. Cada una con su estructura, sus criterios de calidad, sus ejemplos de lo que se aprueba y lo que se rechaza.

Escribir la primera cuesta trabajo, y ese trabajo es el punto. La forma que funciona es sentarse con la persona que hace ese entregable bien, tomar el último que entregó, y preguntarle por qué cada decisión. Por qué ese orden. Por qué se omitió ese dato. Qué habría hecho distinto si el cliente fuera de otro sector. Esa conversación es el activo. La Skill es solo el formato en el que se guarda.

El resultado que se busca es concreto: que la décima auditoría de cliente se parezca a la primera. No idéntica, porque cada cliente es distinto, pero sí con la misma estructura, la misma profundidad y los mismos criterios. Cuando eso pasa, el entregable deja de depender de quién esté disponible esa semana, y la conversación con el equipo cambia de "hazlo como lo hace Marta" a "sigue el sistema y avísame dónde no encaja".

Hay un efecto secundario que suele sorprender: la Skill se convierte en el mejor material de incorporación que existe. Alguien que entra al equipo no lee un manual de cuarenta páginas. Ejecuta el proceso real desde el primer día, con el sistema marcando la estructura, y aprende viendo qué se corrige. El tiempo hasta la primera entrega útil baja de meses a semanas, y el tiempo del senior deja de irse en explicar lo mismo.

MCP: conectar Claude a lo que la empresa ya usa

El segundo cuello de botella no es el criterio, es el acceso a la información. El trabajo real de una agencia vive repartido: los briefs en Drive, el código en GitHub, las decisiones en Slack, los datos de cliente en una base de datos o en una hoja de cálculo que alguien mantiene a mano. La forma habitual de trabajar con un modelo es copiar y pegar entre pestañas, lo cual funciona una vez y es insostenible como proceso.

MCP, el Model Context Protocol, es el estándar abierto que resuelve eso. Conecta Claude a herramientas y fuentes de datos externas, con la especificación pública en modelcontextprotocol.io. La consecuencia práctica es que el sistema deja de trabajar sobre lo que alguien recordó pegar y pasa a trabajar sobre la fuente real.

La forma correcta de pensarlo es como capa de integración, no como colección de conectores. La pregunta no es "qué integraciones tiene", sino "qué proceso deja de requerir intervención humana cuando el sistema puede leer esto". Si el reporte mensual necesita datos de tres sitios, conectar los tres convierte cuatro horas de recopilación en una revisión de veinte minutos. Si el brief creativo depende de encontrar el documento de marca correcto en Drive, conectar Drive elimina el paso donde alguien usa el documento del año pasado.

Y aquí entra el otro elemento técnico que cambia el diseño de los procesos: los modelos Fable, Opus y Sonnet trabajan con una ventana de contexto de un millón de tokens, lo que equivale aproximadamente a un mes de documentos de la empresa en una sola sesión. Haiku 4.5 trabaja con 200K, que es mucho para una tarea puntual pero no para una revisión completa. Eso significa que revisar la coherencia de todo lo entregado a un cliente en un trimestre deja de ser un proyecto y pasa a ser una tarea.

El coste es una disciplina operativa

Poner todo en el modelo más caro es cómodo y es un fallo de gestión. La diferencia entre Haiku y Fable es de diez veces en entrada y de diez veces en salida. En una agencia que procesa volumen, esa diferencia no es un detalle de factura: es la diferencia entre un sistema que se paga solo y uno que hay que justificar cada mes ante el socio que firma.

El criterio de enrutado que funciona es sencillo. Haiku 4.5 para todo lo que sea alto volumen y baja ambigüedad: clasificar tickets, extraer datos de facturas, etiquetar contenido, comprobar formato. Sonnet 5 para el grueso del trabajo, que en una agencia es redacción, análisis, revisión y la mayoría de los entregables. Opus 5 para las decisiones difíciles: arquitectura de una solución, diagnóstico cuando algo no cuadra, trabajo agéntico con muchos pasos encadenados. Fable 5 cuando el problema lo justifica de verdad y el coste está previsto, no cuando alguien lo eligió por defecto en un menú.

Lo que convierte esto en disciplina y no en buena intención es medirlo. Un proceso que corre cien veces al mes tiene un coste unitario, y ese coste unitario debería estar escrito al lado del proceso, igual que está el tiempo que ahorra. Cuando las dos cifras están visibles, la conversación sobre qué automatizar deja de ser ideológica. Y cuando algo se pasa de presupuesto, la pregunta correcta no es si el sistema sirve, sino si esa tarea está corriendo en el nivel que le toca.

Dónde se queda el humano

Hay tres categorías donde la revisión humana no es opcional, y conviene que estén escritas antes de que aparezca el primer caso dudoso.

1. Todo lo que ve el cliente. Un entregable, un correo, una presentación, una respuesta en un canal compartido. El sistema puede producirlo entero, pero alguien del equipo firma antes de que salga. La reputación de una agencia pequeña se construye lento y se rompe en un envío.
2. Todo lo contractual. Propuestas con precio, alcance de proyecto, condiciones, plazos, cualquier cosa que cree una obligación. Redactar el borrador es una tarea. Comprometer a la empresa es una decisión, y las decisiones las toma una persona con nombre.
3. Todo lo irreversible. Publicar, desplegar, enviar a una lista, borrar, modificar datos de producción, mover dinero. La regla operativa es que si deshacerlo cuesta más que revisarlo, se revisa.

Fuera de esas tres, la autonomía es sana y necesaria: si todo requiere aprobación, el sistema solo mueve el cuello de botella de sitio. El objetivo no es supervisar más, es supervisar donde importa.

Datos y confidencialidad

Antes de meter material de cliente en cualquier modelo, de cualquier proveedor, hay preguntas que se responden una vez y se dejan por escrito. Qué dice el contrato con ese cliente sobre subcontratación y tratamiento de datos. Si hay un acuerdo de confidencialidad, qué alcance tiene. Qué información es identificable y si hace falta para la tarea, porque muchas veces no hace falta y se puede quitar. Quién dentro del equipo tiene permiso para conectar qué sistema, porque MCP amplía el acceso y el acceso hay que gobernarlo igual que se gobierna el de una carpeta compartida.

Un punto concreto y verificable que afecta a la decisión de modelo: Fable 5 requiere retención de datos de 30 días y no está disponible bajo retención cero. Si la empresa tiene clientes que exigen retención cero por contrato o por sector, ese trabajo no puede correr en Fable, y eso no es un detalle técnico sino una restricción operativa que hay que conocer antes de diseñar el proceso, no después de venderlo.

La postura razonable para una agencia pequeña es clasificar el material en tres niveles: público, interno y confidencial de cliente. Definir qué se puede procesar en cada nivel y con qué modelo. Y revisarlo cuando entre un cliente nuevo con exigencias distintas, que es exactamente cuando nadie se acuerda de revisarlo.

Un despliegue por etapas

El error más común es empezar por todo a la vez. La forma que funciona es empezar por un proceso, medido, y no tocar nada más hasta que ese esté funcionando.

El proceso que se elige primero debería cumplir tres condiciones: que se repita al menos varias veces al mes, que hoy consuma tiempo de gente cara, y que su calidad sea fácil de juzgar. Un reporte mensual cumple las tres. Una propuesta comercial estratégica no, porque es demasiado variable y demasiado cargada de contexto implícito para ser el primer caso.

Antes de empezar hace falta una línea base, y esto es lo que casi nadie hace. Cuánto tiempo tarda hoy ese proceso, medido de verdad y no estimado. Cuántas vueltas de corrección tiene de media antes de salir. Cuántas veces al mes se ejecuta. Sin esos tres números, cualquier afirmación posterior sobre mejora es una opinión.

Durante las primeras semanas se mide lo mismo, más dos cosas nuevas: el coste por ejecución y el porcentaje de salidas que necesitaron corrección de fondo, no de estilo. Que funcione significa que el tiempo por ejecución baja de forma sostenida, que las correcciones de fondo bajan a medida que la Skill se afina, y que el coste por ejecución es una fracción clara del valor de la hora que sustituye. Si esas tres curvas no se mueven en cuatro o seis semanas, el problema no es el modelo: es que el proceso no estaba tan claro como parecía, y esa también es información útil.

Solo cuando el primer proceso está estable se pasa al segundo, y el segundo cuesta menos porque ya existe el criterio, ya están las conexiones y ya está la clasificación de datos. El tercero cuesta menos todavía. Ese es el patrón: la inversión está casi toda al principio, y lo que se construye no es una herramienta sino una forma de trabajar que sobrevive a que alguien se vaya.