Blog · Proceso
La mayoría de los proyectos de automatización o se arrastran 90 días o se apuran a un Frankenstein de 5 días. Acá tenés cómo se ve realmente una forma deliberada de 30 días — los entregables, los milestones, y los momentos donde los proyectos se rompen si te salteás un paso.
Un proyecto de automatización pyme bien scopeado debería caber en 30 días calendario para un solo proceso ($3K–$7K), 35–45 días para 2–3 procesos conectados ($7K–$16K), y 50–80 días para un sistema operativo ($14K–$30K). La forma es siempre la misma: ~25% discovery, ~50% build, ~15% testing + UAT, ~10% cutover + 30 días de soporte. Las agencias que prometen <2 semanas para algo más allá de un proceso lineal único están salteándose discovery, tests, o ambos — y pagás la diferencia en la semana 4 cuando salen los casos borde. Abajo está el desglose semana por semana para el proyecto canónico de un solo proceso, con notas de cómo se estira para alcances más grandes.
Treinta días es la zona Goldilocks para proyectos de automatización pyme. Los proyectos más cortos se saltean pasos que importan. Los más largos acumulan scope creep y el problema original cambia antes de entregar.
La cuenta: un proyecto de un solo proceso usualmente involucra ~80 horas de trabajo enfocado repartidas en discovery, diseño, build, testing y cutover. Comprimir eso en 5 días significa días de 16 horas O saltearse los entregables que no tienen output visible (discovery, tests, documentación). Estirarlo a 90 días significa que el proceso que estabas automatizando ya no existe en la misma forma cuando terminás.
Treinta días también coincide con cómo la gente presta atención. Cuatro semanas es lo suficientemente corto para que el mismo champion del cliente esté enganchado de kickoff a launch. Más allá de eso, empezás a perder stakeholders a otras prioridades y el proyecto deriva. Vimos proyectos de 90 días morir en la semana 7 no porque el build fallara, sino porque nadie del lado cliente se acordaba qué querían para ese entonces.
La primera semana es donde ocurren la mayoría de los "fracasos de automatización" — meses antes de que alguien se dé cuenta, porque nadie reconoce el modo de falla. La agencia se salteó el discovery, empezó a construir desde un brief de un párrafo, y ahora están al 80% de un sistema que maneja el 60% del proceso real.
Unas 6 horas en total, mayormente en 2-3 calls. Hacemos la mayoría del trabajo async entre calls para que el equipo del cliente no viva en nuestras reuniones. Las 6 horas son:
⚠ Anti-patrón: si una agencia dice "no necesitamos discovery, solo dennos los requerimientos", están asumiendo que el proceso es mucho más simple que la realidad o están optimizando para horas facturables después (porque cada caso borde no detectado se convierte en una change order). El discovery es 20-25% del costo del proyecto y es la parte que más compundea.
Con la semana 1 firmada, la semana 2 es cuando arranca el build. El objetivo no es un proceso terminado — es un esqueleto que corre, por el que el happy path pasa de punta a punta.
Unas 3 horas. Un check-in de 30 min a mitad de semana + una demo de 60 min al final de semana del happy path + ~90 min de review async y feedback.
Qué buscamos en la demo de la semana 2: ¿el happy path coincide con el mapa del proceso de la semana 1? Si sí, la semana 3 es "llenar los bordes". Si no, cazamos un malentendido temprano — mucho más barato arreglarlo en la semana 2 que en la semana 4.
La semana 3 es donde se define la calidad real del build. Cualquiera puede entregar un happy path. Las agencias que recordás después de que el proyecto termina son las que manejaron la semana 3 con el mismo rigor que la semana 2.
Unas 3 horas, similar a la semana 2. Podemos necesitar una call ad-hoc de 30 min para confirmar una decisión específica de caso borde ("si el lead no tiene teléfono, ¿lo ruteamos distinto o salteamos el paso de la llamada?"). La demo de fin de semana muestra el proceso completo manejando escenarios realistas.
La semana 4 es cuando el proceso sale a producción, pero "salir a producción" no es un solo momento — es una secuencia deliberada que caza el último 5% de casos borde que las semanas anteriores no pudieron surfacear.
Unas 6 horas más tiempo de training del equipo. UAT específicamente requiere atención real — acá es donde cazás cosas que la semana 3 no podía anticipar ("no nos dimos cuenta que Maria hace esta parte los viernes a la tarde").
La forma es constante; la escala cambia. Para proyectos más allá de un solo proceso, estirás cada fase proporcionalmente — no agregás una fase distinta.
| Tamaño del proyecto | Discovery | Build | UAT + Cutover | Total calendario |
|---|---|---|---|---|
| Un solo proceso ($3K–$7K) | Semana 1 | Semanas 2–3 | Semana 4 | ~30 días |
| 2–3 procesos conectados ($7K–$16K) | ~10 días | ~20 días | ~10 días | ~35–45 días |
| Sistema operativo ($14K–$30K) | ~14 días | ~30 días | ~14 días | ~50–60 días |
| Plataforma a medida ($25K–$60K) | ~21 días | ~50 días | ~21 días | ~80–100 días |
Qué cambia proporcionalmente con la escala: discovery se alarga porque más procesos significa más casos borde. Build se alarga porque hay más superficie. UAT se alarga porque hay más interfaces para validar. Qué no cambia: la ratio. Siempre vas a gastar ~20-25% del tiempo del proyecto en discovery y ~15% en UAT/cutover — quien recorta esos números está escondiendo el costo en un mes posterior.
Ninguna de estas es sobre la agencia siendo maliciosa. Son sobre incentivos desalineados — las agencias que compiten por precio llegan ahí cortando el trabajo invisible. El trabajo invisible es lo que hace que el sistema sobreviva pasado el mes 3.
✏️ Nota: composiciones ilustrativas, no clientes específicos.
Tres cosas, ninguna técnica:
Para el resto de la cuenta operativa (qué cuesta cada tier, qué debería estar en la cotización, cómo escribir el brief que obtiene un número preciso), ver cuánto cuesta realmente un proyecto de automatización en 2026.
Para un proceso lineal único con 1-2 integraciones, sin casos borde y data limpia — sí, 10-15 días es realista. Para cualquier cosa con branching multi-paso, excepciones, aprobaciones, o data sucia, 30 días es el piso para un proyecto que sobreviva pasado el mes 3. Los timelines comprimidos funcionan cuando el alcance genuinamente calza; no funcionan como claim de marketing contra un proyecto que necesita discovery completo.
Cualquier bug encontrado en operación normal durante los primeros 30 días calendario después del cutover se arregla sin costo extra. Los pedidos de features son scope aparte. Típicamente un proyecto de un solo proceso surfacea 3-6 bugs en el período de soporte; un sistema operativo surfacea 10-15. La mayoría son menores — casos borde que el discovery no reveló — y se parchean en horas. El período de soporte también es cuando hacemos pasadas de tuning (ej. ajustar una regla según la frecuencia real que no se podía predecir).
Unas 18-22 horas en total a lo largo de las cuatro semanas para un solo proceso: ~6h en la semana 1, ~3h en las semanas 2-3, ~6h en la semana 4 más el training del equipo. El predictor más grande de slip de timeline es el tiempo de respuesta — preguntas que esperan 3 días por respuestas convierten un proyecto de 30 días en uno de 45. Designá un champion que pueda responder en 24 horas y estás listo.
Pausamos y tenemos una conversación honesta. Usualmente surgen tres opciones: (a) achicar el alcance para mantener el timeline original, (b) extender timeline y presupuesto proporcionalmente, (c) cancelar con un reembolso parcial basado en el trabajo completado y las lecciones aprendidas (igual es útil — los artefactos de discovery son tuyos). La peor opción es seguir empujando un alcance equivocado esperando que funcione. Nunca vimos eso recuperarse; vimos producir sistemas que se abandonan en 90 días.
Porque el proceso funciona el día 30. La pregunta es si sigue funcionando el día 240 después de haber cambiado algo — sumado una nueva fuente de leads, modificado la estructura de campos del CRM, actualizado las credenciales de integración. Sin tests, cada cambio es un momento de 'cruzá los dedos'. Con tests, el proceso te avisa inmediatamente cuando algo se rompe. Los tests son 5-10% del costo del build y previenen las fallas silenciosas que destruyen la confianza en sistemas de automatización.
A veces sí, a veces no. Si tu equipo ya produjo mapas de proceso y catálogos de casos borde antes, el discovery interno funciona bien y revisamos tus artefactos en una sesión de 4 horas en vez de una semana completa. Si este es tu primer proyecto sistemático de automatización, hacer el discovery juntos usualmente vale el costo — surfacea bordes que un equipo interno que vivió con el proceso para siempre ya no nota. De cualquier forma, no nos salteamos los artefactos; solo discutimos quién los produce.
Blog
Mandanos el proceso — qué lo dispara, qué hace, quién es dueño — y volvemos con un plan de 30 días que calza, con discovery, tests, documentación y soporte post-launch todos itemizados. Sin sorpresas en la semana 4.
Contanos tu problema →
