En los proyectos de IA que desarrollamos en Soamee, pocas cosas nos sorprenden tanto como la desproporción entre el coste de una solución y su impacto real. Este es el caso de una feature que costó menos de $30 al mes implementar y que redujo los tickets de soporte de un cliente SaaS un 40% en las primeras ocho semanas.
No hubo grandes modelos. No hubo infraestructura exótica. Solo una idea simple, bien ejecutada, con el modelo de lenguaje adecuado para la tarea.
El problema: el equipo de soporte ahogado en preguntas repetidas
Cuando el cliente nos contactó, su equipo de soporte gestionaba entre 800 y 1.200 tickets al mes. El problema no era la complejidad de las consultas, sino lo contrario: el 60% de los tickets eran variantes de las mismas 30 preguntas.
“¿Cómo exporto mis datos?”, “¿Puedo cambiar el plan desde el panel?”, “¿Por qué no me llega el correo de confirmación?”. Preguntas que cualquier persona que leyera la documentación podría responder en dos minutos. Pero los usuarios preferían abrir un ticket antes que buscar la respuesta.
El coste directo era evidente: horas de agentes respondiendo preguntas cuya respuesta ya estaba escrita. Pero el coste indirecto era peor: los tickets complejos —los que realmente requerían intervención humana— tardaban más en recibir atención porque la cola estaba bloqueada por preguntas sencillas.
La solución más obvia habría sido contratar más agentes. Pero el equipo era pequeño, el presupuesto ajustado, y escalar soporte humano no resuelve el problema de fondo: la fricción entre el usuario y la documentación existente.
La idea: ¿qué pasa si simplemente respondemos las fáciles?
La insight clave fue esta: no necesitamos un agente de IA sofisticado. Necesitamos algo que lea las FAQs existentes y sea capaz de responder en lenguaje natural cuando un usuario pregunta lo mismo con otras palabras.
RAG básico. Modelo pequeño y barato. Fallback a humano cuando la confianza es baja. Nada más.
La tentación en estos proyectos es sobreingeniear la solución. Añadir memoria conversacional, integrar el CRM, construir un agente multi-paso con acceso a APIs internas. Todo eso puede tener sentido en fases posteriores. Pero en la fase cero, la pregunta correcta es: ¿cuál es la feature mínima que resuelve el 80% del problema?
En este caso, la respuesta era clara: un auto-respondedor de FAQs basado en búsqueda semántica y un LLM de bajo coste.
La arquitectura: simple por diseño
El sistema que construimos tiene cuatro componentes y se puede diagramar en una servilleta:
1. Base de conocimiento indexada
Tomamos los 47 artículos de la base de conocimiento existente del cliente (en formato Markdown) y los procesamos con un script de ingesta. Cada artículo se divide en fragmentos de ~500 tokens con solapamiento de 50 tokens para preservar el contexto entre párrafos. Cada fragmento se convierte en un vector de embeddings usando el modelo text-embedding-3-small de OpenAI (coste: $0,00002 por 1.000 tokens; la ingesta completa costó menos de $0,05).
Los vectores se almacenan en una base de datos vectorial ligera (usamos Qdrant en instancia propia, aunque Supabase con pgvector funciona igual de bien para este volumen).
2. Endpoint de búsqueda semántica
Cuando un usuario escribe una consulta en el widget de soporte, antes de abrir un ticket, el texto pasa por nuestro endpoint. Se convierte en embedding, se buscan los 3 fragmentos más relevantes por similitud coseno, y se construye un prompt con:
- La consulta original del usuario
- Los 3 fragmentos de documentación recuperados
- Una instrucción de sistema que pide respuesta concisa, en tono de marca, con la instrucción explícita de no inventar información no presente en el contexto
3. LLM de bajo coste con caching
El prompt resultante va a Claude Haiku (o GPT-4o-mini, según preferencia). Estos modelos cuestan ~$0,001 por cada 1.000 tokens de entrada y ~$0,002 por cada 1.000 tokens de salida. Un prompt típico tiene 600-800 tokens de entrada y genera 150-250 tokens de salida. El coste por consulta es de aproximadamente $0,0015-$0,0025.
El caching semántico es el elemento que más reduce el coste en producción. Para las consultas más frecuentes (que representan el 35-40% del volumen total), el sistema devuelve la respuesta cacheada sin llamar al LLM. El coste efectivo de esas consultas es virtualmente cero.
4. Lógica de fallback
El sistema incluye un score de confianza basado en la puntuación de similitud del resultado más cercano. Si el fragmento más relevante tiene una similitud inferior a 0,72 (umbral calibrado durante las primeras semanas), el sistema no responde automáticamente. En su lugar, muestra al usuario la documentación más relevante encontrada y ofrece la opción de abrir un ticket, con el contexto de la búsqueda pre-rellenado para el agente.
Esto garantiza que el sistema solo responde cuando tiene base para hacerlo. La tasa de alucinaciones observada en producción fue inferior al 0,5%.
El desglose de costes: $0,002 por consulta
La siguiente tabla muestra el coste real mensual del sistema en producción, con un volumen de ~1.000 consultas al mes:
| Componente | Detalle | Coste/mes |
|---|---|---|
| Embeddings de consultas | 1.000 queries × ~300 tokens | ~$0,006 |
| LLM (Claude Haiku) | 600 consultas sin caché × ~1.000 tokens | ~$1,20 |
| Base de datos vectorial | Qdrant cloud (tier básico) | $10,00 |
| Servidor/API | Función serverless (AWS Lambda) | ~$2,00 |
| Re-ingesta semanal de docs | Actualización de contenido | ~$0,10 |
| Total | ~$13-15/mes |
Con caching activado para las consultas más frecuentes, el coste efectivo por consulta resuelta es de $0,002. Para las consultas cacheadas, el coste es de $0,00.
Lo que antes costaba horas de tiempo de agente ahora cuesta menos que un café.
Los resultados: ocho semanas después
Antes del sistema, el equipo procesaba una media de 950 tickets al mes. Ocho semanas después del despliegue:
Reducción de tickets: -40%
El sistema resolvió de forma autónoma el 40% de las consultas que antes generaban tickets. No las desvió, no las ignoró: las respondió de forma satisfactoria sin intervención humana.
Tiempo de respuesta: 3 segundos de media
El tiempo de respuesta del sistema es prácticamente instantáneo desde la perspectiva del usuario. Comparado con el tiempo de espera anterior (que podía ser de 4-24 horas según la carga del equipo), la mejora percibida fue significativa.
Satisfacción: 92% de valoraciones positivas
Implementamos una microvaloración al final de cada respuesta automática (pulgar arriba / pulgar abajo). El 92% de las respuestas automáticas recibieron valoración positiva. El 8% restante derivó en ticket con contexto pre-rellenado.
Tickets complejos con más atención
Con el 40% menos de carga en la cola, los agentes pudieron dedicar más tiempo a los tickets que realmente lo necesitaban. El tiempo medio de resolución de tickets complejos se redujo de 18 horas a 11 horas.
Lo que nos sorprendió: los usuarios prefieren la IA para preguntas simples
El resultado más inesperado no fue cuantitativo sino cualitativo. En las primeras semanas, recibimos feedback anecdótico de usuarios que decían preferir la respuesta automática a esperar a un agente para preguntas sencillas.
La razón es intuitiva cuando lo piensas: si sabes que tu pregunta es simple, la fricción de esperar respuesta humana (por mínima que sea) se percibe como desproporcionada. Una respuesta instantánea, aunque sea de una IA, elimina esa fricción.
Esto también nos enseñó algo sobre el diseño de estos sistemas: la transparencia importa. El widget indicaba claramente “Respuesta automática basada en nuestra documentación”. No intentaba hacerse pasar por humano. Y eso, lejos de generar desconfianza, generó confianza: los usuarios sabían exactamente qué estaban recibiendo y por qué.
Lo que no funcionó: los límites del sistema
La honestidad es parte del diseño. Este sistema tiene límites claros y es importante reconocerlos.
Incidencias técnicas complejas
Cuando un usuario reporta un error con pasos específicos de reproducción, logs de error o comportamientos inesperados, el sistema RAG no puede ayudar. La documentación no contiene ese nivel de especificidad. Estos casos siempre van a agente humano, y deben hacerlo.
Quejas y situaciones emocionales
Un usuario frustrado que lleva días con un problema no quiere una respuesta de documentación. Quiere sentirse escuchado. El sistema detecta patrones de frustración en el texto (palabras como “inaceptable”, “llevo semanas”, “quiero cancelar”) y escala directamente a humano, sin intentar responder con documentación.
Preguntas que implican contexto de cuenta
“¿Cuántos usuarios puedo añadir en mi plan actual?” parece una pregunta de FAQ pero requiere conocer el plan específico del usuario. Sin acceso al CRM, el sistema responde con la información genérica de planes y recomienda verificar en la configuración de cuenta. En la fase dos del proyecto, está previsto añadir un token de sesión que permita al sistema conocer el plan activo del usuario.
Onboarding de nuevos flujos
Cuando el producto lanza una feature nueva, hay un período de 1-2 semanas hasta que la documentación está actualizada y re-ingerida. Durante ese período, las preguntas sobre la nueva feature van a agente. Es el único “lag” estructural del sistema.
La matemática: $30 al mes frente a lo que cuesta el tiempo de un agente
Pongamos los números en perspectiva. Un agente de soporte dedicado en España tiene un coste empresa de aproximadamente 2.000-2.500 euros al mes. Su capacidad de gestión de tickets, asumiendo que dedica el 70% de su tiempo a responder consultas, es de unas 400-600 tickets al mes.
El sistema de IA resolvió 380 tickets al mes (40% de 950) a un coste de $15. Si esos tickets los hubiera gestionado un agente humano, habrían representado el 65-95% de su capacidad mensual.
No estamos diciendo que la IA reemplaza al agente. Estamos diciendo que libera al agente para hacer el trabajo que solo un humano puede hacer bien.
El ROI en este caso fue de varios órdenes de magnitud. Y la inversión inicial de implementación se amortizó en las primeras dos semanas de operación.
Cómo replicar esto en tu producto
Si tienes un SaaS con una base de conocimiento existente y un volumen de soporte que empieza a ser una carga, este es el camino más directo:
Semana 1: Audita tus tickets de los últimos 3 meses. Clasifica las consultas por categoría. Si el 40-60% son preguntas cuya respuesta ya existe en tu documentación, tienes un caso de uso claro.
Semana 2: Ingesta de documentación. Convierte tus artículos a Markdown si no lo están, divídelos en fragmentos, genera embeddings. Este proceso es técnico pero no complejo.
Semana 3: Construye el endpoint mínimo. Búsqueda semántica + prompt + LLM + lógica de fallback. No añadas más funcionalidad hasta que esto funcione.
Semana 4: Despliega en modo shadow (la IA genera respuestas pero un humano las revisa antes de enviar). Calibra el umbral de confianza. Ajusta el prompt según los errores que observes.
Semana 5-8: Activa el modo autónomo para las categorías con mayor confianza. Monitoriza la tasa de satisfacción. Itera.
El principio subyacente es siempre el mismo: empieza pequeño, mide todo, itera sobre datos reales.
Conclusión: la IA no tiene que ser cara para ser útil
La narrativa dominante sobre IA en empresas suele girar alrededor de grandes transformaciones, plataformas complejas y presupuestos de seis cifras. Pero algunos de los impactos más significativos que hemos visto en nuestros proyectos vienen de features pequeñas, bien definidas, que resuelven un problema concreto con tecnología modesta.
$0,002 por consulta. $15 al mes. 40% menos de tickets. 92% de satisfacción.
Esos números no son excepcionales porque la tecnología sea sofisticada. Son excepcionales porque la tecnología es la adecuada para el problema.
Si tu equipo de soporte dedica tiempo a responder preguntas que ya están respondidas en tu documentación, tienes un problema que la IA puede resolver hoy, con modelos disponibles públicamente, a un coste que no necesita justificación ejecutiva.
En Soamee trabajamos exactamente este tipo de proyectos: soluciones de IA prácticas que generan impacto medible sin infraestructura innecesaria. Si quieres explorar si algo así tiene sentido para tu producto, cuéntanos el contexto.