Presupuesto de automatización n8n: qué debe incluir

Comprar una automatización es encargar un circuito operativo: un evento entra, se valida, produce una acción y deja un registro. El número de nodos del editor no alcanza para describir ese trabajo. Un flujo corto puede depender de un ERP difícil de integrar; uno largo puede usar conexiones ya disponibles.

Si estás evaluando a un consultor de n8n, pedí una propuesta que tu responsable de operaciones y tu equipo IT puedan revisar juntos. Esta ficha sirve como base para esa conversación; las cantidades, plazos y condiciones se acuerdan para tu caso.

Un alcance útil podría ser: cuando operaciones aprueba un alta en el CRM, validar los campos requeridos, buscar si el cliente ya existe en el ERP y crear un borrador si corresponde. El responsable revisa el resultado antes de activar el registro. Es un ejemplo para definir alcance, no un caso de cliente ni una promesa de integración con cualquier ERP.

Esa primera pieza deja fuera la migración histórica, la limpieza completa de la base y la automatización de todas las áreas. Esas tareas pueden ser necesarias, pero necesitan su propio alcance. Cuando una propuesta dice “integrar CRM y ERP”, preguntá qué objetos mueve, en qué dirección y con qué reglas.

Antes de elegir n8n, revisá si tus sistemas ya tienen un conector que resuelva exactamente ese circuito. Para investigar las opciones de acceso disponibles, podés partir de nuestra guía de integración con ERPs argentinos. La versión y los permisos de tu instalación deben verificarse aparte.

No hay un importe único que permita cotizar cualquier workflow. El esfuerzo cambia con el acceso a los sistemas, la calidad de los datos, las excepciones, las aprobaciones y el modo de operación. Una propuesta comparable explica qué está incluido y quién paga cada componente.

La página oficial de planes de n8n define una ejecución como una corrida completa del workflow y publica condiciones distintas por plan. Revisá el plan vigente al contratar: cantidad de nodos, registros procesados y ejecuciones no son la misma medida.

Self-hosted significa que alojás n8n en infraestructura elegida por tu empresa. La documentación oficial de alojamiento distingue Community de las ediciones con licencia. Alojamiento propio requiere asignar operación, actualizaciones y recuperación; no convierte todo el proyecto en un servicio sin costo.

Pedí una estimación de uso basada en tu operación: frecuencia del disparador, volumen de eventos y otros servicios involucrados. No proyectes ahorro ni retorno sólo porque la demo funciona. Para evaluar el resultado, registrá primero el trabajo manual y luego comparalo con el mismo proceso automatizado.

“El ERP tiene API” todavía no resuelve el presupuesto. Hay que comprobar que tu edición permita usarla, que exponga la operación necesaria y que exista un entorno donde probar. También importan los límites de uso, permisos, identificadores y reglas del proveedor.

Si no hay API, un export programado puede servir para ciertos procesos por lotes. No garantiza escritura en el sistema ni sincronización inmediata. La propuesta debe indicar qué alternativa se verificó y qué dependencia queda pendiente; cotizar una integración no comprobada como si ya estuviera resuelta oculta trabajo.

Como referencia de arquitectura, publicamos un build de alta de productos para ecommerce que describe un origen sin API y una etapa de revisión humana. Ese diseño ilustra una alternativa concreta; no demuestra que cualquier sistema admita el mismo camino.

Una prueba de aceptación es la evidencia acordada de que el proceso cumple el alcance. Para el ejemplo CRM–ERP, la siguiente matriz convierte “está integrado” en comportamientos que negocio e IT pueden verificar. Los resultados son requisitos propuestos, no resultados medidos de un proyecto.

Para evitar duplicados, el diseño debe identificar cada evento y comprobar qué ocurrió en el destino antes de repetir una escritura. Una respuesta tardía del ERP puede esconder una operación que sí se completó. Pedí que el proveedor explique cómo verifica ese caso.

n8n permite configurar workflows de error, como explica su documentación de manejo de errores. Eso ofrece un mecanismo para avisar; las alertas, los destinatarios y la recuperación deben diseñarse y probarse para tu flujo.

La aceptación debería incluir una prueba con el responsable de negocio, un registro de incidencias y la aprobación del pase a producción. Acordá qué se hace si una dependencia del ERP impide completar la prueba.

Antes de firmar, definí quién administra la instancia, quién recibe alertas y quién puede cambiar reglas. Pedí que queden disponibles para tu equipo los workflows, la documentación y los accesos acordados, con las cuentas y licencias identificadas.

El soporte debe distinguir un defecto del alcance original de un cambio pedido después: agregar otro ERP, otro objeto o una regla de negocio nueva puede requerir trabajo adicional. También debe explicar qué pasa si cambia una API externa.

Si contratás mantenimiento, acordá cobertura, forma de reportar incidentes y tiempo de respuesta. Un tiempo de respuesta no equivale a un tiempo garantizado de resolución. Si tu equipo IT operará el sistema, incluí el traspaso en el alcance y verificá que pueda recuperar una ejecución fallida.

Compartí la misma ficha con los proveedores que estés evaluando. Usá ejemplos anonimizados y documentación de acceso; las credenciales se coordinan después mediante el canal que acuerde tu equipo IT.

Si faltan datos, marcá “pendiente” y pedí que el proveedor indique qué necesita relevar antes de cerrar precio y plazo. No hace falta resolver toda la arquitectura para iniciar la conversación, pero sí identificar qué proceso querés comprar.