Monitorización Automática de Licitaciones Públicas

¿Qué hace este flujo y qué problema resuelve?

Este flujo de n8n automatiza la monitorización de licitaciones públicas y transforma una tarea repetitiva y de alto riesgo en un proceso sistemático, trazable y accionable. Su propósito es detectar convocatorias relevantes para la organización, normalizar la información publicada en múltiples portales (BOE, plataformas autonómicas y plataformas sectoriales), aplicar filtros de prioridad y notificar a los equipos responsables con la documentación y los plazos necesarios para preparar una oferta competitiva.

El problema que resuelve es doble. Primero, reduce la probabilidad de pérdida de oportunidades por supervisión manual insuficiente: los equipos suelen depender de búsquedas puntuales o alertas generales que generan ruido. Segundo, mitiga el riesgo operativo y de cumplimiento asociado a plazos y requisitos documentales al centralizar la identificación, el registro y la notificación de cada expediente en un flujo automatizado con historial.

1. Captura de fuentes: el flujo consulta periódicamente APIs y páginas públicas de licitaciones.
2. Extracción y normalización: estructura datos clave (objeto, presupuesto, plazos, órgano contratante, clasificación CPV/CNAE).
3. Filtrado y priorización: aplica reglas comerciales para seleccionar oportunidades de interés.
4. Desduplicado y enriquecimiento: elimina duplicados y añade metadatos internos (cliente interesado, responsable, urgencia).
5. Notificación y registro: envía alertas a los responsables (correo, canal de mensajería, sistema de gestión) y guarda el expediente en el histórico.

Beneficios operativos: mayor cobertura de mercado, reducción del tiempo de respuesta, asignación temprana de recursos y generación de un registro auditable de todas las convocatorias analizadas y las decisiones tomadas. Desde la dirección, esto se traduce en aumento de la efectividad comercial y mejor control del pipeline de licitaciones.

Ejemplo operativo con una empresa ficticia:

• InnovaContratos S.L.: compañía de ingeniería con foco en infraestructuras públicas. Define criterios: Comunidad Autónoma = Andalucía; CPV = obras de carretera y suministro de materiales; presupuesto mínimo = 500.000 EUR; plazo de presentación > 15 días.
• Resultado del flujo para InnovaContratos S.L.: el sistema detecta 3 convocatorias relevantes en 72 horas, normaliza la información y notifica al equipo comercial con ficha resumida y enlaces a los pliegos.

Impacto esperado: disminución de oportunidades perdidas, incremento en el ratio de respuesta a licitaciones y mejor priorización de recursos. En una visión directiva, el flujo aporta visibilidad temprana del mercado público y facilita decisiones de asignación presupuestaria y de personal basadas en datos.

Cuándo usar este flujo

Definición de criterios de búsqueda

Definición de criterios de búsqueda

La definición de criterios de búsqueda es la etapa crítica que determina la precisión y relevancia de las alertas de licitaciones públicas. En este paso diseñamos filtros semánticos, paramétricos y de canal para que el flujo automatizado de n8n detecte convocatorias alineadas con la estrategia comercial. El objetivo es minimizar ruido y maximizar oportunidades accionables.

Principios ejecutivos: priorizar campos obligatorios (CPV/NAICS, tipo de procedimiento, importe mínimo/máximo), establecer tolerancias por geografía y fechas, y combinar filtros booleanos y semánticos para capturar sinónimos y variaciones terminológicas.

1. Identificar atributos clave
   1. Sector o CPV/NAICS: usar códigos primarios y secundarios.
   2. Alcance geográfico: país, región, municipio.
   3. Tipo de contrato: suministro, obra, servicios.
   4. Rango presupuestario y fechas de publicación/cierre.
2. Configuración específica de nodos n8n

   Ejemplo de cadena mínima de nodos y parámetros recomendados:

   1. Node: Cron — Trigger diario a las 07:00 UTC.
   2. Node: HTTP Request / RSS Feed — Endpoint de licitaciones. Parámetros: method=GET, responseFormat=JSON, query params: 'cpv'= '45000000, 72000000', 'region'='Andina'.
   3. Node: Set — Normalizar campos: amount_numeric = parseFloat(amount.replace(/[^0-9.]/g,'')), publish_date = new Date(publish_date).
   4. Node: Function — Aplicar filtros semánticos: keywords = ['mantenimiento','infraestructura','servicios TIC']; match = keywords.some(k => title.toLowerCase().includes(k)).
   5. Node: IF — Condiciones lógicas: (match == true) AND (amount_numeric >= 50000) AND (region == 'Región Centro').
   6. Node: Google Sheets / Database — Registrar ID y hash para evitar duplicados; campos: id, title, cpv, amount, publish_date, source_url.
   7. Node: Send Email / Slack — Notificación con plantilla resumida y enlace a ficha completa.
