3rd Party: A Microsoft Support Show – How DSEs Accelerate Microsoft Support Services (ep6).

That’s a good question. As the enterprise architect manager, my team looked at offerings that have been around for a while from various organizations, and we came up with the DSE in the “DSE” for a “designated support engineer.” They’re enterprise architects, but they’re doing a support engineer role—basically a white glove treatment for our customers. One of our goals is to build a relationship with the customer.

That’s important to us because, for example, you’ve had the experience where you call your mobile provider, and you get support, and you get whoever you get. Sometimes they’re good, but sometimes you have to explain your situation over and over again. And if you call back the next day, guess what? You talk to another person. You’ve got to start that whole story all over again.

We didn’t want to give that experience to our customers if we could get around that. How do we do that? We become part of their organization. That’s what the DSE role is: they own that technology for their customer and know everything about it.

Part of that ownership is to place internal notes on tickets so that when engineers open up a break/fix ticket with a severity level of one, two, three, or four, it is clear that we’ve got a DSE who is intimate with that technology and who knows all about it so they can probably skip a lot of that introductory prep work. That could include questions like, “What’s the background look like? What’s the what’s the historical context? What’s going on in the environment that might have led to this?”

That’s nice for our engineers to rely on this ownership to bridge those gaps and lend a helping hand because sometimes they might be very intimate with technology and might have additional ideas. That’s pure reactive services being supported by proactive services: learning from another expert who has already learned that environment and preventing customers from having to tell their story over and over again.

The other main goal that we have is related to the reality that, right now, technology is so converged. I’m so glad that Microsoft doesn’t make freeways because there’s no lanes—all the cars would crash. With all these “cars” crashing, if you have technologists who know SQL, issues with that system might cross over into Intune, and those might cross over into Azure or M365. After that, the problem gets all melted together. In other words, 80% of the issue, technology, upgrade, or proactive service being addressed might be SQL. The other 20% could be anything else.

For US Coud it is commonplace, but for other organizations—and I’ve been in consulting for 40 years—it is not very common. And what’s really nice is, like I said, we merge the reactive and proactive services together to provide our customers with a complete offering. We also will bring in other technologists if customers need them to resolve that other 20% of their Microsoft issue. That could include SQL, SharePoint, Power BI, or whatever needs to happen to resolve those tickets. We do it all.

We just had one last week. The CEO of a very large corporation in the Fortune 100—probably a lower number than 100—was in a Teams meeting giving a presentation. There were 80 or more people on the call, all C-level executives. However, our client got kicked out of the meeting while they were presenting. So that’s not a great optic; that means somebody in the Teams meeting had the ability to kick the presenter out.

This was a misconfiguration in the organization, and it was because of the timing and the message that was going out to this organization at the time, so the CEO was kicked out of the Teams meeting—and it didn’t look very good.

They therefore opened a Sev. 1 case. They had a DSE around Teams. So, the team’s DSE was notified by the break/fix side because of that internal note that said, “Hey Rob, is our DSE on this technology. You might want to reach out to him.”

He hopped on the call and within the first half hour, he analyzed the situation, figured out exactly what went wrong, and helped them implement a policy to prevent this from happening again in the future. Now, there’s no reason that anybody else should be able to kick the CEO off a call when they’re presenting.

That whole process went very fast because of the level of complexity in the environment, the nature of the issue, and the participants in fixing the issue.

The client also decided they wanted to have Microsoft take a look at this issue, too.

Microsoft came back within ten minutes of looking at our analysis (which was already done), our project plan, and how to proceed with the resolution, and experts directly from Microsoft said, “We wouldn’t do anything different. This is exactly how to handle this.”

We were able to handle that issue in a very timely fashion, get the client back on the call, resolve the whole issue, and then make sure it didn’t happen again in the future. This agile response and resolution would not have been possible without our DSE’s dedication.

Yes—this happens daily, so it’s not a rare occurrence! There’s a lot of data gathering when a ticket comes in and an engineer first gets on the phone with a client. They’ll ask questions like, “I need to know your story. Why are you calling me? What’s going on? What does the environment look like? How many users are impacted? They will go through that whole process.

What happens is, again, because of that internal note, a DSE is called and they can give the tech some background. A lot of times it really helps narrow down the troubleshooting, shortening the time it takes for a ticket to begin the resolution process.

That’s like a situation wherein you and I are new to a conversation, but we’re planning for our families to spend some time together. I don’t know how many kids you have, and I don’t know what we’re going to do together—but I do still have to ask you those types of questions.

Well, let’s say I already know from a friend who’s known you for longer that you don’t have a girl, so I don’t need to ask you questions related to what daughters like to do. I just cut the question tree in half to help us decide how we’re going to get a playdate going for the kids.

I don’t need to ask you a whole bunch of silly questions, then, such as how old your daughter is or what she likes to do. That long-term friend of yours is like a DSE for a client: an expert who knows more about the client’s digital context and IT infrastructure and can support newcomers to the conversation about how to help the client succeed.

Let’s say that long-term friend of yours (the DSE in this scenario) has told me that you have a 12-year-old son who loves baseball. When I enter the conversation with you, we’re already narrowing down those questions down again. That way, I can eliminate even more talk about whether your son likes soccer or baseball. I can get straight to what he needs.

