Lo que se necesita para construir una IA que realmente funcione en soporte al cliente (perspectivas del jefe de IA de Hiver)

Perspectivas del Jefe de IA de Hiver

La mayoría de las personas asume que construir funciones de IA para una plataforma de atención al cliente es solo cuestión de planificación, ejecución y entrega.

Pero si hablas con las personas detrás de escena, sabrás cuán diferente es realmente la realidad.

Anurag Maherchandani, Jefe de IA en Hiver, es una de esas personas. En Hiver, una plataforma de atención al cliente potenciada por IA utilizada por más de 10.000 equipos de soporte para gestionar conversaciones con clientes a escala, la presión para "agregar IA" llegó temprano y con fuerza. Cada bandeja de entrada, cada ticket, cada interacción con el cliente parecía un candidato natural para la automatización.

Anurag lidera todas las iniciativas de Hiver's AI, lo que significa que es responsable de definir qué construir, cómo construirlo y por qué debería importar a los clientes. Esta es su perspectiva sobre lo que realmente se necesita para crear funciones de IA que de verdad funcionen.

Empieza por el resultado, no por el modelo

El principio central detrás de cada decisión relacionada con IA en Hiver: La IA no es el producto. El resultado es el producto.

En la práctica, esto significa que el punto de partida para cualquier función de IA nunca es "¿qué puede hacer este modelo?" Es "¿en qué decisiones gastan tiempo los humanos que no deberían tener que tomar?"

Esa distinción define todo lo que sigue, desde la elección del problema hasta cómo se muestra la función en la interfaz de usuario.

"Cuando los equipos dicen que están 'construyendo un producto de IA', normalmente quieren decir que han integrado un modelo, lo han expuesto a través de una interfaz de usuario y han conseguido cifras sólidas de precisión. Pero nada de eso garantiza valor. Los usuarios no compran inteligencia. Compran alivio: del trabajo repetitivo, de la incertidumbre, de la fricción operativa", dice Anurag.

Incluso si un modelo se ve muy bien en las pruebas, la verdadera prueba de fuego es si realmente impacta en la forma en que los usuarios trabajan.

Inferencia o reglas: escoge primero la herramienta adecuada 

Antes de que cualquier problema llegue a la etapa de selección de modelos o evaluación de datos, hay una pregunta más fundamental: ¿Realmente esto requiere inferencia?

La inferencia significa que el sistema necesita generalizar a partir de patrones que no ha visto explícitamente, haciendo juicios que no pueden capturarse por completo de antemano.

Las reglas significan que la lógica puede escribirse de forma explícita: si X, entonces Y. Los dos enfoques no son intercambiables, y acudir a la inferencia cuando bastarían reglas añade costes, latencia e imprevisibilidad sin obtener ningún beneficio.

Cuando el equipo de Hiver necesitó configurar el enrutamiento de correos de segmentos de clientes específicos como cuentas VIP, ciertas industrias o dominios concretos, el instinto fue construir un modelo de IA que pudiera identificarlos automáticamente.

En lugar de eso, Hiver creó objetos de reglas configurables. Estos utilizan lógica explícita basada en dominios, palabras clave y metadatos. El resultado es predecible, fácil de depurar y configurable por los usuarios finales sin involucrar al equipo de IA de Hiver.

Por ejemplo, si una empresa quiere que todos los correos de @enterprise.com o mensajes que contengan la palabra “contrato” vayan a una bandeja de entrada prioritaria, pueden configurar una regla en minutos. Esto no requiere IA y no hay ambigüedad sobre cómo se manejan los correos.

Como dice Anurag: "Si puedes escribir las reglas, escribe las reglas. Reserva la IA para los problemas en los que las reglas sean imposibles de enumerar, donde necesites que el sistema generalice desde patrones que no ha visto explícitamente."

Evaluación de problemas que sí requieren inferencia 

Una vez que un problema realmente requiere inferencia, Hiver lo evalúa contra cuatro criterios antes de comprometerse a desarrollarlo:

