Cómo automatizar tu primer flujo de back-office con IA en 30 días [tutorial 2026]

TL;DR — Cómo automatizar el primer flujo con IA en 30 días

• Cuatro semanas, un único flujo, un sistema mínimo en producción. Esa es la cadencia realista para una empresa de servicios de 5-20 personas que arranca su primer proyecto de IA.
• Semana 1 — definir el flujo y elegir candidato: documentar el proceso actual en una página, decidir qué flujo automatizar (volumen alto, coste-hora alto, patrón repetitivo, bajo riesgo), congelar el alcance.
• Semana 2 — construir el sistema mínimo (MBS): stack típico Claude Sonnet 4 + Make/n8n + Notion. Sistema que procesa el flujo end-to-end con revisión humana obligatoria en cada output.
• Semana 3 — rodaje en paralelo con el flujo manual: el sistema procesa los mismos casos que el equipo. Se compara salida del sistema vs salida del equipo. Ajustes diarios al prompt y a la lógica.
• Semana 4 — paso a producción con revisión humana: el sistema entrega; el equipo revisa antes de finalizar. Métrica clave: % de outputs aceptados sin modificación.
• Coste realista del sprint: 4.000-8.000 € + 100-300 €/mes recurrentes. Equipo dedicado: 1 persona de operación 3-5h/semana + soporte técnico del proveedor.
• Tres criterios de éxito al día 30: >90% outputs aceptados, -50% tiempo del flujo, cero incidencias graves en últimas 2 semanas.
• Veredicto operativo: el ROI del primer flujo no es solo horas liberadas, es el aprendizaje sobre cómo IA encaja en TU operación. Sin ese aprendizaje, los siguientes flujos se construyen sobre supuestos no verificados.

Por qué un sprint de 30 días y no un proyecto de 6 meses

La trampa más común al implementar IA en empresa pequeña es planificar un proyecto largo: 6 meses para automatizar todo el back-office. Suena ambicioso, fracasa el 70% de las veces. Las razones son operativas, no técnicas:

• El equipo no aguanta 6 meses sin ver resultados. La motivación cae, el sponsor de dirección se cansa, el proyecto se diluye.
• El flujo de la empresa cambia en 6 meses. Lo que se documenta en enero ya no aplica en junio.
• No hay aprendizaje real hasta que algo funciona en producción. Construir tres flujos sobre supuestos que nunca se validaron multiplica el desperdicio.

Por eso en HEW lo hacemos al revés: un único flujo, en 30 días, hasta producción. Sale fallido o exitoso, pero sale. Y a partir de ese aprendizaje real, se decide el siguiente paso. La fase la llamamos El Primer Golpe y es la primera de las tres del proceso completo (detalle en el pillar de implementar IA).

Estos son los pasos exactos.

Semana 1 — Definir el flujo y elegir candidato

Cuatro tareas que se ejecutan en orden y consumen 8-12 horas de trabajo (entre el equipo del cliente y el equipo del proveedor).

Día 1-2: Mapeo del back-office y selección del candidato

Lista de todos los flujos de back-office que comen tiempo significativo del equipo. Para cada uno, registrar:

• Volumen mensual: cuántas veces se ejecuta el flujo al mes.
• Coste-hora: quién lo hace y cuánto cuesta esa hora (interna o externa).
• Tiempo por ejecución: cuánto se tarda cada vez.
• Patrón: ¿inputs y outputs estables o varían mucho?
• Riesgo si falla: ¿qué pasa si la IA se equivoca? ¿llega al cliente o queda en revisión interna?

Una lista típica para un despacho de 10-15 personas: clasificación de correo entrante, generación de propuestas comerciales, preparación de informes mensuales, onboarding administrativo de cliente nuevo, control de plazos administrativos, generación de borradores estándar.

Selección del candidato: el que cumple cuatro criterios acumulativos.

Si ningún flujo cumple los cuatro, bajar ambición: empezar con un sub-flujo más acotado del que más se acerca. El error es elegir un flujo grande “para que valga la pena”.

Día 3-4: Documentación del flujo en una página

El flujo seleccionado se documenta en un documento breve (una página A4, máximo dos). Sin esto, no se puede construir; con esto, se construye en semanas.