All those things are what I can get from the DSE, and we can just go right to the conversation as to what do they really need? Do they need a coach to help them bring up their RBIs for batting? If that’s true, then I won’t bring the batting tee to the playdate because he won’t even need it.

Thanks to the DSE, we get right to the core of the problem instead of having an entire conversation restricted to your background. While the backstory is great, it does not resolve the task at hand. Because DSEs have the intimate knowledge of the environment, they can help the break/fix team eliminate a bunch of things.

If you’ve ever done troubleshooting, you know experts need to spend a lot of time narrowing an issue down to find the solution. The DSE helps us narrow that down a lot quicker.

How Microsoft does their escalation support today includes using multiple organizations, and because of privacy acts, they are frequently not allowed to share that information.

If support employee completes a shift and it’s now 5:00, for example, they might end up sending that escalation ticket to another vendor who can’t get some of the data from the first vendor because of privacy issues, because none of them are Microsoft employees.

They’re all “V-Dash,” which stands for “vendor” and provides those employees with only vendor-level access to the ticket.

All of our employees are US Cloud, so the process on our end is pretty simple. When you open a ticket through US Cloud, you’re going to talk to a DSE or talk to a break/fix person.

And they’re all going to be able to talk to each other and share data in a secure fashion that’s encrypted and endpoint-to-endpoint. Our techs are able to communicate openly and freely.

And then if we need to bring somebody in to support the resolution of the ticket, then they can bring in an expert who’s at an enterprise architect level and who can look at the global picture to put the pieces together. Sometimes it’s very complex and it takes multiple sets of eyes from different disciplines to merge to get a solution. Break/fix tickets are almost never clear-cut anymore—it’s multiple technologies and issues. We have the capability to bring those teams in.

Other escalations take a lot of time with other vendors because they can’t bring in those disciplines. They’re kind of pigeonholed and siloed. The SQL person will do their part, then pass the ticket on to the SharePoint person, who will do their little part and pass it on to the Power BI person, and so on.

Meanwhile, the clock has been ticking and there’s still an issue, right? Things are not getting resolved. It is very frustrating. It’s not a great experience, and it is very difficult for engineers to keep track of when to switch. They have to ask themselves, “When do I go from the SQL to the SharePoint to the Power BI? When are we done?”

And then there’s a lot of finger-pointing (unintentionally, but there’s still finger pointing) at who probably dropped the ball. And they do use the word “probably,” which is not great for resolution and problem-solving when you’re dealing with break/fix tickets.

If I’m the client, I want definite responses. I want an answer, and I want to get up and running.

So we hit on three different areas. One of them is project advisory. Customers can come to us with questions about their Microsoft products and get expert help. Questions could be about anything they want professional advice for, like a new button that just happened in the interface, or a new mandate that Microsoft has done and says they’re going to sunset something, or something that has to be upgraded within a certain timeframe.

We don’t own the cloud, we just rent it. So because we rent it, the “landlord” can at any time say, for example, “I’m going to paint the walls purple next week. You need to be ready.”

And we’re like, “I’m not ready! I still have paintings on the wall, so I can’t make it purple.” So clients come to us and ask, “Do I need to worry about this? When they make it purple, is that going to affect me? What’s going to happen?”

That’s what we call a project advisory ticket. Customers might have the need to just bounce some questions back and forth, or maybe they have a plan. We can step up and help them prepare: “Here’s what we’re going to do. We’re going to remove the nails, put some spackle up. And then Microsoft can come in and paint it purple.”

But how do we  prepare for that? Did we miss anything? For example, if there’s no tarp for the floor when they paint, the wall is going to be purple, but some of the floor is going to be purple too, because there’s going to be some spillage and some dripping. Those are the types of processes that we help them with through a project advisory.

The next thing that we do in the consulting services is a full-blown project deployment. Now we consider a project anything that takes over 15 hours or more to solve. So it might be that we’re upgrading 300 servers. It might be that we’re going to do some migrations or a merger and acquisition, and we’re doing the actual merger part and changing email addresses and moving data and things back and forth.

For those projects that 15 hours and above can go into the thousands. It really depends on how big of an organization they are and how much help they need from US Cloud.

With projects, we are allowed to work hands-on for full support. We don’t do staff logs, we do consulting logs.

We have intelligent professionals who can help run a process because a lot of times you run out of time. When you’ve told your manager, “We’re going to have that done by Friday,” and you’re not going to have it done by Friday because you don’t have the time or the professionals who can do it. You need more hands because it takes a village sometimes to do some of these projects because they’re big. We’ve got technology consultants and enterprise architects who can step up and do that.

They can literally do the hands on and work for your team. And the reason why I say it’s consulting log is because, you know, we do a lot of testing and pilots and everything, but sometimes there’s a curveball. We know there’s something different in the account or there’s something going on in the organization that no one’s addressed until we start running a new process. We can then pivot and solve those on the fly.

The last thing that our consulting service does is DSE, like we’ve already mentioned. So the DSE is our third offering that we have that gives the white glove family experience to the organization to really become embedded as part of an extension of the team, which is nice for customers.