Cómo añadimos un asistente de IA a una plataforma SaaS — sin romperla

Todos los equipos de SaaS con los que hablamos acaban diciendo la misma frase en voz alta: «Deberíamos poner un asistente de IA aquí dentro». A veces es presión del consejo, a veces el lanzamiento de un competidor, a veces convicción genuina. Lo interesante nunca es la idea: casi todo el mundo la tiene. Lo interesante es la distancia entre esa frase y una función en la que los usuarios reales realmente confían. Esta es la historia de un equipo que la recorrió, y de las decisiones poco glamurosas que lo llevaron hasta allí.

Una nota rápida antes de empezar: hemos anonimizado al cliente y redondeado las cifras. Es una pequeña empresa SaaS B2B rentable —menos de veinte personas— que vende una herramienta de flujos de trabajo a equipos de operaciones. Hemos cambiado suficientes detalles para que no la reconozca, pero la forma del proyecto es exactamente como ocurrió. Las cifras son ilustrativas, no auditadas; preferimos mostrarle el patrón antes que maquillar un gráfico.

Lo escribimos porque el proyecto es un ejemplo casi perfecto de cómo van realmente estas cosas. No fue como decía la presentación de arranque. Fue mejor, pero solo porque estuvimos dispuestos a borrar la primera versión.

La situación: dos problemas con un mismo disfraz

Cuando el fundador se puso en contacto por primera vez, la petición era sencilla: «Queremos un chatbot de IA en la app». Ahí es donde arrancan la mayoría de los proyectos, y también donde muchos se tuercen en silencio. «Chatbot de IA» no es un objetivo, es una forma. Así que nuestra primera tarea fue averiguar qué problema se suponía que debía resolver el chatbot, y si acaso era un solo problema.

No lo era. Bajo esa única petición había dos dolores completamente distintos. El primero era la carga de soporte: un equipo de éxito de cliente de dos personas se ahogaba en tickets repetitivos: «¿cómo exporto esto?», «¿dónde está el ajuste para aquello?», «¿por qué no se ejecutó mi informe?». Alrededor del 60 % de los tickets entrantes eran preguntas ya respondidas en algún lugar de su documentación de ayuda. El segundo dolor era más silencioso y más caro: la activación. Su producto tenía una función realmente potente enterrada a tres clics de profundidad que casi nadie descubría por su cuenta. Los usuarios que la encontraban se quedaban años. Los que no, se marchaban en los dos primeros meses.

Mismo disfraz, dos problemas. Y tiraban en direcciones distintas. Un bot de soporte quiere desviar preguntas y quitarse de en medio. Un asistente de activación quiere iniciar conversaciones y empujar a la gente hacia cosas que no pidió. Si hubiéramos construido «un chatbot de IA» sin separar esto, habríamos construido algo que hacía ambos trabajos mal.

Reducir el alcance a algo que pudiéramos terminar

Ante dos problemas, la tentación es construir un gran asistente que atienda ambos desde el primer día. Convencimos al equipo de no hacerlo. No porque la visión estuviera mal, sino porque un «asistente para todo» de seis meses es exactamente el tipo de proyecto que se entrega tarde, aterriza sin fuerza y pone nervioso a todo el mundo respecto a la IA durante los siguientes dos años.

Así que elegimos uno. Escogimos primero el desvío de soporte, por tres razones aburridas pero decisivas. Tenía un objetivo claro y medible: el volumen de tickets. Usaba contenido que ya existía: su documentación de ayuda y tickets pasados. Y si rendía por debajo de lo esperado, el coste era pequeño: un usuario que no obtenía una buena respuesta simplemente hacía lo que ya hacía y abría un ticket. Riesgo bajo, feedback rápido, métrica honesta. Esa es una buena primera función de IA, siempre.

El asistente de activación no desapareció: lo aparcamos, sobre el papel, con una nota clara: fase dos, una vez probada la capa de recuperación. Esa única decisión probablemente salvó el proyecto. Le dio al equipo una meta que realmente podía alcanzar en semanas en lugar de trimestres.

El primer prototipo que construimos — y borramos

Aquí está la parte que la mayoría de los casos de estudio omiten. Nuestro primer prototipo funcional era, por decirlo con amabilidad, malo. Hicimos lo obvio: conectamos los artículos de ayuda del producto a un gran modelo de lenguaje, añadimos una caja de chat y dejamos que los usuarios hicieran preguntas. En la demo parecía mágico. En pruebas reales se desmoronó de una forma muy concreta y muy instructiva.

El modelo se equivocaba con aplomo. Preguntado por un ajuste renombrado seis meses antes, se inventaba alegremente la antigua ruta de menú. Preguntado por una función de un plan superior, explicaba cómo usarla, a un cliente que no podía acceder a ella. Cada respuesta sonaba autorizada, lo que hacía que las erróneas fueran peores que no dar respuesta alguna. Un bot de soporte que miente educadamente no reduce tickets; genera otros más furiosos.

Podríamos haberlo disimulado con ajustes de prompt. En cambio hicimos algo que se sintió como un paso atrás y resultó ser todo el juego: tiramos el primer prototipo y lo reconstruimos alrededor de una regla estricta: el asistente solo puede responder a partir de fuentes que pueda citar, y de lo contrario debe decir «No lo sé».