3. Substep: afinación y pruebas
   1. Ejecutar el flujo en modo manual con 50-100 registros históricos.
   2. Medir tasa de verdaderos positivos y falsos positivos; ajustar keywords y umbrales de importe.
   3. Agregar más fuentes o normalizadores si faltan resultados relevantes.

Ejemplo con empresa ficticia: Constructora NovaSur. Requisitos de NovaSur: obras de infraestructura vial, CPV 45100000, importe entre 200.000 y 2.000.000 USD, región: Provincia Central. En n8n se configura el nodo Function para mapear sinónimos: ['reparación vial','rehabilitación de carreteras'] y el IF para cerrar en el rango de importes. Las alertas se envían al equipo comercial y se guardan en Google Sheets para control de oportunidades.

Problemas frecuentes

Falsos positivos recurrentes

Síntoma: muchas alertas no relevantes. Causa: palabras clave demasiado genéricas o ausencia de contexto semántico. Solución: añadir filtros CPV, usar expresiones regulares más específicas y aplicar listado de exclusión (blacklist) en el nodo Function.

Faltan resultados relevantes

Síntoma: oportunidades conocidas no aparecen. Causa: fuente no incluida, normalización incorrecta de campos o umbrales de importe demasiado altos. Solución: incorporar más endpoints, revisar transformaciones en Set/Function y bajar temporalmente umbrales para pruebas.

Duplicados en alertas

Síntoma: la misma licitación notificada varias veces. Causa: falta de deduplicación por identificador o cambios menores en la fuente. Solución: almacenar hash de contenido y comprobar prior a notificar; usar nodos de base de datos o Google Sheets para control.

Errores de parsing

Síntoma: fallos al convertir importes o fechas. Causa: formatos regionales (coma vs punto) o campos vacíos. Solución: implementar funciones de normalización robustas en el nodo Function y capturar excepciones para registro de errores.

Latencia o fallos por límite de API

Síntoma: requests bloqueados o flujo interrumpido. Causa: límites de llamadas a la API de origen. Solución: implementar backoff, cache local y escalonar cron triggers; considerar usar proveedor alternativo para replicación.

Adaptaciones

• Flujo para consultoras TIC: priorizar CPV de software y servicios, añadir análisis de requisitos técnicos en nodo Function y enviar a canal técnico interno en Slack.
• Flujo para suministros y compras: incorporar validación de proveedores aprobados, umbral de importe bajo y conexión a ERP para comprobar stock y condiciones comerciales.
• Versión para internacionalización: parametrizar geografía y moneda; añadir conversión de divisas en nodo Function y normalizar CPV/NAICS entre jurisdicciones.
• Flujo de adjudicaciones y seguimiento post-licitación: ampliar criterios para capturar actas de adjudicación, alertas de recursos y plazos contractuales; integrar con CRM para seguimiento comercial.

Consulta diaria a la API PLACE

Esta sección describe la implementación diaria de la consulta a la API PLACE usando n8n. El objetivo es ejecutar una búsqueda programada de nuevas licitaciones, filtrar las relevantes y registrar los resultados en la base de datos o enviar alertas a los responsables. A continuación se presenta la configuración detallada de los nodos n8n, el paso a paso operativo, un ejemplo práctico con una empresa ficticia y apartados de salida esperada, problemas frecuentes y adaptaciones recomendadas.

Configuración específica de nodos n8n

• Schedule Trigger
  • Mode: 'Every Day'
  • Time: '07:00'
  • Timezone: 'Europe/Madrid'
• HTTP Request
  • HTTP Method: 'GET'
  • URL: 'https://api.place.gob.es/v1/licitaciones'
  • Authentication: 'Header' – Header Name: 'X-API-KEY', Value: '{{ $credentials.PLACE_api_key }}'
  • Query Parameters: 'date_from' = '{{ $json["last_run"] }}' or calculated as 'today - 1 day', 'limit' = '100', 'offset' = '0'
  • Response Format: 'JSON'
