El problema.
Una empresa industrial B2B con doce comerciales recibía cada mes entre 80 y 120 peticiones de oferta (RFQs) por canales mezclados: email genérico de comercial@, formularios web del propio sitio, portales de cliente (e-procurement), y peticiones que entraban directamente al móvil de un comercial concreto y que muchas veces sólo él veía.
Cada oferta requería el mismo flujo manual: leer el pliego o lista de productos del cliente, identificar cada referencia en el catálogo interno, comprobar stock y plazos de entrega, calcular el precio con los descuentos específicos del cliente (volumen, histórico, contrato marco), buscar si ya se había hecho una oferta parecida para no contradecirse en condiciones, redactar la propuesta en el formato exacto que pide el cliente (Excel propio del cliente, plantilla Word, formulario del portal), adjuntar fichas técnicas y enviar. Tiempo medio: 3-4 horas por RFQ.
El equipo comercial dedicaba el 50 % de su jornada a hacer ofertas en lugar de a vender. Las RFQs urgentes se llevaban toda la atención y las que parecían "más sencillas" se posponían hasta que vencía el plazo. Sólo el 60 % de las peticiones se respondían a tiempo. Cuando llegaban las respuestas tarde, el cliente ya había decidido. Cuando llegaban a tiempo, había inconsistencias de criterio entre comerciales (descuentos distintos para clientes parecidos, condiciones que se contradecían con ofertas anteriores).
Qué construimos.
1. Captura unificada multicanal
Un workflow de n8n monitoriza los cuatro canales de entrada y normaliza cualquier RFQ a un formato interno común: cliente, productos solicitados, cantidades, plazo de entrega pedido, formato de respuesta requerido, fecha límite, contacto del cliente. Si la RFQ entra por WhatsApp del móvil de un comercial, se reenvía a una casilla común que el sistema escucha. Ninguna RFQ se queda sin registrar.
2. Análisis con LLM y matching de productos
Un modelo (Claude para razonamiento contextual, GPT-4o para extracción tabular) lee el pliego o la lista, identifica cada referencia y la cruza contra el catálogo interno: producto exacto, equivalente o sustituto. Si el cliente pide algo no catalogado, el sistema lo marca como excepción a revisar y propone alternativas razonadas con justificación técnica.
3. RAG sobre ofertas previas y conocimiento interno
El sistema vectoriza la RFQ y la busca contra una base de conocimiento que incluye: histórico de ofertas anteriores al mismo cliente y a clientes similares, políticas comerciales (descuentos por volumen, condiciones de pago, garantías estándar), contratos marco activos, promociones vigentes, y especificaciones técnicas y fichas de producto. Devuelve los pasajes relevantes al modelo generador para que la propuesta sea coherente con lo que la empresa ya ha ofrecido al mismo cliente y al sector.
4. Rellenado en el formato del cliente
La parte que más tiempo consumía a mano: cada cliente quiere la oferta en su propio formato. Excel con las celdas que tiene su sistema de compras, plantilla Word con sus campos, formulario de portal con su estructura de productos. El sistema reconoce el formato (que se modela una sola vez por cliente al darlo de alta) y rellena cada campo en su sitio: referencia, cantidad, precio neto, descuento aplicado, plazo, garantía, condiciones de pago. Genera el archivo final listo para enviar.
5. Borrador para validación humana
El comercial recibe en su CRM una notificación con el borrador completo, un resumen del razonamiento (qué descuentos se aplicaron y por qué, qué ofertas previas se usaron como referencia, qué excepciones requieren atención humana), y los campos marcados de baja confianza destacados en amarillo. Revisa, ajusta lo que crea oportuno, firma y envía. Tiempo medio: 30 minutos, con picos de 60 minutos en RFQs grandes y 10 minutos en repetitivas.
6. Loop de aprendizaje
Cada RFQ ganada/perdida alimenta la base. Si la propuesta se modifica antes de enviar, el sistema aprende del cambio. Si la oferta se gana, queda como ejemplo de oro para clientes parecidos. Si se pierde, se anota el motivo (precio, plazo, técnico, otro). Tras 3 meses, el porcentaje de campos que el comercial deja sin tocar sube del 70 % inicial al 88 %.
El comercial pasó de hacer ofertas a vender. Antes nos saltábamos RFQs; ahora respondemos a todas, y mejor. La tasa de conversión no la mejoró el sistema — la mejoró que ahora podemos centrarnos en las grandes.
Cómo lo implementamos.
Seguimos nuestras 5 fases estándar — ver proceso completo.
- Semana 1 · Descubrimiento + plan de ruta: sesión con director comercial, dos comerciales senior y la persona que mantiene el catálogo. Mapeamos los 4 canales de entrada, los 5 formatos más frecuentes de respuesta (cubren el 80 % de las RFQs), y catalogamos las políticas comerciales por cliente. Quick win: empezar por el formato más usado (Excel del cliente top-3) y ampliar después.
- Semanas 2-3 · Desarrollo: construcción en staging sobre VPS dedicado y Supabase EU-Frankfurt. Ingestamos 18 meses de ofertas históricas, las vectorizamos y montamos el RAG. Conectamos con el CRM (Pipedrive en este caso) y con el ERP para precios y stock. Modelamos los 5 formatos de respuesta más frecuentes con plantillas reutilizables.
- Semana 4 · Pruebas con datos reales: el sistema procesa 40 RFQs reales en sombra, sin enviar nada. Comparamos las propuestas generadas con las que el equipo comercial habría enviado. Afinamos casos borde: equivalencias de producto, descuentos de cliente con histórico complejo, formatos rotos.
- Semanas 5-8 · Estabilización (4 semanas supervisadas): el sistema entra en producción acompañando al equipo comercial. Reuniones semanales para ajustar el knowledge base, refinar los prompts, añadir excepciones aprendidas. Al final de las 4 semanas: producción 100 % autónoma con validación humana de 30 min.
- Producción: retainer mensual de evolución para añadir nuevos formatos de cliente, ampliar a nuevos sectores, y mantener el knowledge base con nuevas ofertas y políticas.
Stack utilizado.
n8n self-host Claude Sonnet GPT-4o pgvector Supabase Pipedrive docx-js · ExcelJS PostgreSQL Grafana
Para qué empresas funciona este patrón.
Cualquier empresa que reciba ofertas a petición (RFQs, RFPs, peticiones de cotización, presupuestos) en formatos heterogéneos y con un equipo comercial limitado. Aplica especialmente bien a:
- Distribución industrial con catálogos amplios y descuentos por volumen.
- Ingeniería y servicios técnicos con propuestas que mezclan productos y horas.
- Suministros B2B (industrial, sanitario, oficina) con clientes recurrentes y condiciones marco.
- Construcción y reformas con presupuestos por mediciones.
- Software / SaaS B2B con licencias por volumen y SLAs personalizados.
El umbral de rentabilidad típico es 40-50 RFQs/mes. Por debajo, el ROI tarda. Por encima, el sistema empieza a pagarse en el primer trimestre.