Cifras del cliente: de 100 consultas a 33 citas agendadas

El reto

El sitio del despacho recibía preguntas y no hacía nada con ellas. Alguien con un problema real llegaba a las once de la noche, encontraba un formulario de contacto, y o lo llenaba y esperaba o se iba. De los que se iban, el despacho nunca se enteraba.

La solución obvia es un asistente que responda la pregunta, y la respuesta misma es lo que frena a la mayoría de los despachos. Decirle a alguien del público que califica para algo, o que su caso va a prosperar, es ejercer la abogacía. Un sistema que lo hace una sola vez, en cualquier idioma, es un pasivo y no una fuente de trabajo. Todo lo que se construyó sale de ahí.

El enfoque

Separamos las dos cosas que una buena respuesta hace a la vez: explicar cuáles son las opciones y decidir cuál aplica. Explicar es información, y el software puede hacerlo. Decidir es criterio legal, le corresponde al abogado, y construimos el sistema para que no pueda derivar hacia ese asiento.

El abogado escribió las reglas de comportamiento. Nosotros construimos el sistema que las aplica y las verifica, en vez de escribir un prompt y confiar. El pipeline aplica esas reglas como revisiones en vez de pedirle al modelo que las recuerde, y una capa de pruebas aparte califica cada cambio contra ellas. Eso es lo que le permitió ponerle su nombre.

La solución

Una sola pregunta, respondida en público. Un visitante hace una pregunta, sin cuenta, en su propio idioma. Un modelo barato la filtra, un modelo caro escribe la respuesta con búsqueda web en vivo para traer material actualizado, y un panorama de una a tres páginas llega al navegador en 20 a 90 segundos. Cierra con una oferta de consulta enrutada al calendario del despacho.

Una capa de cumplimiento aplicada en el sistema. La respuesta nunca determina si alguien califica y nunca predice un resultado. Nombra de entrada y sin rodeos cualquier complicación que el visitante revele, en vez de suavizarla hasta que suene mejor. El sistema lo admite cuando una pregunta no trae lo suficiente para responder, y enruta a una consulta en vez de asumir hechos y construir sobre ellos. Cada respuesta cierra con el descargo del despacho, traducido cuando la respuesta no está en inglés.

Una cuarta capa de pruebas que califica las reglas, no el código. Las pruebas unitarias, de integración y de extremo a extremo dicen que el pipeline funciona. Ninguna dice que la respuesta fue segura. Así que cada escenario empareja un fixture con una respuesta ideal que el abogado escribió él mismo: revisiones deterministas cubren las reglas que él hizo no negociables, y un juez LLM califica el resto contra su versión. Corre fuera de la suite de cada commit, así las pruebas que corren en cada push no gastan presupuesto de modelo, y el pipeline registra cada corrida contra el prompt que la produjo.

Un ciclo de curaduría que captura el criterio del abogado. Él revisa respuestas candidatas en una aplicación interna de revisión, las califica y las anota. El sistema embebe las que él selecciona, las recupera contra la pregunta del visitante en vivo y las inyecta como ejemplos. El modelo nunca se reentrena. Las respuestas seleccionadas alimentan la recuperación, lo que mantiene su criterio legible en vez de horneado en pesos que nadie puede inspeccionar. El cliente trazó esa línea antes de que empezara el trabajo.

Resultados

Cifras reportadas por el cliente, de las primeras dos semanas y media después del lanzamiento, en un despacho que no nombramos. Son cifras del propio cliente y aproximadas.

• Unas 100 consultas de visitantes respondidas, de las cuales unas 33 terminaron en cita agendada.
• Unas 15 de esas citas se atendieron, y unos 5 terminaron en casos firmados de unos $5,000 cada uno.
• Una tasa de consulta a cita cercana a 1 de cada 3, que es el número que la plataforma existe para mover.

Dos notas honestas. Son cifras del cliente y no instrumentación nuestra, y dos semanas y media es una ventana corta, así que una tasa medida sobre una más larga probablemente se vería distinta. Y la brecha entre agendar y asistir es real: cerca de la mitad de quienes agendaron una cita no llegaron. Ese es un problema de agenda que el asistente no resuelve, y no vamos a decir que sí.

Qué lo hizo difícil

Probar que las reglas se cumplían fue más difícil que escribirlas. Una regla como “nunca predecir un resultado” es fácil de meter en un prompt e imposible de verificar leyendo código. La cuarta capa de pruebas es lo que cerró esa brecha. Sin ella, cada cambio de prompt es un riesgo sin medir sobre la única propiedad que hace publicable el sistema, y la falla aparece frente a alguien del público en vez de en una corrida de pruebas.

El segundo problema fue el tiempo. Una generación que puede tardar minuto y medio no puede sostener una conexión abierta ni bloquear una petición. El pipeline toma cada trabajo de forma atómica, lo que evita que dos workers agarren el mismo, empuja la respuesta terminada al navegador en vez de dejarla esperando en un socket, y barre los trabajos que quedaron tomados y sin terminar. Un visitante que cierra la pestaña y vuelve igual recibe su respuesta.