HUB
FINTECH

De abrir un ticket para todo a resolverlo en la propia conversación

Un asistente sobre su propia documentación que retiró el 75% de los tickets y convirtió los que sí eran incidencias en tickets completos.

Startup del sector financiero

ANTES

Cada duda acababa en un ticket

DESPUÉS

75% menos tickets

El problema: casi ningún ticket era una incidencia

La plataforma funcionaba. Lo que no funcionaba era encontrar las cosas dentro de ella: dónde está esta funcionalidad, con quién hablo para este caso, cómo saco este informe. Cada una de esas preguntas terminaba abierta como ticket, porque era el único camino que el usuario tenía a mano.

El equipo de soporte pasaba el día respondiendo cosas que ya estaban documentadas, y ese volumen tapaba lo que sí necesitaba a una persona.

El segundo problema era el contrario y más caro. Cuando el ticket sí era una incidencia real, llegaba con muy poca información. El técnico tenía que escribir al cliente, esperar, volver a preguntar por el dato que faltaba, esperar otra vez. Un error que se arregla en diez minutos se resolvía en días, y ninguno de esos días era de trabajo técnico: eran de ida y vuelta.

Qué construimos

Un asistente que se apoya en la base documental del propio cliente y hace tres cosas distintas según lo que el usuario necesite.

Responder. Resuelve la duda en la conversación, apoyándose en la documentación real del producto, no en lo que el modelo recuerde por su cuenta. Cuando la respuesta completa vive en una página concreta, lleva al usuario hasta ella en lugar de resumirla a medias.

Derivar. Hay casos que no se resuelven con documentación y necesitan una persona concreta, no el buzón genérico. El asistente reconoce esos casos y encamina al usuario hacia quien corresponde.

Abrir el ticket, ya completo. Si lo que hay delante es una incidencia, el asistente pide la información que el equipo técnico va a necesitar y crea el ticket automáticamente con todo dentro.

La base documental la mantiene el cliente. Actualizar una respuesta es actualizar su documentación, no pedirnos un despliegue.

La decisión: no bloquear el ticket, completarlo

Un chatbot de soporte se suele vender por una sola métrica: cuántos tickets evita. Medido así, el éxito consiste en que el usuario se rinda antes de escribir.

Aquí el planteamiento fue otro. Los tickets que sobraban eran los que la documentación ya respondía, y esos desaparecen solos en cuanto la respuesta llega antes. Pero los que sí eran incidencias tenían que seguir existiendo — el problema nunca fue que se abrieran, sino que llegaban vacíos.

Así que la mitad del trabajo fue el camino contrario al habitual: cuando el asistente detecta una incidencia real, no intenta disuadir a nadie. Recoge lo que hace falta y abre el ticket él mismo.

El resultado es que las dos vías mejoran a la vez, y no una a costa de la otra.

Qué hace falta para poner un modelo delante de clientes de una fintech

En el sector financiero, un asistente conversacional no es solo un modelo con un buen prompt. Hay tres cosas que decidimos antes de escribir la primera línea.

Los datos personales no salen sin filtrar. Los mensajes pasan por una capa de detección y anonimización de información personal antes de llegar al modelo. Con Presidio, y como paso obligatorio, no como opción de configuración.

Cada respuesta es trazable. Langfuse registra qué se preguntó, qué documentación se recuperó y qué se contestó. Sin eso, un asistente en producción es una caja negra que nadie puede auditar cuando algo sale mal.

Los cambios se evalúan antes de salir. Con DeepEval hay una batería de casos que se ejecuta contra el sistema, de modo que actualizar la documentación o ajustar el comportamiento no degrada en silencio respuestas que antes eran correctas.

El resto del sistema es Python con FastAPI, Pydantic AI para la orquestación y pgvector para la base de conocimiento. Esto último también fue una decisión: los embeddings viven en el Postgres que el cliente ya opera, en vez de en una base vectorial aparte que habría que administrar, asegurar y pagar. El modelo es Qwen.

El resultado

Los tickets bajaron un 75%. No porque se disuada a nadie de abrirlos, sino porque la inmensa mayoría eran preguntas sobre dudas o documentación, y esas ahora se resuelven en la propia conversación.

La cuarta parte que queda es la que siempre debió existir: incidencias reales, que además entran con la información que el técnico necesita desde el primer mensaje en lugar de después de tres correos. Y las consultas que necesitan a una persona llegan a la persona correcta.

La v1 fue un asistente en la web. Hoy existe además un agente de WhatsApp con las mismas capacidades, así que quien usa la plataforma entra por donde ya está, en vez de por donde nosotros habíamos decidido.

Está en producción y en uso.

ALCANCE

Qué incluía la v1

La v1 salió solo en la web, a propósito: primero comprobar que las respuestas eran buenas sobre la documentación real, y solo después abrir un segundo canal. WhatsApp llegó en una fase posterior, ya con esa base contrastada.

Servicios que intervinieron

¿Construimos algo que escale, juntos?

Cuéntanos tu proyecto. Te respondemos con un plan concreto y un equipo senior — no con un presupuesto genérico.

Hablemos de tu proyectoholalmnhub.com