• Function / Function Item
  • Usado para: manejar paginación (leer campo 'next' o incrementar 'offset'), normalizar fechas y filtrar por sectores/geografía.
• SplitInBatches para procesar cada licitación individualmente (batch size = 1-10).
• IF para filtrar por criterios (valor estimado, sector, provincia).
• Postgres / MySQL / Google Sheets para registro y deduplicado: comprobar si 'tender_id' ya existe antes de insertar.
• Webhook / Email / Slack para notificaciones a responsables si se cumple criterio de aviso.

Paso a paso operativo (substeps)

1. Crear el nodo Schedule Trigger con la programación diaria.
2. Conectar a un nodo Set para enviar la variable 'date_from' (por ejemplo 'yesterday' en formato ISO) y 'limit' inicial.
3. Configurar el nodo HTTP Request con la URL de la API PLACE y el header 'X-API-KEY'.
4. Agregar un nodo Function para comprobar la respuesta y gestionar paginación: si response.next existe, actualizar 'offset' y re-ejecutar hasta agotar resultados.
5. Pasar la lista al nodo SplitInBatches para procesar cada licitación: extraer campos clave (id, título, fecha_publicacion, fecha_limite, valor_estimado, link).
6. En nodo IF, aplicar reglas (ej.: valor_estimado > 100000 y sector == 'Obras Públicas' y provincia == 'Sevilla').
7. Registrar en la base de datos: usar consulta upsert para evitar duplicados por 'id'.
8. Enviar notificación por email/Slack si el registro cumple criterios de alerta y actualizar el log con la marca de procesamiento.
9. Actualizar variable 'last_run' al final del flujo con la fecha y hora de ejecución.

Ejemplo práctico (empresa ficticia)

La empresa ficticia 'Servicios de Ingeniería Altair S.L.' monitoriza licitaciones de obras públicas en Andalucía. Requisitos: valor estimado > 150.000 EUR y plazo de presentación > 10 días. Altair configura el flujo descrito, añade un IF con esos criterios y un nodo Slack para alertar al equipo de licitaciones. Tras la primera ejecución diaria, reciben un resumen y el flujo realiza upsert en su base de datos interna para seguimiento comercial.

Output esperado

Ejemplo de salida tras una ejecución diaria (datos ficticios):

Problemas frecuentes

Error: Sin resultados inesperados

Síntoma: El flujo devuelve lista vacía pese a que hay licitaciones esperadas. Causa: Parámetros 'date_from' o filtros demasiado restrictivos; zona horaria incorrecta. Solución: Revisar el valor enviado en 'date_from', probar con un rango ampliado, confirmar timezone del Schedule Trigger.

Error: Paginación incompleta

Síntoma: Solo se reciben los primeros 100 registros. Causa: No se implementó la lógica de paginación o se interpreta mal el campo 'next'. Solución: Implementar nodo Function para leer 'response.next' o incrementar 'offset' en bucle hasta que no haya más páginas.

Error: 401/403 Autenticación

Síntoma: Respuesta de la API con 401 o 403. Causa: API key incorrecta o caducada, header mal nombrado. Solución: Verificar credenciales en n8n Credentials, usar el nombre de header correcto ('X-API-KEY' o 'Authorization: Bearer ...').

Error: Duplicados en la base de datos

Síntoma: Mismas licitaciones registradas varias veces. Causa: No se usa clave única o upsert en insert. Solución: Implementar consulta upsert por 'id' externo o marcar procesadas las integraciones con índice único en la tabla.

Error: Lento o timeouts

Síntoma: Tiempo de respuesta largo o fallos por timeout. Causa: Solicitudes con limit demasiado alto o procesamiento síncrono de archivos adjuntos. Solución: Reducir 'limit' y usar SplitInBatches; descargar adjuntos en un flujo asíncrono posterior.

Adaptaciones del flujo

• Filtrado por ámbito geográfico: adaptar el nodo IF para incluir provincias o código NUTS y enviar alertas solo a delegaciones locales.
• Integración con CRM: en lugar de solo registrar en BD, ejecutar un nodo HTTP Request a la API del CRM para crear oportunidades con metadatos de la licitación.
• Sincronización incremental por id: usar un endpoint de cambios (if disponible) o mantener un cursor 'last_id' cuando la API no soporta fecha, para evitar re-procesos.
• Multicanal de notificación: añadir nodos para enviar resumen diario por email, crear tarea en gestor interno y notificar en Slack/Teams según prioridad.