Estructura del documento:

1. Objetivo del flujo: qué problema resuelve.
2. Inputs: qué información recibe (de qué sistema, en qué formato, con qué frecuencia).
3. Pasos del proceso actual: cómo lo hace una persona hoy, paso a paso.
4. Outputs: qué produce (en qué sistema, en qué formato, qué define que está terminado).
5. Criterio de calidad: qué hace que el output sea “bueno”. Ejemplos concretos de outputs aceptados y rechazados.
6. Casos extremos: qué pasa cuando el input es raro (formato no estándar, datos faltantes, conflicto de información).
7. Responsable interno: quién valida la salida del sistema durante el sprint.

Si el flujo no se puede documentar en una página, no está suficientemente claro para automatizarlo. Volver a la fase de definición operativa antes de construir nada.

Día 5: Decisión técnica y congelación del alcance

Con el documento sobre la mesa, decisiones técnicas:

• Modelo: por defecto Claude Sonnet 4 (mejor razonamiento sobre castellano y output estructurado). Alternativas: GPT-5 si el equipo ya está integrado con OpenAI, Gemini 2.5 si el stack ya es Google Workspace.
• Orquestador: Make si el flujo es lineal y conecta servicios estándar (Gmail, Notion, Sheets, Slack). n8n si hay más lógica condicional o el equipo prefiere autoalojado. Código a medida si la integración requiere autenticación compleja, sistemas legacy o lógica que Make/n8n no permiten.
• Almacenamiento de inputs/outputs: Notion (si el equipo ya lo usa), Google Sheets (si lo natural es tabular), CRM existente (si ya hay HubSpot, Pipedrive, Holded).
• Punto de revisión humana: ¿dónde se valida cada output antes de finalizar? Notion con estado “pendiente revisión”, Slack con aprobación inline, email con botón de aprobar.

Congelación: el documento del flujo y el stack quedan cerrados al final de la semana 1. No se cambian durante las semanas 2-4. Si aparece la necesidad de cambiar, se anota para el siguiente sprint.

Semana 2 — Construir el sistema mínimo (MBS)

El objetivo es un sistema que ejecute el flujo end-to-end, aunque sea con calidad mediocre. La calidad se afina en la semana 3.

Día 6-7: Conectores y autenticación

Lo más aburrido y lo que más bloquea proyectos: conectar el orquestador (Make, n8n, código propio) con los sistemas de la empresa. Gmail/Outlook, Notion, Google Drive/SharePoint, CRM, etc.

Recomendaciones operativas:

• Usar cuentas de servicio dedicadas para el sistema, no la cuenta personal del responsable. Permite auditoría limpia y revocación rápida si algo falla.
• Para conectar con Notion y Google Workspace, los MCP oficiales publicados en 2024-2025 ahorran 1-2 semanas frente a integración a medida. Detalle en conectar Claude con Notion y Google Workspace.
• Validar permisos mínimos: el sistema solo debe acceder a lo estrictamente necesario para el flujo. Si lee correo, solo el buzón compartido relevante, no todo Gmail.

Día 8-10: Pipeline básico

Tres bloques que se construyen en orden:

1. Ingesta de inputs: el sistema lee la fuente (correo nuevo, documento subido, registro creado en Notion) y normaliza los datos.

2. Procesamiento con Claude: prompt estructurado que recibe los inputs, aplica el criterio del despacho documentado en la semana 1, y genera el output en el formato definido.

Plantilla genérica de prompt para un primer flujo:

Eres un asistente operativo para [empresa]. Tu tarea es [acción concreta].

Inputs que recibes:
[Estructura de los inputs]

Reglas a aplicar:
1. [Regla 1 con ejemplo]
2. [Regla 2 con ejemplo]
3. [Regla 3 con ejemplo]
...

Casos extremos:
- Si [input raro], entonces [acción específica]
- Si falta [dato], entonces [acción específica]

Devuelve el output en este formato JSON exacto:
{
  "campo1": "...",
  "campo2": "...",
  "explicacion_decision": "..."
}

El campo explicacion_decision es crítico: obliga al modelo a justificar su salida y facilita la revisión humana en la semana 3.

