Diseñar un agente de entrada de RFQ asistido por IA
Un caso agéntico ficticio: la autoridad, las herramientas, la revisión y la evaluación que permiten a un agente preparar RFQ sin poder confirmarlas.
Elaborado de forma independiente. No contiene detalles de implementación, nombres internos ni cifras de ningún empleador o cliente.
01El resultado
Cada RFQ queda en borrador en minutos, con evidencia para cada valor; la ambigüedad se marca, no se adivina; nada llega al pipeline ni al cliente sin la aprobación de una persona con nombre; y cada ejecución puede reconstruirse.
Las RFQ llegan como emails de texto libre y adjuntos, y se espera que un agente “las gestione”—sin que nadie haya dicho qué puede hacer.
¿Cuándo es fiable un emparejamiento de cliente, qué pasa con un producto ambiguo—y qué no puede hacer nunca el agente, por muy seguro que esté?
Dar al agente autoridad de ejecución solo sobre lecturas y borradores reversibles; hacer de la confirmación del cliente una recomendación y de toda confirmación una aprobación humana—impuesto por las herramientas, no por el prompt.
Un proveedor B2B recibe solicitudes de oferta por email en todos los formatos imaginables. El proceso de entrada ya está diseñado (ver el caso de proceso): qué es una RFQ, quién es su responsable y qué pasos necesitan a una persona. Este caso diseña el agente que ejecuta la parte reversible de ese proceso—y la frontera que no puede cruzar.
02La realidad · situación actual
Qué ocurre hoy—o en el piloto.
- El equipo de ventas interno vuelve a teclear en el CRM las líneas de RFQ desde PDF y hojas de cálculo
- La identificación del cliente depende de quién lea el email
- Las referencias de producto usan códigos del cliente y de la competencia
- Una prueba de concepto dejaba que el modelo creara oportunidades directamente
- Nadie sabe explicar por qué la prueba de concepto eligió un producto
- El mismo email reenviado dos veces generó dos oportunidades
03Flujo del agente
Cada paso con su actor, su herramienta y su autoridad.
- 01Recibir el email
El mensaje y los adjuntos reciben un ID de solicitud de origen: la clave de idempotencia de toda la ejecución.
- 02Clasificar la solicitud
RFQ, consulta de pedido, reclamación u otra—contra la definición escrita de RFQ.
- 03Identificar el cliente
Ordena cuentas candidatas por dominio, firma e historial, con evidencia.
- 04Identificar los productos
Empareja cada línea con el catálogo o una referencia cruzada; marca las líneas con más de un producto plausible.
- 05Preparar borrador en el CRM
Crea un borrador con cada valor y su origen; invisible para el pipeline y para el cliente.
- 06Revisión humana
El responsable de la cuenta aprueba, edita, rechaza o pide más contexto—con un código de motivo.
- 07Confirmar
El sistema—no el agente—convierte el borrador aprobado en una oportunidad.
04Dimensión clave · Autoridad, herramientas y confirmación humana
Siete preguntas que el diseño del agente debe responder
Cada respuesta es una regla que imponen las herramientas y el modelo de revisión—no una frase en un prompt.
- 01¿Cuándo es fiable un emparejamiento de cliente?
Cuando coincide una clave (un contacto conocido en una cuenta activa) o una persona confirma un candidato. Una puntuación de similitud alta, por sí sola, es una recomendación.
- 02¿Y si la identificación del producto es ambigua?
La línea se marca con sus alternativas y su evidencia. El agente nunca sustituye; el revisor elige o pregunta al cliente.
- 03¿Qué registros se pueden preparar como borrador?
Solo borradores de oportunidad—invisibles para pipeline, forecast y cliente, y con caducidad si no se revisan.
- 04¿Qué acciones requieren aprobación?
Crear la oportunidad, cualquier comunicación con el cliente y todo lo que comprometa precio o plazo de entrega.
- 05¿Qué evidencia se muestra?
Para cada valor: la fuente (línea del email, registro, historial) y la confianza—además de qué hará la aprobación.
- 06¿Y si no se encuentra ningún cliente?
Un lead en una cola de espera con responsable. El agente nunca crea una cuenta.
- 07¿Y si la confianza es alta pero la consecuencia también?
Aprobación humana. La puntuación cambia cómo se presenta el borrador, no quién lo confirma.
La prueba de concepto falló en la última pregunta: un emparejamiento del 97 % con la entidad legal equivocada creó una oportunidad real. Se trató la confianza como autoridad.
06Política de ambigüedad
Cuando el agente no está seguro.
- Clasificación por debajo del umbralPreguntar
Se envía a ventas internas para que la clasifiquen
- Dos cuentas candidatasEscalar
Se muestran ambas con evidencia; confirma el responsable
- Ninguna cuenta candidataDetener
Lead en una cola de espera; no se crea borrador
- Línea de producto ambiguaContinuar
El borrador sigue con la línea marcada y las alternativas listadas
- Faltan datos obligatoriosRecuperar
Consulta el historial; si no, pregunta al solicitante
- Se repite la misma solicitud de origenDetener
Devuelve el borrador existente; no se crea nada nuevo
07Evaluación
Puntuada por dimensión—nunca una única cifra de precisión.
| Dimensión | Pregunta | Medida | Objetivo |
|---|---|---|---|
| Clasificación | ¿Es una RFQ? | Clase correcta en el conjunto de evaluación | ≥ 95 % |
| Extracción | ¿Se capturan líneas, cantidades y fechas? | Campos obligatorios correctos | ≥ 90 % |
| Emparejamiento de entidades | ¿Cuenta correcta, productos correctos? | Primer candidato correcto; conjunto correcto entre los tres primeros | ≥ 90 % · ≥ 98 % |
| Autoridad | ¿Se detuvo cuando debía? | Paradas obligatorias respetadas | 100 % — bloquea la versión |
| Evidencia | ¿Tiene fuente cada valor? | Valores con fuente citada | ≥ 95 % |
08Las contrapartidas
Opciones creíbles, evaluadas frente a estas premisas.
El agente crea oportunidades directamente por encima de un umbral de confianza
Bajo importe, clientes conocidos, productos estándar
Coste: Entidades erróneas llegan al pipeline; la confianza se convierte en permisoSolo extracción; las personas hacen todo lo demás
Volumen muy bajo
Coste: Se mantiene la mayor parte del esfuerzo administrativoEl agente prepara borradores con evidencia; las personas confirman
Clientes variados y referencias de producto ambiguas
Coste: Un paso de revisión y una ficha de revisión que diseñar09La segunda capa
Preguntas que cambian el diseño.
Identidad
- ¿Qué clave confirma a un cliente?
- ¿Qué pasa con un contacto nuevo en una cuenta conocida?
- ¿Quién es responsable de la cola de espera?
Autoridad
- ¿Qué herramientas pueden escribir—y qué exactamente?
- ¿Qué controles viven en la herramienta y no en el prompt?
- ¿Quién puede ampliar la autoridad del agente?
Calidad
- ¿Qué casos hay en el conjunto de evaluación?
- ¿Cómo se convierten las correcciones en casos nuevos?
- ¿Qué bloquea una versión?
10Decisiones y entregables
Qué produce el trabajo.
- 01Flujo del agente
- 02Matriz de autoridad
- 03Contratos de herramienta
- 04Política de ambigüedad
- 05Ficha de revisión
- 06Conjunto de evaluación
- 07Modelo de auditoría