Conclusión: Con una programación diaria, paginación controlada, reglas de filtrado y upsert en la base de datos, n8n ofrece un flujo robusto para monitorizar automáticamente las licitaciones del PLACE y notificar a los equipos responsables. Las adaptaciones propuestas permiten escalar el uso a diferentes regiones, integraciones y políticas de notificación.

Análisis de relevancia con IA

Notificación al equipo comercial

Notificación al equipo comercial (Paso 4)

En esta etapa se transforma la detección de una nueva licitación en una notificación operativa para el equipo comercial. El objetivo es entregar la información esencial (título, órgano convocante, importe aproximado, fecha de cierre y link) en el canal apropiado, con prioridad y asignación automática cuando aplique. A continuación se detallan los nodos n8n, su configuración y un flujo probado que permite entregar notificaciones coherentes y accionables.

1. Nodo: SplitInBatches

   • Propósito: procesar lotes si llegan múltiples resultados en una sola ejecución.
   • Configuración clave: Batch Size = 1 (procesamiento por licitación).

2. Nodo: Set

   • Propósito: normalizar datos y construir el payload de notificación.
   • Campos que crear:
   • title = {{$json.title}}
   • authority = {{$json.authority}}
   • budget = {{$json.estimated_value}}
   • deadline = {{$json.closing_date}}
   • url = {{$json.url}}
   • priority = {{$json.estimated_value > 50000 ? 'Alta' : 'Media'}}
   • assigned = {{$json.category === 'Infraestructura' ? 'EquipoA' : 'EquipoB'}}

3. Nodo: Function (opcional: enriquecimiento)

   • Propósito: aplicar lógica para generar asunto y texto de notificación.
   • Ejemplo de salida:
   • subject = `Nueva licitación: ${item.title} (${item.priority})`
   • message = `Órgano: ${item.authority}\nImporte: ${item.budget}\nCierre: ${item.deadline}\n${item.url}`

4. Nodo: Conditional / IF

   • Propósito: enrutar según prioridad o categoría (p. ej. correo vs. Slack vs. Teams).
   • Condiciones típicas: priority == 'Alta' → canal urgente; assigned == 'EquipoA' → notificar líder específico.

5. Nodo: Slack (o Microsoft Teams / Email)

   • Slack - Campos recomendados:
   • Channel = #oportunidades-licitaciones
   • Text = Nueva licitación: {{$json.title}}\nÓrgano: {{$json.authority}}\nImporte: {{$json.budget}}\nCierre: {{$json.deadline}}\n{{$json.url}}
   • Blocks (opcional) = botones: "Ver" -> {{$json.url}}, "Asignar" -> enlace interno
   • Email - Campos recomendados:
   • To = comercial@solucionespublicas.example
   • Subject = {{$json.subject}}
   • Body (HTML) = incluir tabla con campos clave y enlaces.

6. Nodo: Google Sheets / Airtable (registro)

   • Propósito: crear o actualizar registro de oportunidad para trazabilidad.
   • Campos a mapear: id, title, authority, budget, deadline, url, priority, assigned, notified_at = {{$now}}

7. Nodo: Set de salida y retorno

   • Propósito: consolidar resultado para logs y webhooks de auditoría.

Ejemplo operativo (empresa ficticia): SolucionesPublicas S.A. recibe una licitación detectada por el scraper. El flujo divide el lote, normaliza campos en Set, genera asunto en Function, evalúa prioridad en IF y envía una notificación a Slack al canal #oportunidades-licitaciones y un correo a comercial@solucionespublicas.example si la prioridad es Alta. Simultáneamente registra la oportunidad en Google Sheets bajo la hoja "Oportunidades".

Comprobaciones de éxito: el equipo comercial debe recibir un mensaje en Slack con el asunto y el enlace, el correo (si aplica) debe llegar al buzón de comercial, y la hoja de registro debe contener la fila con notified_at y estado inicial "Pendiente contacto".

Problemas frecuentes:

Error 1 — Mensaje no llega a Slack

Síntoma: nodo Slack reporta error o la notificación no aparece en canal. Causa: token de API caducado o canal mal escrito. Solución: renovar token en las credenciales de Slack y verificar el nombre del canal; probar con un mensaje simple desde n8n.

Error 2 — Campos faltantes en la notificación

