The problem: Creating Efficiency for Engineering and Frustration for the user

Microsoft’s Partner Center is the portal used by companies to manage and grow their product-based relationship with Microsoft. Since its inception, it has largely been a consolidation of other existing portals. A key business reason for this type of consolidation is to share services like account settings, pay in/out, and support across the varying programs.

With this project, the product team’s goal was to increase engineering efficiency by unifying the support experience. Upon closer inspection, there was an opportunity to inexpensively increase user satisfaction and reduce business costs as a part of the original workstream.

The initial plan introduced the wrong kind of friction into the process of filing a support ticket. It would take the user six steps and multiple substeps to find a topic and product to complete the process. I say the wrong type of friction, because diverting users to support documentation in lieu of filing a ticket causes friction, but potentially reduces the time and effort expended by the user and support staff.

a simple plan: why not make it…good?

In order to do this, I proposed a simplified search experience. Integrating “smart” search functionality would be a costly implementation, but searching through product name, solution area, and help topic title is comparable to using Ctrl+F (or Cmd+F, Mac users) to search a flattened list of topics. This saves the user time from having to self-identify or guess the correct product and solution areas for their topic. This is an evolution in thinking from my last time working on support for Xbox. Even the most sensical Information Architecture is going to be more difficult to maneuver than search, especially given the sheer amount of content created by the multiple site mergers.

The next step is to introduce the aforementioned “good friction” of offering users the choice of exploring potentially related documentation before filing a ticket. Because of the number of steps in the original process, the new flow, with its attempts at deflection is still fewer steps. I’m not an ardent defender of fewer clicks always being the best sign of efficiency, but in this case fewer steps resulted in more clarity.

Impressive results

While building out the project’s hypothesis, I knew we’d see a reduction is support calls, but I was not prepared for how well that was validated. In the first three months the new experience was available to users, we saw a 17% reduction in support tickets. This is hundreds fewer calls monthly, empowering users to unblock themselves and enabling support agents to prioritize larger issues.