1. Frecuencia. La IA tiene un coste real: coste de inferencia, latencia añadida y modos de fallo impredecibles. Ese coste solo tiene sentido cuando la tarea es lo suficientemente frecuente como para que la automatización se acumule. Una tarea que ocurre unas pocas veces a la semana rara vez justifica la complejidad. Una tarea que los agentes realizan cientos de veces al día, sí.
2. Predictibilidad. Algunas clasificaciones dependen de información presente en la entrada (contenido del correo electrónico, asunto, metadatos) más que de aprender de los datos disponibles. Otras dependen de contexto que el modelo simplemente no tiene: nivel del cliente, políticas internas de escalado, juicio del agente desarrollado con el tiempo. Antes de comprometerse a construir, el equipo realiza comprobaciones de viabilidad en datos históricos para determinar si una predicción es siquiera posible con un nivel de confianza útil. Si la señal no está presente, ninguna decisión de arquitectura cambia eso.
3. Demanda del cliente. ¿Esto resuelve un problema que los clientes han identificado, o uno que el equipo asume que tienen? La primera opción tiene una probabilidad mucho mayor de adopción. La segunda tiende a producir funciones que funcionan bien pero que se ignoran en el momento de adoptarlas.
4. Importancia y reversibilidad. ¿Qué pasa cuando el modelo se equivoca? Una etiqueta mal clasificada que un agente corrige con un clic tiene un perfil de riesgo muy diferente al de una respuesta enviada erróneamente a un cliente o una escalada no realizada. Las predicciones de bajo riesgo y fácilmente reversibles son excelentes candidatas para la automatización. Las decisiones de alto riesgo necesitan revisión humana o umbrales de confianza significativamente más altos antes de que se activen.

La función de auto-etiquetado de Hiver funciona porque cumple con los cuatro criterios. Utiliza un modelo para inferir la etiqueta más relevante para una conversación entrante. Los agentes no tienen que categorizar manualmente cada ticket.

Los equipos definen un conjunto de etiquetas en el panel de administración, como “Facturación” o “Soporte Técnico.” Estas funcionan como objetivos de predicción. El modelo aprende patrones del contenido del correo electrónico, asunto y metadatos. Solo se incluyen etiquetas con señales claras.

Los agentes realizan esta tarea en casi todas las conversaciones, lo que la convierte en una tarea de alta frecuencia. La señal está presente en el contenido del correo para las etiquetas incluidas, lo que la hace predecible. Los clientes de Hiver han solicitado explícitamente reducir la clasificación manual, lo que impulsa la adopción. Cuando el modelo se equivoca, la etiqueta se puede corregir con un clic, manteniendo el riesgo bajo y reversible.

El análisis de sentimiento sigue el mismo patrón. Analiza el tono de cada conversación para identificar si un cliente está frustrado, neutral o satisfecho. Los equipos ven esto en cada conversación, por lo que es de alta frecuencia. El tono está presente en el texto, lo que lo hace predecible.

Los equipos quieren visibilidad temprana de los clientes frustrados, lo que genera una demanda clara. Si el modelo se equivoca, los agentes pueden corregirlo sin afectar el resultado, manteniendo el riesgo bajo.

Pruebas de Viabilidad Antes de Construir

Una de las partes más exigentes del proceso de Hiver: realizar pruebas de viabilidad de precisión antes de escribir cualquier código de producción.

La función de sugerencia de etiquetas es un ejemplo instructivo. Por ejemplo, si un correo electrónico dice, “Me cobraron dos veces,” el modelo debería elegir “Facturación.” Pero también intentaba seleccionar etiquetas como “Cliente VIP” o “Escalar al Gerente,” que no pueden inferirse únicamente a partir del correo. La precisión era baja y los agentes dejaron de confiar en la salida.

El problema de fondo era no distinguir entre tipos de etiquetas predecibles e impredecibles. Las etiquetas de categoría como “Facturación,” “Soporte Técnico,” y “Devoluciones” corresponden a patrones lingüísticos presentes en el contenido de los correos. Son aprendibles.

Las etiquetas operativas como “Cliente VIP,” “En espera de Legal,” y “Escalar al Gerente” dependen de contexto externo a la entrada: historial de la cuenta, reglas internas de negocio, coordinación entre equipos. Ningún modelo entrenado con correos de clientes las predecirá de forma fiable.

La solución fue estructural: antes de que cualquier tipo de etiqueta se incluya como objetivo de predicción, pasa por una comprobación de viabilidad. ¿El histórico de datos respalda una predicción fiable de este resultado? Si no es así, se excluye del alcance del modelo, independientemente de lo útil que pueda ser teóricamente automatizar esa etiqueta.

“La disciplina de decir ‘este tipo de etiqueta no es un buen candidato para automatización’ fue más difícil que construir el modelo. Pero significó que solo lanzamos predicciones en las que los agentes podían confiar.”

Incorporar IA en el Flujo de Trabajo, No Encima de Él

La ubicación de la IA en el producto importa tanto como lo que hace. 

Una función que hace que los usuarios se detengan, escriban una instrucción y revisen el resultado antes de actuar ha añadido un paso al flujo de trabajo, no eliminado uno. Eso es negativo neto incluso si la IA es precisa. Los usuarios que van rápido, gestionando ticket tras ticket, evitarán cualquier cosa que interrumpa ese ritmo. 

La dirección de diseño que funciona: IA que actúa antes de que el usuario tenga que pensar en ella. Con Hiver: 

