I had a really good experience with Microsoft support today. What made it kind of special is that we almost had a bet with a colleague who had not such a pleasant experience a couple of months back. Anyhow, in my case we got the issue resolved in less than one hour. In his case, it took a month, and it was not, eventually, resolved. So, yes, I sort of won..
However, what if I said that your experience with Microsoft support(and, probably, with any other “support”) depends on you just as much as it depends on the individual support engineer and on the support process in general?
You might say that some tickets stay open for a long time, they don’t get resolved to your satisfaction, bugs are not getting fixed as fast as you’d like, and so on. So, basically, the experience is not as pleasant as you would expect.
That is exactly what I mean, though..
Let me explain.
To start with, even though I usually say that I have .NET development background, there also were 3-4 years in my life when I was essentially working as a support team lead. Those who still remember AVIcode probably remember those times. In my case, I was in a very comfortable support environment since, to some extent, I was still a member of the dev team. Which means I had full access to the source code, I would, occasionally, manage delivery and deployment of hotfix builds, and I could actually go talk to the upper management any time I wanted to. That gives a lot of flexibility and power to resolve client issues quickly.
Historically, there is a model where support is provided on different levels. The efficiency (and the cost) of support resources is lowest on Level 1. Resources are getting more expensive (but, also, more efficient) on Level 2. It goes even further on Level 3.
Apparently, the thinking is that every support request should go through a bit of a process. If Level 1 can’t handle it, Level 2 will try. If Level 2 can’t, Level 3 will get engaged. If Level 3 can’t, the product team may have to be involved.
Depending on the efficiency of the support process, there could be triggers in this process which will allow a ticket to bypass level 1, for example, and go directly to level 2. And so on.
Here is what I’m talking about:
Is it necessarily how all support is done? No, but it is safe to say that, especially for the more complex issues, you won’t, usually, get your ticket assigned directly to the “most-experience know-it-all” team member who can solve your problem on the spot. This process may take some time.
Now, imagine a typical support engineer (without the superpowers of the dev team member). There are a few things you may have to keep in mind:
- They don’t have the authority to make any changes in the product
- They don’t have the authority promise any fixes unless approved by the dev team
- They don’t always have the time, ability, or even the opportunity to review product source code in the hope to understand what’s going on behind the scene
- They have no idea what’s going on in your environment, so they have to understand not only what’s happening to the product, but, also, what is it that’s so special about your environment
- And sometimes it can be a problem between the keyboard and the chair.. so it can be you or your users
There is a lot to consider, there are lots of different factors, so this can all get really complicated and time-consuming.
But there are a few things that can turn possibly frustrating experience into something much more civilized. And it’s really about the expectations which you have to set for yourself.
If you have not done any research, if you have not provided concise and clear explanation of your problem (which is not just clear for you, but, also, clear for somebody who has no clue about the context in which the problem is happening), and if you expect the problem to be resolved right away.. That’s just wrong expectations, so you need to either be ready for a lot of questions OR you need to start preparing your ticket descriptions better. Basically, it’s extra work in either case.
Once you’ve done the above, there is another piece of this puzzle that you may need to consider to come up with the right expectations. What are you really asking about? Is it about some error that’s happening in a certain situation which is easy to reproduce? Or is it a conceptual question which likely does not have an immediate answer and may involve some back and forth between the support engineer and the product team, possibly with the management, etc? It’s much more likely that you will have the problem resolved quickly in the first scenario.
And, finally, there are always product limitations, and there are always bugs. The trick is that those issues can’t be resolved strictly on the support side – you might feel extremely disappointed that there is a bug; however, even though it’s expected that a support engineer will identify something as a bug, but it’s not expected at all that they will have a fix (or even a workaround) available right away.
To that point, if you, like me, tend to ask Microsoft support to contact you by email rather than by phone.. you are actually complicating the process since you are slowing down communications.
Anyway, what is it I had a problem with today?
There was an import job that was stuck in the “submitted” state. In the on-prem environments, where I used to work for almost 8 years, this would normally be an indication of some issues with the Async Service. So, even though it was online this time, I opened a support ticket and mentioned that my import jobs are stuck in the “submitted” state, so, maybe, support could do something with the async service. And identified it as a critical issue.
15 minutes later, our imports were up and running, even though we spent 15 more minutes in the screensharing session just double-checking things.
And I certainly learned something. Which is, if you are looking at the import file and you see “Cancelled” status reason under the System Jobs, it could be that your instance is still in the Admin mode:
Import jobs won’t be working in that mode.
What was that other question that took more than a month to answer? That was a conceptual one – whether a certain product follows a certain standard. Problem is, if there is no immediate and clear answer, it’s not up to the support engineers to answer such questions, so it goes to the product team, to the marketing, to the sales.. you name it.
So, a really long story short, when opening a support ticket, don’t just expect an immediate resolution all the time – think of what is actually possible, try to provide helpful details where you can, and, sometimes, maybe don’t even send those questions through the support channel if it’s really a conceptual question.
And, by the way, somebody else asked me after that what is the best place to open support tickets for Dynamics/PowerApps. Personally, I find it works best from the new admin center, which is at https://admin.powerplatform.microsoft.com/ :
Although, I think it’s still possible to open support request from the office admin center, but, even there, you might see a message like this:
Anyway, have fun, possibly don’t run into any issues that require support, but, if you do, be conscious of what to expect.