Síntoma: la notificación muestra campos vacíos. Causa: mapeo incorrecto en el nodo Set o nombres de campo del origen cambiaron. Solución: revisar el output del nodo anterior (debug), actualizar expresiones {{$json.}} y añadir validaciones en Function.

Error 3 — Duplicados en la hoja de registro

Síntoma: la misma licitación se registra varias veces. Causa: ausencia de verificación de duplicados (ID único). Solución: antes de crear, ejecutar un nodo Google Sheets Query o Search en Airtable para comprobar existencia por ID; actualizar si existe.

Error 4 — Retrasos o tiempo de espera

Síntoma: el flujo tarda o falla por timeout al llamar a servicios externos. Causa: endpoints lentos o límites de API. Solución: implementar reintentos con backoff, aumentar timeouts en HTTP Request y usar SplitInBatches para controlar carga.

Error 5 — Asignación incorrecta

Síntoma: asignado a equipo inapropiado. Causa: reglas de negocio en Function mal definidas o cambios categóricos. Solución: centralizar la lógica de asignación en un lookup table (Google Sheets/Airtable) y referenciarlo desde el flujo.

Adaptaciones del flujo para otros contextos:

• Venta B2B: reemplazar el canal Slack por notificaciones directas a CRM (Salesforce / HubSpot) y mapear lead score según importe y sector.
• Operaciones técnicas: notificar al equipo técnico por Microsoft Teams y crear tickets automatizados en Jira con prioridad derivada del importe o impacto.
• Alcance internacional: añadir nodo de traducción automática (Google Translate) para generar notificaciones en el idioma regional y adjuntar resumen en local language.
• Gestión de subcontratistas: enviar notificación segmentada por categoría a una lista de proveedores externos via correo y registrar aceptación en Airtable para seguimiento.

Output esperado del flujo

Salida esperada del flujo de monitorización automática de licitaciones públicas: descripción ejecutiva y ejemplos concretos para integración operativa. El flujo debe producir salidas estructuradas y accionables que permitan a equipos comerciales y de oferta priorizar oportunidades y activar procesos internos (alertas, creación de leads, descarga de pliegos).

Formato(s) de salida esperado(s):

• Registro por licitación en una hoja de cálculo (Google Sheets / Excel) o en una base de datos: una fila por licitación con campos normalizados.
• Payload JSON por notificación, enviado a webhook o a un canal de mensajería corporativa (Slack/Teams) para consumo por sistemas downstream.
• Correo electrónico ejecutivo diario/resumen con las licitaciones que pasan umbrales de prioridad.

Estructura de datos recomendada (explicación rápida):

1. ID_externo: identificador único de la publicación en el portal.
2. Título: texto corto de la licitación.
3. Órgano_convocante: entidad pública responsable.
4. Fecha_publicación y Fecha_límite: en formato ISO (YYYY-MM-DD).
5. Estado: nuevo / actualizado / cerrado.
6. Palabras_clave_encontradas: lista de términos que activaron la coincidencia.
7. Prioridad (0-100): score calculado por reglas (sector, importe, plazo).
8. Enlace_pliego: URL directa al anuncio.

Ejemplo concreto (datos ficticios). Este ejemplo se muestra como tabla tal como quedaría en Google Sheets o en la respuesta JSON enviada al CRM:

Ejemplo de fila integrada en CRM o en un ticket de oportunidad (lista de campos clave):

• Cuenta: NovaInfra Consultores S.L.
• Oportunidad origen: MonitorLicita-n8n
• Título oportunidad: Servicio de mantenimiento de infraestructuras viarias (LIT-2026-00123)
• Fecha límite: 2026-08-05
• Score_prioridad: 86
• Contacto asignado automáticamente: Equipo Obras

Indicaciones operativas breves: utilice la columna Prioridad para filtrar alertas automáticas (ej.: prioridad >= 80 = notificación inmediata a equipo comercial). Asegure un campo URL activo para permitir descarga directa del pliego desde los flujos de trabajo.

Ejemplo de uso por una empresa ficticia: ConsulteraTech S.A. configura el flujo para que todas las licitaciones con prioridad >=85 generen un ticket en su herramienta de gestión de propuestas y envíen un correo al responsable de ofertas con la tabla adjunta y el enlace al pliego.

Problemas frecuentes y cómo resolverlos

Adaptaciones del flujo para otros contextos