Imagina que tienes dos automatizaciones: una manda un recordatorio interno los jueves; la otra actualiza las existencias de la tienda desde el ERP. Las dos llevan meses funcionando. Si el recordatorio se retrasa, alguien lo puede enviar a mano. Si el stock se queda congelado un sábado, puedes seguir vendiendo artículos que ya no tienes. No pondría el mismo plan de mantenimiento a las dos, aunque estén hechas con la misma herramienta.
Cuando me preguntan cuánto cuesta mantener una automatización, empezaría por cuánto tiempo puede pasar sin funcionar y qué ocurre mientras tanto. El número de pasos importa, pero no tanto como saber si alguien puede detectar el problema, contenerlo y recuperar el trabajo. Una ejecución en verde tampoco demuestra que el resultado siga siendo correcto.
Lo que miraría en una semana sin incidencias
En la integración de stock, compararía cuándo se actualizó el ERP con cuándo se reflejó ese cambio en la tienda. Miraría cuántos artículos quedan pendientes, si aumentan los reintentos y si el proceso tarda más de lo habitual. Una alerta por fallo sirve, pero también hace falta notar que hoy no se procesó nada cuando debería haber cambios. Para el recordatorio, puede bastar un aviso y una revisión ocasional de que sigue llegando al equipo adecuado.
Además del historial, mantendría una lista de conexiones, responsables y cambios que pueden afectarlas. Una cuenta que se desactiva, un permiso retirado o un cambio de API puede romper el flujo sin tocar una línea de su lógica. Si el ERP va a cambiar un campo o el proveedor modifica cómo se accede, haría una revisión antes o inmediatamente después según el riesgo. No esperaría a la siguiente revisión periódica para descubrir que la tienda lleva días sin recibir el stock.
También vigilaría el consumo si la plataforma cobra o limita por operaciones. Un lote que antes se procesaba una vez puede multiplicar las llamadas si se reintenta sin control. Las condiciones documentadas de Power Automate ilustran por qué conviene comprobar los límites del plan y del conector, no solo el número de ejecuciones. Al estimar el soporte, separaría ese consumo de las horas de supervisión, corrección y cambios.
El equipo de negocio y el soporte técnico resuelven cosas distintas
Si la tienda muestra menos unidades que el ERP, operaciones puede decir si eso es correcto: quizá hay unidades reservadas que no deben venderse. El equipo técnico puede averiguar si la integración recibió la reserva, transformó mal el dato o dejó el cambio pendiente. Yo nombraría a un responsable para cada decisión y a una persona de respaldo. No dejaría el aviso únicamente a quien construyó la automatización, ni pediría a soporte que decida por su cuenta qué stock es comercializable.
Dejaría también una ficha operativa: qué dispara el flujo, qué datos mueve, qué cuentas necesita, cómo se comprueba el resultado y quién puede pausarlo. Si una credencial caduca, el procedimiento no acaba al reconectarla. Hay que revisar qué cambios no llegaron, cuáles se aplicaron y desde dónde retomar sin repetir efectos. La guía de Microsoft sobre manejo de errores distingue rutas de fallo, espera y éxito. El detalle que me importa es que el aviso diga qué pasó y qué comprobar antes de actuar.
Si alojas tú la plataforma, sumaría actualizaciones, copias, espacio, control de accesos y seguridad de las integraciones. Herramientas como n8n documentan auditorías de seguridad de la instancia, pero eso no sustituye comprobar que puedes restaurarla. Si el flujo trata datos sensibles, revisaría también qué se guarda en registros y alertas, quién los consulta y durante cuánto tiempo.
Qué soporte elegiría según lo que cuesta parar
Para el recordatorio quizá acordaría soporte puntual, con un aviso y una forma manual de salir del paso. Para un proceso estable que necesita ajustes y revisiones periódicas, una bolsa de horas puede encajar si queda claro qué atiende y qué no. Si las existencias no pueden estar desactualizadas más allá de un margen corto, plantearía soporte continuado: quién recibe la incidencia, cuándo puede responder, cómo se escala y qué vía alternativa usa el negocio. Una promesa de respuesta no es una promesa de que el sistema se recupere en ese plazo.
No fijaría una frecuencia universal. Miraría volumen, picos, cambios de sistemas, criticidad, datos tratados y capacidad interna. A un flujo sencillo puede bastarle una revisión de salud y avisos claros. A uno crítico le pediría controles más próximos al uso, pruebas de recuperación y revisión específica antes de cambiar permisos, reglas o dependencias. En cómo asignar un dueño a una automatización tienes un ejemplo para repartir decisiones.
Para comparar ofertas de soporte, haría una estimación con tres partidas: revisión prevista, incidencias y cambios. No daría el mismo peso a una conexión estable que a un ERP que se actualiza cada temporada. Si hay un pico de ventas previsto, pediría saber quién revisa la capacidad antes y quién atiende un aviso durante ese periodo. No es lo mismo contratar tiempo para mejoras que cubrir la interrupción de un proceso crítico.
Lo ensayaría cuando aún no hay una urgencia
Probaría con un cambio controlado: simular que la tienda no confirma un artículo, comprobar que el responsable recibe el aviso y recuperar solo ese cambio. Si no sabemos si el sistema lo aplicó, un reintento no arregla la incertidumbre. Cambiaría la lógica primero en un entorno de pruebas o con datos controlados y dejaría una forma de volver atrás cuando sea posible. Si quieres profundizar en ese momento, aquí está qué hacer cuando falla una automatización.
Para saber qué mantenimiento necesita la tuya, preguntaría hoy quién se enteraría si se para y qué haría antes de relanzarla. Si tienes una respuesta clara, puedes ajustar el soporte al riesgo en vez de pagar por una cobertura genérica. Si nadie puede explicar qué pasaría con el stock de ese sábado, empezaría por esa prueba, no por añadir otro recordatorio.
Preguntas frecuentes
¿Necesita mantenimiento aunque funcione?
Sí. Pueden cambiar permisos, datos, reglas o plataformas sin que el flujo se modifique. Revisa que siga entregando el resultado previsto y que detecte errores y retrasos.
¿Quién debería encargarse?
Un propietario funcional valida qué resultado es correcto y cómo actuar ante excepciones. Un responsable técnico mantiene conexiones, lógica e infraestructura según el acuerdo. Conviene prever un suplente.
¿Qué pasa si caduca una credencial o cambia un permiso?
El flujo puede pararse total o parcialmente. Tras recuperar el acceso autorizado, revisa qué trabajo quedó pendiente o ya tuvo efecto antes de reanudar.
¿Los reintentos automáticos evitan todos los fallos?
No. Ayudan ante errores transitorios si es seguro repetir. No corrigen datos, permisos o lógica incorrecta, y pueden duplicar efectos si no hay controles.
¿Cuándo necesita soporte continuado?
Cuando un fallo tiene impacto relevante, hay poco margen para recuperarlo o las dependencias y cambios requieren atención organizada. Para bajo impacto puede bastar soporte puntual.
¿Puedo estimar el coste antes del lanzamiento?
Sí, como rango de esfuerzo basado en el volumen, dependencias, riesgo, infraestructura y nivel de soporte. Separa licencias y consumo del tiempo de revisar, corregir y adaptar.
¿Una de tus automatizaciones no puede esperar al lunes si falla?
En Soulvi podemos revisar contigo el flujo, sus dependencias y el margen real de recuperación para decidir qué vigilar y qué tipo de soporte necesitas.