3. Escritura del output: el sistema escribe la respuesta en el destino (Notion, hoja de cálculo, sistema interno) y notifica al responsable de revisión.

Día 11-12: Logging y observabilidad mínima

Antes de cualquier rodaje, asegurar que el sistema registra:

• Cada input procesado, con timestamp.
• El prompt exacto enviado al modelo.
• La respuesta exacta del modelo (sin postprocesado).
• El output final escrito en destino.
• Cualquier error o excepción.

Sin este log no se puede iterar en la semana 3. Con él, cada ajuste al prompt se hace con datos reales sobre qué falla.

Al final de la semana 2 el sistema está construido y procesa correctamente al menos un caso del flujo end-to-end. No tiene calidad de producción todavía, pero el pipeline funciona.

Semana 3 — Rodaje en paralelo y ajuste

El sistema y el equipo procesan los mismos casos durante toda la semana. Se compara cada output del sistema con el output que produciría el equipo manualmente. Cada diferencia es un ajuste.

Día 13-15: Procesamiento dual

Cada caso real del flujo se procesa dos veces: una vez por el sistema (output A) y una vez por la persona que lo haría normalmente (output B). Las dos salidas se registran en una hoja de comparación.

Para cada caso, el revisor anota:

• ¿El output del sistema cumple el criterio del despacho?
• Si no cumple, ¿qué falta o qué sobra?
• ¿La explicación del modelo (explicacion_decision) revela un malentendido del criterio?

Volumen mínimo recomendado: 20-40 casos en la semana. Por debajo, no hay datos suficientes para ajustar; por encima, hay sobrecarga sobre el revisor.

Día 16-17: Ajuste del prompt y de la lógica

A partir del log de comparación, se identifican los 3-5 patrones más frecuentes de error del sistema. Cada patrón requiere una de tres acciones:

• Ajuste del prompt: añadir una regla específica que cubra el caso, con ejemplo concreto.
• Ajuste del orquestador: añadir lógica condicional antes o después del modelo (validaciones, filtros, transformaciones).
• Documentación del límite: si un caso requiere criterio humano no automatizable, marcarlo como “escalar a humano” y no intentar resolverlo con IA.

Es normal que la primera versión del prompt tenga 200-300 palabras y la versión iterada del día 17 tenga 600-1.000. El crecimiento del prompt viene de añadir ejemplos y casos extremos, no de añadir explicaciones genéricas.

Día 18-19: Validación con casos histórico

Sobre el sistema ajustado, procesar 20-30 casos del histórico (3-6 meses anteriores) sin volver a mostrarlos al revisor. Comparar el output del sistema con lo que se hizo realmente en su día.

Métrica esperada al final de la semana 3: 70-85% de outputs aceptables sin modificación. Si la métrica está por debajo de 70%, prorrogar la semana de ajuste. Si está en 85%+, listo para semana 4.

Semana 4 — Paso a producción con revisión humana

El sistema ya tiene calidad operativa. Esta semana se incorpora al flujo real del equipo, con revisión humana obligatoria pero ligera.

Día 20-21: Documentación operativa para el equipo

Antes de incorporar el sistema al día a día, documentar:

• Cuándo se ejecuta: en qué disparador (correo nuevo, formulario, planificado).
• Dónde ver los outputs pendientes de revisión: ubicación clara (vista de Notion, canal de Slack, etc.).
• Cómo revisar: criterio de calidad básico y casos en los que el revisor debe modificar.
• Cómo escalar problemas: a quién avisar si el sistema da output claramente erróneo.
• Cómo desconectar el sistema en caso de incidencia mayor (kill switch).

Esta documentación es una página A4. Si crece más, el sistema es demasiado complejo y se ha violado la regla del MBS.

Día 22-26: Operación con revisión obligatoria

El sistema procesa todos los casos del flujo. Cada output queda en estado “pendiente revisión”. La persona responsable de la operación valida (aprobar / modificar / rechazar) antes de que el output salga del sistema.

Métricas que se miden cada día:

• % outputs aceptados sin modificación.
• % outputs aceptados con modificación menor (<10% del contenido).
• % outputs rechazados o requieren rehacer.
• Tiempo medio de revisión humana por output.