• Los correos electrónicos son etiquetados antes de que los agentes los abran.
• El sentimiento se calcula y se marca antes de que un agente abra la conversación: un cliente frustrado ya ha salido a la cabeza de la cola.
• El orden de la cola refleja señales de prioridad sin que los agentes tengan que configurar nada.
• Los borradores de respuestas aparecen en línea como sugerencias.
• Los casos en los que la confianza del modelo cae por debajo de un umbral se presentan para revisión humana en lugar de que se tome alguna acción automática.

La interfaz no está diseñada para que los agentes pidan ayuda a la IA. No es necesario que los agentes la activen. Los correos se etiquetan y priorizan antes de que los abran. La IA elimina el esfuerzo antes de que el agente tenga que pensar en ello. 

La métrica interna para saber si esto está funcionando: "Si los usuarios notan la IA, probablemente la construiste mal." 

Cuando funciona, los usuarios dejan de mencionar la función de IA. Hablan de tiempos de resolución más rápidos, menor acumulación de pendientes, incorporación más fácil de nuevos agentes. La IA ha pasado de ser visible a ser estructural.

📌 Vista del Cliente: Cómo Funciona en la Práctica

En ITS Logistics, los equipos gestionaban las conversaciones con clientes desde bandejas de entrada dispersas, derivando solicitudes manualmente y a menudo solapándose con respuestas duplicadas o seguimientos perdidos. Tras migrar a Hiver, eso cambió rápidamente. En tan solo tres semanas, el tiempo de respuesta para presupuestos se redujo en un 61%, y la mayoría de solicitudes entrantes se asignaban automáticamente a la persona adecuada. Más importante aún, cada conversación tenía un responsable claro y los gestores finalmente tenían visibilidad sobre el avance del trabajo. El resultado fue un sistema capaz de gestionar la creciente demanda sin añadir complejidad ni aumentar el personal, porque el trabajo mismo se volvió más estructurado y predecible. “Hiver transformó consultas dispersas en un sistema estructurado de atención al cliente. Cada solicitud se rastrea, tiene dueño y se resuelve más rápido.” — Alejandro Arboleda, Director de Operaciones, ITS Logistics.

Precisión y Confianza Son Problemas Diferentes

Un sistema puede alcanzar una precisión del 95% y aún así fallar en producción si los usuarios no tienen un modelo mental fiable de cuándo fallará.

La confianza surge de la previsibilidad y el control. Los usuarios necesitan entender el comportamiento del sistema lo suficiente como para saber cuándo pueden confiar en él y cuándo deben anularlo. Si no pueden desarrollar ese modelo, dejarán de usar la función o dejarán de revisar su resultado, ambos son modos de fallo.

El enfoque de Hiver es hacer de la corrección una parte principal del diseño más que una solución ante errores. Los agentes pueden anular cualquier predicción con un solo clic. El sistema recoge las ediciones como señales de retroalimentación. Los umbrales basados en confianza determinan qué se aplica automáticamente y qué se muestra para revisión.

En palabras de Anurag, "En vez de tratar las anulaciones como fallos, las construimos como funciones. Así los agentes mantienen el control y se crea un bucle de aprendizaje sin necesidad de entrenar nunca con datos de clientes. El sistema mejora observando resultados."

Esto también resuelve un problema de datos. Porque las correcciones vuelven como señales de retroalimentación, el modelo mejora aprendiendo de los resultados observados en vez de requerir acceso a los datos originales de los clientes.

El límite de privacidad se mantiene intacto mientras el sistema se vuelve más preciso con el tiempo.

Dos Preguntas Antes de Lanzar Cualquier Función de IA

Antes de aprobar cualquier nueva función de IA, dos preguntas:

"Si mañana eliminan esta función, ¿los usuarios se quejarían?"

Si la respuesta es no, la función es complementaria pero no esencial. Todavía no ha cambiado la forma en que la gente trabaja. Esa es la meta por la que vale la pena esforzarse.

"¿Esta función reduce una decisión o crea una nueva?"

Si los usuarios tienen que decidir si confían o no en la IA, configurarla o interpretar su resultado antes de actuar, la IA ha añadido carga cognitiva en vez de quitarla.

Eso es un fracaso, sin importar el desempeño técnico.

El Verdadero Trabajo Detrás de las Funciones de IA

Construir IA que funcione en producción tiene más que ver con seleccionar el problema correcto, probar la viabilidad y diseñar para la forma en que la gente realmente trabaja, que con seleccionar el modelo adecuado. La inteligencia artificial en sí es la parte más pequeña del problema. 

"El producto nunca fue clasificación, análisis de sentimiento, redacción ni resumen. El producto era menos decisiones por agente, resultados más rápidos, menor carga cognitiva, operaciones escalables. La IA era el mecanismo, y un mecanismo solo funciona si se aplica al problema adecuado, con datos que realmente respalden la solución."

Si estás pensando dónde encaja la IA en tus operaciones de soporte, habla con nosotros en Hiver. Te mostraremos cómo podemos ayudarte a brindar atención empática.