Lo que construimos de verdad

La versión que se lanzó fue deliberadamente modesta en lo que intentaba y estricta en cómo se comportaba. Por dentro era un asistente anclado en la recuperación: cuando un usuario preguntaba algo, el sistema primero buscaba en una base de conocimiento curada y actualizada, y luego pedía al modelo que respondiera solo a partir de lo que encontraba, con un enlace de vuelta a la fuente. Sin fuente, sin respuesta segura: solo un traspaso limpio a una persona.

Tres decisiones de diseño hicieron el grueso del trabajo, y ninguna es emocionante. Ese es el punto: las decisiones aburridas suelen ser las que deciden si se confía en una función de IA o si se apaga en silencio.

Anclaje antes que astucia

Cada respuesta estaba atada a un documento real y actual. Dedicamos más tiempo a limpiar y estructurar la base de conocimiento que a ajustar el modelo. Poco glamuroso, y con diferencia el trabajo de mayor apalancamiento del proyecto. Un modelo mediocre sobre contenido excelente y bien mantenido gana a un modelo brillante sobre un desastre desactualizado.

Un traspaso elegante

Cuando el asistente no estaba seguro, no adivinaba. Lo decía y ofrecía una ruta de un clic hacia una persona, llevando consigo el contexto de la conversación para que el usuario nunca tuviera que repetirse. De forma contraintuitiva, esto hizo que la gente confiara más en el bot: un asistente que admite sus límites parece honesto, y se apoyaban en él para el 60 % fácil precisamente porque se apartaba en el 40 % difícil.

Consciente de quién pregunta

Como vivía dentro del producto, el asistente conocía el plan, el rol del usuario y dónde estaba en la app. Así que nunca explicaba una función a la que no podía acceder, y podía decir: «El botón que busca está en la pantalla en la que ya se encuentra». Esa conciencia del producto es la verdadera ventaja de un asistente dentro de la app frente a un chatbot genérico atornillado a una web de marketing.

1. 1
   Limpiamos y estructuramos la base de conocimiento

   Auditamos cada documento de ayuda, eliminamos los obsoletos y etiquetamos el resto por plan y función. Fue la semana uno, y fue la semana más importante.
2. 2
   Construimos la capa de recuperación

   Primero buscar, luego responder. El modelo solo veía contenido verificado y actual, y se le instruyó a rechazar cualquier cosa que no pudiera anclar en una fuente.
3. 3
   Conectamos el contexto del producto

   Enlazamos el asistente con el plan, el rol y la pantalla actual del usuario, para que las respuestas fueran a medida y nunca señalaran funciones inaccesibles.
4. 4
   Diseñamos el plan B honesto

   Construimos la ruta «No estoy seguro — aquí tiene a una persona» como una función de primer nivel, con todo el contexto de la conversación entregado al equipo de soporte.
5. 5
   Lo lanzamos al 10 % de los usuarios tras un flag

   Desplegamos en silencio a una porción de cuentas, observamos conversaciones reales durante dos semanas, arreglamos lo que se rompía y luego ampliamos el despliegue.

Los resultados — y el que nos sorprendió

Después de que el asistente llevara unos tres meses activo para todos, el cuadro era claro. Le daremos cifras redondeadas e ilustrativas: la dirección importa más que los decimales.

La cifra de soporte era la que habíamos prometido, y cumplió: algo más de la mitad de los tickets repetitivos simplemente dejaron de llegar, y el equipo de dos personas recuperó su semana para atender los casos que de verdad necesitaban a una persona. Buen resultado, exactamente como se había definido.

Pero el resultado que de verdad sorprendió al fundador fue uno para el que no habíamos optimizado en absoluto. Como el asistente respondía preguntas de «cómo hago X» todo el día, iba señalando de forma natural a los usuarios hacia aquella función enterrada y adhesiva, la ligada a la retención. Aún no habíamos construido el asistente de activación. El bot de soporte hacía en silencio una parte de su trabajo como efecto secundario, simplemente por ser útil y consciente del producto. Los nuevos usuarios encontraban la función semanas antes que antes.

Lo que le diríamos al próximo equipo

Si usted es un equipo de SaaS mirando fijamente la misma frase de «deberíamos añadir un asistente de IA», hay algunas cosas de este proyecto que se generalizan mucho más allá de él.

• Separe los problemas antes de construir. «Chatbot de IA» casi siempre esconde dos o tres trabajos distintos que piden diseños diferentes.
• Empiece por el caso de uso donde una respuesta errónea cueste menos. El desvío de soporte es un primer paso casi perfecto; el plan B es el statu quo.
• Reserve la mayor parte de su esfuerzo para el contenido, no para el modelo. Anclar en datos limpios y actuales es lo que hace fiable a un asistente.
• Convierta el «No lo sé» en una función, no en un fallo. Un traspaso honesto construye la confianza que hace que los usuarios se apoyen en lo que el bot hace bien.
• Lance primero tras un flag a una pequeña porción. Las conversaciones reales le enseñarán cosas que ninguna demo enseñará jamás.

Preguntas frecuentes