O agente de suporte da Microsoft acertava e era pouco usado. Contexto, franqueza e uma saída mudaram a adoção

Um funcionário já reiniciou o laptop, limpou o cache e perguntou ao colega da mesa ao lado. Ele abre o agente de suporte, descreve o problema, e a primeira sugestão do agente é reiniciar o laptop. A resposta está correta. É também o momento em que esse funcionário decide não voltar mais.

A organização de TI da Microsoft descreve esse padrão, em suas próprias palavras, em um estudo de caso publicado em 8 de outubro. Seu Employee Self-Service Agent foi lançado no segundo semestre de 2025 para mais de 300.000 funcionários e equipes contingentes. A adoção foi mais fraca do que o esperado, então a Microsoft Digital encomendou uma pesquisa com usuários, conduzida pela empresa de design Designit por meio de entrevistas, grupos de foco e análise de workflows e feedback em várias regiões.

O que a pesquisa descobriu

As descobertas não eram sobre o modelo.

A confiança veio primeiro. “A confiança era uma questão importante”, disse Chaitrasri Rao, da Designit. “As pessoas abordavam um agente de IA de maneira muito diferente de como abordavam softwares tradicionais.” Os usuários tratavam o agente mais como alguém com quem conversavam do que como uma ferramenta, e queriam sinais de que ele entendia sua situação.

As pessoas chegam no meio da jornada. A maioria dos funcionários já havia tentado colegas, documentação, ferramentas existentes ou suas próprias soluções antes de abrir o agente. A frustração aumentava quando ele sugeria o que eles já tinham feito.

A jornada é a unidade. Os funcionários julgavam toda a experiência de suporte, não respostas individuais. Perder contexto, ou ser solicitado a refazer etapas, custava mais boa vontade do que uma resposta imperfeita.

Uma saída constrói confiança. Os usuários precisavam de garantia de que o agente os encaminharia para uma pessoa real se não conseguisse resolver o problema.

O que mudou

A Microsoft reconstruiu o comportamento do agente, não o seu conhecimento. Agora ele reconhece a solução de problemas anterior, reconhece o contexto do funcionário, declara suas limitações e explica os próximos passos. A equipe escreveu diretrizes de personalidade e comportamento, documentou cenários de quebra de confiança e os combinou com um comportamento esperado, e definiu orientações para respostas de baixa confiança e para quando o escalonamento é o melhor resultado. Nas palavras de um membro da equipe, o agente original “era muito máquina”.

A Microsoft relata dois resultados: 50% dos funcionários agora começam sua jornada de suporte com o agente, ante 27% antes da iniciativa de confiança, e uma redução geral de 30% nos chamados de suporte de TI criados. O estudo de caso não fornece um período de medição e não separa o efeito do redesign de outras mudanças, então esses são números internos da Microsoft, não um resultado controlado.

As lições transferíveis

Avalie jornadas, não respostas. A maioria dos conjuntos de avaliação de agentes pontua uma única pergunta e uma única resposta. O catálogo de quebra de confiança da Microsoft é, na prática, um tipo diferente de suíte de testes: um cenário (“o usuário diz que já reiniciou”) combinado com um comportamento exigido. Todo agente de suporte deveria ser testado dessa forma, incluindo o que ele faz quando não está confiante.

O escalonamento é uma funcionalidade, e é trabalho de integração. As pessoas usam mais um agente quando sabem como sair dele. Um handoff que obriga o funcionário a recontar a história para um humano anula o benefício, então o contexto precisa viajar para o sistema de tickets junto com o caso. Esse trabalho está na integração de gestão de serviços de TI, não no design de prompt.

Escolha métricas que mostrem comportamento. A porcentagem de funcionários que começam com o agente mede a confiança na prática, o que uma pontuação de satisfação não faz. A redução de chamados precisa de um acompanhante, porém: menos chamados também pode significar que as pessoas desistiram. Taxas de recontato e tempo de resolução distinguem os dois casos. É a mesma cautela que levantamos sobre contar horas economizadas como valor: o número principal precisa da decisão por trás dele.

Orce pelo trabalho que moveu o resultado. Pesquisa com usuários, especificações de comportamento e integração de handoff raramente aparecem em um business case de IA. O caso da Microsoft sugere que pode ser aí que a adoção é ganha ou perdida. Um agente preciso em que as pessoas não confiam é um custo sem retorno.