Seeking to drive adoption, Microsoft fumbles customer service

Let’s subtitle this post “A tale of two tickets.”

The other day, I got a request from one of my staff: could we please start using Shifts for scheduling his team’s on-call rotations? “Sure,” I said, little realizing what a journey that would entail. To make a long and painful story as short as possible: Shifts didn’t work in our tenant, so I filed a ticket, which took six weeks and multiple escalations before it got to someone who actually realized the problem (it was a back-end provisioning issue) and fixed it.

Six weeks. Hold that thought.

Now, a digression.

It is no big secret that Microsoft is working very, very hard to increase adoption of their cloud services. At their recent Inspire partner conference,  there was a steady drumbeat of adoption-focused messaging directed, loudly, at Microsoft partners, and many Microsoft partner and sales personnel have found that their fiscal year (FY) 2020 compensation is directly tied to increasing adoption. For example, one person I spoke to told me that in FY 2020, the target they were expected to meet was to drive Teams adoption in their target market year-over-year (YoY) up by more than 250%.

Now, really: I get it. Microsoft is selling their “three clouds” (Dynamics 365, Office 365, and Microsoft 365) as hard as they can, but the old phenomenon of “channel stuffing” rears its head when customers buy licenses for those three clouds and don’t use them fully. If you buy a bunch of O365 Enterprise E3 licenses, for example, but only use Exchange Online, Microsoft is worried that you might a) buy less expensive licenses at renewal or b) defect to Gmail. They therefore have a really strong interest in not only selling licenses for these services but ensuring that people actually use what they’ve paid for.

Not only that, if customers don’t use the licenses they already have, it’s darn hard to upsell them more expensive or more capable licenses. This is a major brake on Microsoft 365 adoption: it’s hard to sell people a new SKU for Windows 10 and Office 365 when they already have O365 licenses on a multi-year agreement and perpetual Win10 licenses on their existing devices.

Side note: Azure is of course a Microsoft cloud, and it absolutely has its own, and rather daunting, adoption and consumption targets, but since almost all Azure services are priced based on actual usage, the play in Azure-land is to get people to use more rather than to get more use out of what they’ve already bought. Thus the intense focus on topics such as “digital transformation,” which translates to “getting stuff out of your on-premises data centers and into Azure” and the various Azure security offerings (which translate to “pay us per-minute to do cool security stuff on your Azure-hosted resources.”)

To recap: Microsoft wants customers to use all of the workloads in their O365 or M365 SKUs because doing so helps them keep customers around longer and sell them more stuff. In fairness, customers can benefit too by getting better value (defined as “more productivity” or “better security” or whatever) from their existing investment, but I think Microsoft is mostly interested in this because “customers can benefit” directly turns into “customers give us money.”

With that background, you’d probably think that Microsoft is always looking for new ways to increase user adoption… and you’d be right. That explains the mail I received this morning.

It looked like a support ticket, but I figured it must just be a decent phishing attempt. After all, I didn’t open a ticket, so the “Your request…” language was suspicious. Then I read it and damn near threw my coffee mug at the monitor.

Why?

Think about it. This is Microsoft sending me a “support ambassador” to try to convince me to use more of their services, i.e. to increase adoption, in a test tenant with only 1 paid license… something which only benefits Microsoft.

Meanwhile, users in my production tenant have to wait SIX WEEKS to get an actual problem fixed, one that directly affects their ability to work. Oh, by the way, fixing that problem would drive adoption of the service! We wanted to use Shifts but couldn’t until the problem was fixed– so no need to manufacture a fake support ticket to try to get me engaged.

Apparently there are enough “support ambassadors” roaming around to waste time dunning the admin of a single-user test tenant because “[their] system detected that not all users are using the services included.” Now, of course I realize that the “support ambassadors” here are not really support engineers in the same mold as the people who answer, y’know, actual support requests. What this email really means is that Microsoft is spending money on trying to drive adoption that would be spent better on the actual support organization.

This is part of the same tiring and worrisome trend we’ve seen in Office 365 for years now, where Microsoft does questionable stuff behind their customers’ backs. Here are a few examples:

• Contacting the tenant admin (me in this case) to drive adoption based on data I haven’t seen about what my users were doing– perhaps this would be an unpleasant surprise to admins who don’t realize that user usage data is used for this purpose
• Faking a support ticket as a means to fool customers into thinking they should read the adoption-related propaganda. (I split this one out separately because it irritates me so much.)
• Pushing feedback surveys directly to Teams end users. Here’s some feedback for y’all: don’t talk directly to my organization’s end users without permission. Interestingly, the Teams team has made no public comment on this feature despite the uniformly negative feedback I have heard they’ve received.
• Sticking transport rules into customer’s Exchange Online tenants. (Hear more about that here.)
• Magically generating O365 Group objects from distribution groups and making them appear in the GAL
• Turning on any number of other features by default so that they appear to end users with little or no warning. I do appreciate that the roadmap communications have gotten more detailed, and more frequent, as the service has matured, but since I still don’t know exactly when feature X will hit my tenant, it’s harder to do adoption and change management than it should be.

MVPs have a reputation for giving Microsoft candid and honest feedback, so here it is in two short digestible sound bites.

First, tighten up the support organization so that it doesn’t take multiple weeks to fix any problem. I can migrate a 100,000+ user organization in the amount of time it takes Microsoft to recognize and fix simple provisioning problems.

Second, stop bypassing (or trying to bypass) the tenant admins. Be very, very judicious with which new features are on by default; provide admin controls for new features on day 1 (and not later), and don’t assume that your customers are OK with you interacting directly with their end users.