Un agente que cualifica formularios, paso a paso

El escenario se repite: entre cien y trescientos formularios al mes, un comercial que los mira cuando puede y una sensación general de que se pierden oportunidades. Nadie sabe cuántas, porque no hay registro. Ese es el terreno perfecto para un primer agente: frecuencia alta, criterio explicable y errores reversibles.

Voy a contarlo como lo monto, en el orden en que lo monto, con los números de un proyecto real de este año. La parte técnica es la más corta.

Antes de tocar nada: el criterio en una página

La primera sesión no tiene ordenador. Me siento con quien atiende los formularios hoy y le pido que clasifique treinta reales del último mes en tres montones: llamar hoy, llamar esta semana, no encaja. Y que diga en voz alta por qué en cada uno.

De ahí sale el criterio. En el proyecto que uso de ejemplo salieron seis señales positivas, cuatro descalificadoras y dos que dependían del presupuesto declarado. Todo cabía en una página. Esa página es el documento más importante del proyecto: si no existe, lo que montes después será una lotería con buena presentación.

DETALLE QUE AHORRA DISCUSIONES >Las señales descalificadoras se aplican antes de puntuar y no se discuten. Un descarte por regla clara es revisable; un descarte por puntuación baja invita a interpretar, y ahí es donde el equipo pierde la confianza.

Pieza 1 · Una sola puerta de entrada

Antes había tres formularios distintos, dos direcciones de correo y los mensajes de LinkedIn. Lo primero fue reducirlo a una entrada única: todos los formularios de la web mandan al mismo webhook, y los correos que llegan a la dirección genérica se reenvían al mismo sitio.

El campo que más discutimos fue el de presupuesto. Al final quedó opcional y con tramos, porque obligatorio bajaba el número de envíos un 30 %. Con tramos opcionales lo rellena la mitad, y esa mitad es la que más convierte.

• Cinco campos: nombre, empresa, correo, qué necesitas y plazo. El presupuesto por tramos, opcional.
• Un campo oculto con la página de origen: sirve después para saber qué contenido trae mejores consultas.
• Todo lo que llega se guarda tal cual en la tabla antes de que el modelo vea nada.

Pieza 2 · El modelo clasifica y resume

Aquí el trabajo es de redacción, no de programación. La instrucción incluye el criterio de la página anterior, tres ejemplos completos de cada categoría con su justificación, el formato exacto de salida y una orden clara: si falta información para decidir, la categoría es «faltan datos», nunca una suposición.

La salida es un objeto con cinco campos: categoría, puntuación, dos líneas de resumen para el comercial, la pregunta pendiente si hay alguna, y las señales detectadas. Ese resumen de dos líneas es lo que más se agradece en el equipo: es lo que se lee en el móvil antes de llamar.

1. Categoría: llamar hoy, esta semana, no encaja, faltan datos.
2. Puntuación numérica, sólo como apoyo, nunca como decisión única.
3. Resumen de dos líneas escrito para quien va a llamar, con el problema del cliente en sus palabras.
4. Pregunta pendiente, si el caso no se puede decidir sin ella.
5. Señales detectadas, para poder auditar la decisión después.

«Un agente que no puede decir «faltan datos» acaba inventando la respuesta que hacía falta para no bloquearse.»

Pieza 3 · La tabla donde queda todo

Cada formulario deja una fila con la entrada original, la salida del modelo, la fecha, la versión de la instrucción usada y una columna vacía: la corrección humana. Durante las dos primeras semanas, alguien revisa cada fila y, si no está de acuerdo, escribe la categoría correcta.

Esa columna es el motor de mejora del sistema. En el proyecto de ejemplo, la primera semana hubo un 22 % de correcciones; la segunda, un 9 %; a partir de la cuarta, alrededor del 4 %. Las correcciones no se usan para reentrenar nada: se leen los viernes y se corrige la instrucción o se añade un ejemplo.

La versión de la instrucción en cada fila parece un detalle burocrático hasta el día en que empeora algo y quieres saber a partir de cuándo. Es una columna de texto y vale su peso en oro.

Pieza 4 · El aviso al comercial

Aquí se decide si el sistema se usa o se ignora. Un mensaje por cada formulario en un canal compartido se convierte en ruido en dos semanas. Lo que ha funcionado: los «llamar hoy» llegan al momento con nombre, empresa, resumen de dos líneas y enlace a la fila; el resto se agrupa en un resumen a las nueve de la mañana.

La fila de «faltan datos» tuvo un efecto que no esperaba: el correo con una sola pregunta concreta recuperó el 35 % de esos casos en menos de un día. Antes, esos formularios se quedaban esperando a que alguien tuviera tiempo de pedir aclaraciones.

Pieza 5 · Las dos semanas de sombra

El agente no manda nada fuera durante las dos primeras semanas. Clasifica, escribe en la tabla y avisa internamente; las respuestas al cliente las sigue mandando una persona. Es la parte que los clientes quieren saltarse y la que más problemas evita.

Al final de esas dos semanas hay tres números sobre la mesa: porcentaje de correcciones, minutos ahorrados por semana y casos raros encontrados. Con ellos se decide qué se automatiza del todo. En el proyecto de ejemplo se automatizaron los avisos y el correo de «faltan datos»; la respuesta a los «no encaja» se quedó con revisión humana por decisión del cliente, y me pareció sensato.

RESULTADO A LAS SEIS SEMANAS >De 4 h 20 min semanales dedicadas a mirar formularios a unos 50 minutos de revisión. El tiempo medio hasta la primera llamada bajó de 31 horas a 4. Y por primera vez existía un número de cuántas consultas no encajaban: el 41 %.

Qué se rompió y cómo

Tres cosas, y las cuento porque van a pasar en cualquier montaje parecido. Un formulario en inglés que la instrucción no contemplaba y que se clasificó como «faltan datos» —correcto por casualidad, no por diseño—. Un cambio en la web que renombró un campo y dejó el resumen sin el problema del cliente durante dos días. Y un pico de treinta envíos de un robot que llenó el canal.

• Idiomas: instrucción explícita para responder en el idioma del formulario, y detección antes de clasificar.
• Nombres de campo: nodo de normalización al principio y aviso si falta un campo esperado.
• Robots: límite de envíos por dirección IP y hora, y una comprobación de que el texto no es basura antes de gastar una llamada al modelo.

Ninguno de los tres fue un problema del modelo. Los tres fueron problemas de alrededor, que es donde están casi siempre.