Día 27-30: Cierre del sprint

Al final del día 30, evaluar los tres criterios de éxito:

Si los tres se cumplen: el sistema queda en producción con revisión humana ligera. Empieza una fase de estabilización de 4-8 semanas antes de tocar nada.

Si falla 1 o 2 criterios: prorrogar 2 semanas más de ajuste. No es fracaso, es ajuste normal.

Si falla el criterio 3 (incidencias graves): replantear el alcance. El flujo elegido era demasiado complejo o demasiado arriesgado para un primer sprint.

Stack típico para un primer flujo de back-office

Recomendación por defecto: empezar por la columna izquierda (sin código). Si en la semana 2 se ve que Make/n8n no llega, migrar a código en semana 3. Cambiar al revés (de código a no-código) es más caro.

Errores comunes en un primer sprint de 30 días

Error 1: Elegir el flujo “porque sí” sin filtrar por los 4 criterios. Resultado: el sistema funciona pero no libera tiempo significativo, o falla porque el patrón no era estable.

Error 2: Cambiar el alcance a mitad de sprint. Resultado: el sistema se reescribe sin nunca llegar a producción. Detalle en los 6 errores operativos al implementar IA (error 4: specs abiertas).

Error 3: Saltar la semana 1 (“ya lo tenemos claro, vamos a construir”). Resultado: en semana 3 aparecen casos extremos que nadie había considerado y el sistema se atasca.

Error 4: No tener responsable interno con dedicación real. Si nadie del equipo dedica 3-5h/semana a validar outputs, el sistema se entrega y se queda parado. La IA no implementa IA sola en una empresa que no la quiere.

Error 5: Querer automatizar el 100% desde el día 1. Las primeras 4-8 semanas, revisión humana obligatoria. Quitar la revisión antes de tiempo es la receta para que un error visible llegue al cliente y queme el proyecto entero.

Qué hacer después del primer flujo automatizado (día 30+)

Semanas 5-8: estabilización. No tocar el sistema durante 4-8 semanas. Dejar que el equipo se acostumbre, recoger ajustes finos, medir el ROI real (horas liberadas vs coste mensual).

Semana 9: documentar el aprendizaje. Una página A4 con: qué funcionó, qué no, qué sorprendió, qué cambiar para el siguiente sprint. Este documento es la materia prima del segundo flujo.

Semanas 10+: segundo flujo. Aplicando el aprendizaje del primero, repetir el sprint de 30 días con un nuevo candidato. La curva de aprendizaje hace que el segundo flujo suela ser 30-50% más rápido y barato que el primero.

Error a evitar: lanzar el segundo o tercer flujo en paralelo durante el sprint del primero. Multiplica la complejidad y diluye la validación.

Preguntas frecuentes

¿Qué flujo de back-office tiene más sentido automatizar primero con IA?

El que cumpla cuatro criterios acumulativos: alto volumen (decenas o cientos de ejecuciones al mes), alto coste-hora de la persona que lo hace, patrón repetitivo (mismos inputs, mismos outputs en estructura) y bajo riesgo si la salida tiene errores en las primeras semanas (mientras se valida con revisión humana). Candidatos típicos: clasificación de correo entrante, generación de propuestas, preparación de informes mensuales, onboarding administrativo de cliente.

¿Cuánto cuesta automatizar un primer flujo de back-office en 30 días?

Entre 4.000 y 8.000 € para una empresa de servicios de 5-20 personas. Incluye análisis del flujo (semana 1), construcción del sistema (semanas 2-3) y rodaje con revisión humana (semana 4). Coste recurrente posterior: 100-300 €/mes en API y herramientas. Si el flujo no está documentado al empezar, sumar 1-2 semanas adicionales en la fase de definición.

¿Qué stack uso para un primer flujo con IA?

Para flujos simples a medios sin programador interno: Claude Sonnet 4 (modelo) + Make o n8n (orquestación) + Notion o Google Sheets (almacenamiento). Para flujos con lógica compleja o muchas integraciones: Claude Sonnet 4 + código a medida con SDK de Anthropic + Notion/CRM como fuente de verdad. Evitar agentes complejos en el primer flujo.

