Microsoft's support agent was accurate and still underused. Context, honesty and a way out fixed adoption

An employee has already restarted the laptop, cleared the cache and asked the colleague at the next desk. They open the support agent, describe the problem, and the agent’s first suggestion is to restart the laptop. The answer is correct. It is also the moment that employee decides not to come back.

Microsoft’s IT organization describes that pattern, in its own words, in a case study published on October 8. Its Employee Self-Service Agent launched in fall 2025 to more than 300,000 employees and contingent staff. Adoption was weaker than expected, so Microsoft Digital commissioned user research, run by the design firm Designit through interviews, focus groups and analysis of workflows and feedback across regions.

What the research found

The findings were not about the model.

Trust came first. “Trust was a major issue,” said Designit’s Chaitrasri Rao. “People approached an AI agent very differently than the way they approached traditional software.” Users treated the agent more as someone they were talking to than as a tool, and wanted signs that it understood their situation.

People arrive mid-journey. Most employees had already tried coworkers, documentation, existing tools or their own fixes before opening the agent. Frustration rose when it suggested what they had already done.

The journey is the unit. Employees judged the whole support experience, not individual answers. Losing context, or being asked to retrace steps, cost more goodwill than an imperfect reply.

A way out builds confidence. Users needed assurance that the agent would hand them to a live person if it could not solve the problem.

What changed

Microsoft rebuilt the agent’s behavior rather than its knowledge. It now acknowledges prior troubleshooting, recognizes the employee’s context, states its limitations and explains next steps. The team wrote personality and behavior guidelines, documented trust-breakdown scenarios and paired each with an expected behavior, and set guidance for low-confidence answers and for when escalation is the better outcome. In the words of one team member, the original agent “was too much of a machine”.

Microsoft reports two results: 50% of employees now begin their support journey with the agent, up from 27% before the trust initiative, and a 30% overall reduction in IT support tickets created. The case study gives no measurement period and does not separate the effect of the redesign from other changes, so these are Microsoft’s internal figures, not a controlled result.

The transferable lessons

Evaluate journeys, not answers. Most agent evaluation sets score a single question and a single reply. Microsoft’s trust-breakdown catalog is, in effect, a different kind of test suite: a scenario (“the user says they already rebooted”) paired with a required behavior. Every support agent should be tested that way, including what it does when it is not confident.

Escalation is a feature, and it is integration work. People use an agent more when they know how to leave it. A handoff that forces the employee to retell the story to a human undoes the benefit, so the context has to travel into the ticketing system with the case. That work lives in IT service management integration, not in prompt design.

Choose metrics that show behavior. The share of employees who start with the agent measures trust in practice, which a satisfaction score does not. Ticket reduction needs a companion, though: fewer tickets can also mean people gave up. Re-contact rates and time to resolution tell the two apart. It is the same caution we raised about counting hours saved as value: the headline number needs the decision behind it.

Budget for the work that moved the result. User research, behavior specifications and handoff integration rarely appear in an AI business case. Microsoft’s case suggests they may be where adoption is won or lost. An accurate agent that people do not trust is a cost with no return.