Agente de soporte de Microsoft: preciso pero poco usado. Contexto, honestidad y salida mejoraron la adopción

Un empleado ya reinició el portátil, borró la caché y preguntó al colega de al lado. Abre el agente de soporte, describe el problema, y la primera sugerencia del agente es reiniciar el portátil. La respuesta es correcta. También es el momento en que ese empleado decide no volver.

La organización de TI de Microsoft describe ese patrón, en sus propias palabras, en un caso de estudio publicado el 8 de octubre. Su Employee Self-Service Agent se lanzó en otoño de 2025 para más de 300.000 empleados y personal contingente. La adopción fue más débil de lo esperado, por lo que Microsoft Digital encargó una investigación de usuarios, realizada por la firma de diseño Designit mediante entrevistas, grupos focales y análisis de flujos de trabajo y feedback en distintas regiones.

Lo que encontró la investigación

Los hallazgos no eran sobre el modelo.

La confianza fue lo primero. “La confianza era un problema importante”, dijo Chaitrasri Rao de Designit. “Las personas se acercaban a un agente de IA de manera muy diferente a como se acercaban al software tradicional”. Los usuarios trataban al agente más como alguien con quien hablaban que como una herramienta, y querían señales de que entendía su situación.

Las personas llegan a mitad del recorrido. La mayoría de los empleados ya habían probado con colegas, documentación, herramientas existentes o sus propias soluciones antes de abrir el agente. La frustración aumentaba cuando sugería lo que ya habían hecho.

El recorrido es la unidad. Los empleados juzgaban toda la experiencia de soporte, no respuestas individuales. Perder el contexto, o que se les pidiera repetir pasos, costaba más buena voluntad que una respuesta imperfecta.

Una salida genera confianza. Los usuarios necesitaban la seguridad de que el agente los pasaría a una persona real si no podía resolver el problema.

Lo que cambió

Microsoft reconstruyó el comportamiento del agente en lugar de su conocimiento. Ahora reconoce la solución de problemas previa, reconoce el contexto del empleado, declara sus limitaciones y explica los siguientes pasos. El equipo escribió guías de personalidad y comportamiento, documentó escenarios de ruptura de confianza y emparejó cada uno con un comportamiento esperado, y estableció pautas para respuestas de baja confianza y para cuando el escalamiento es el mejor resultado. En palabras de un miembro del equipo, el agente original “era demasiado una máquina”.

Microsoft reporta dos resultados: el 50% de los empleados ahora comienzan su recorrido de soporte con el agente, frente al 27% antes de la iniciativa de confianza, y una reducción general del 30% en los tickets de soporte de TI creados. El caso de estudio no indica un período de medición y no separa el efecto del rediseño de otros cambios, por lo que estas son cifras internas de Microsoft, no un resultado controlado.

Las lecciones transferibles

Evalúe recorridos, no respuestas. La mayoría de los conjuntos de evaluación de agentes puntúan una sola pregunta y una sola respuesta. El catálogo de ruptura de confianza de Microsoft es, en efecto, un tipo diferente de suite de pruebas: un escenario (“el usuario dice que ya reinició”) emparejado con un comportamiento requerido. Todo agente de soporte debería probarse de esa manera, incluso lo que hace cuando no tiene confianza.

El escalamiento es una característica, y es trabajo de integración. Las personas usan más un agente cuando saben cómo salir de él. Un traspaso que obliga al empleado a contar de nuevo la historia a una persona anula el beneficio, por lo que el contexto tiene que viajar al sistema de tickets con el caso. Ese trabajo vive en la integración de la gestión de servicios de TI, no en el diseño de prompts.

Elija métricas que muestren comportamiento. La proporción de empleados que comienzan con el agente mide la confianza en la práctica, lo que una puntuación de satisfacción no hace. La reducción de tickets necesita un acompañante, sin embargo: menos tickets también pueden significar que las personas se rindieron. Las tasas de recontacto y el tiempo de resolución distinguen a los dos. Es la misma advertencia que planteamos sobre contar horas ahorradas como valor: el número principal necesita la decisión detrás de él.

Presupueste el trabajo que movió el resultado. La investigación de usuarios, las especificaciones de comportamiento y la integración del traspaso rara vez aparecen en un caso de negocio de IA. El caso de Microsoft sugiere que pueden ser donde se gana o se pierde la adopción. Un agente preciso en el que las personas no confían es un costo sin retorno.