¿Qué pasa si el flujo cambia mientras lo estoy automatizando?

El flujo NO debe cambiar durante las 4 semanas del sprint. Es regla operativa. Si cambia, parar y replanificar. Construir sobre un proceso en construcción multiplica el coste por 2 o 3. Antes de empezar el sprint, congelar el flujo: cómo es hoy, no cómo nos gustaría que fuera mañana. Las mejoras del flujo se introducen DESPUÉS del primer sistema en producción.

¿Quién en la empresa lidera el proyecto durante esas 4 semanas?

Una persona de la operación que vive ese flujo a diario (no de IT, no de dirección general). Su dedicación realista es 3-5 horas/semana para validar outputs, ajustar el criterio del sistema y reportar incidencias. Sin esa figura, el sistema se entrega y nadie lo usa porque no se ha alineado con la realidad del día a día.

¿Cómo sé que el sistema está listo para producción real al final del día 30?

Tres criterios acumulativos: >90% de outputs aceptados sin modificación por la persona que valida, tiempo del flujo reducido al menos 50% respecto al manual, cero incidencias graves (datos mal procesados, decisiones erróneas que llegan al cliente) en las últimas 2 semanas. Si fallan 1 o 2 criterios, prorrogar 2 semanas; si falla el 3º, replantear el alcance.

¿Qué hago después del primer flujo automatizado?

Tres opciones por orden de prioridad: estabilizar lo construido durante 4-8 semanas más antes de tocar nada, dejando que el equipo se acostumbre y aparezcan los ajustes finos. Documentar el aprendizaje (qué funcionó, qué no, criterio del sistema) en una página. Solo entonces empezar el siguiente flujo, aplicando lo aprendido. El error común es lanzar 3 flujos en paralelo antes de validar el primero.

En resumen

• Sprint de 30 días, un único flujo, sistema mínimo en producción es la cadencia que funciona en empresa de servicios de 5-20 personas. No 6 meses, no 6 flujos.
• Semana 1: definir, documentar en una página, congelar alcance. Seleccionar candidato por 4 criterios acumulativos.
• Semana 2: construir el sistema mínimo (MBS) con stack Claude Sonnet 4 + Make/n8n + Notion/Sheets. Logging desde el día 1.
• Semana 3: rodaje en paralelo con el flujo manual, 20-40 casos comparados, 3-5 patrones de error ajustados, validación contra histórico.
• Semana 4: producción con revisión humana obligatoria. Métricas diarias: % outputs aceptados, tiempo de revisión, incidencias.
• Coste realista: 4.000-8.000 € + 100-300 €/mes recurrentes. Dedicación del cliente: 3-5h/semana de una persona de la operación.
• Veredicto operativo: el ROI del primer flujo no es solo horas liberadas, es el aprendizaje sobre cómo IA encaja en TU operación. Estabilizar 4-8 semanas antes de empezar el segundo flujo. El error que mata proyectos es lanzar 3 a la vez.

Fuentes y referencias

• IndesIA — Barómetro de adopción de la inteligencia artificial en las PYMES españolas (2024) — patrones de adopción de IA en empresas españolas.
• INE — Encuesta sobre el uso de TIC y comercio electrónico en empresas (Q1 2025) — uso de IA integrada en empresas españolas.
• OECD — AI adoption by SMEs (diciembre 2025) — barreras y patrones de adopción en PYMES.
• Anthropic — Model Context Protocol (MCP) — guías oficiales de integración — estándar para conectar agentes con sistemas externos.
• Make — Documentación oficial y patrones de uso — orquestador no-code para flujos con IA.
• n8n — Documentación oficial — alternativa autoalojada para orquestación de flujos.

Próximo paso

Si estás considerando un primer sprint de 30 días para automatizar el primer flujo de back-office, el siguiente paso útil es identificar el flujo candidato por los 4 criterios. En 30 minutos podemos mirarlo juntos: tu lista de flujos, su volumen, su patrón y su nivel de riesgo. Salimos con un candidato priorizado y horquilla de coste realista. Sin compromiso.

Agendar reunión →