Opening a support ticket with Microsoft (or: how not to support your customers)

I had to open a support ticket with Microsoft today: I found a bug in the TCP/IP stack of Windows Embedded Compact 7 that I wanted them to know about (and to fix). I also wanted to know when it would be fixed — after all, the bug is critical and the company I work for is a Microsoft Gold partner, so I had a reasonably high expectation of service.

Suffice it to say I was disappointed.

Reporting a bug should be easy: bugs provide the most valuable kind of feed-back about your software in that it tells you that it went wrong, that it is being used and that someone cares enough about it going wrong to tell you about it. As a rule of thumb, you should assume that for each bug report you get, there are at least seven bug reports that you don’t get. In Microsoft’s case, I would expect this latter number to be higher rather than lower.

Reporting a bug should be a two-step process: click an appropriate link, fill in a form. In the case of Microsoft’s system, it is rather more complicated. Here are the steps I went through:

  1. click the appropriate link
  2. be sent on a wild goose chase to find a PID that doesn’t exist with my type of license — “charges may apply” being the motivator (why would charges every apply to report a bug?)
  3. give up on that and choose the option that says charges may apply — now be presented with a choice of the “standard of care”
  4. take a guess
  5. be presented with a form to fill in two IDs; try the partner ID (twice) — doesn’t work — click on “chat”
  6. wait to be connected…
  7. the representative presents me with a “greeting” of sorts to tell me what she can and cannot do — which is good — I present her with my problem
  8. get sent to a link that doesn’t answer the question
  9. tell her it doesn’t answer the question
  10. get told it does
  11. explain why it doesn’t
  12. well.. if I insist…
  13. get the info to get through the form I was on
  14. now I get to fill in the data

The whole experience, including several waits during the chat because the representative was apparently doing other things as well, took over 45 minutes (closer to an hour). A similar issue with KDE a few months ago took all of five minutes, and I’m still receiving feedback for that issue.

Again, bug reports are important assets you get from your customers for free. You should not:

  • threaten to make them pay for helping your
  • make them wait unnecessarily
  • send them where they won’t be able to report the bug
  • make it difficult to get feedback on the bug report

You should:

  • thank them (profusely) for helping you
  • make the experience as simple as a walk in the park (in spring — without the four-foot layer of snow now obstructing the passage)
  • make it quick
  • provide feedback, quickly, friendly, …

About rlc

Software Analyst in embedded systems and C++, C and VHDL developer, I specialize in security, communications protocols and time synchronization, and am interested in concurrency, generic meta-programming and functional programming and their practical applications. I take a pragmatic approach to project management, focusing on the management of risk and scope. I have over two decades of experience as a software professional and a background in science.
This entry was posted in Opinions and tagged , . Bookmark the permalink.