Early in 2015 a small group of people at Support.com decided to see firsthand how the home automation segment of the Internet of Things was being supported. You can read all the details here, but let me give you a brief overview of the basic findings.
I’ll start with a really brief overview: It was an abysmal experience.
Now that we’ve got that out of the way…
In our report, “New Rules for a New World: Five Support Imperatives That Can Save the Internet of Things,” we laid out our vision of how support has to change to accommodate an interconnected world. If our admittedly unscientific experiment is any indication, we’ve got a long way to go. Here are the five imperatives and how our experience stacked up against them.
1. Provide support throughout the customer’s entire experience of the product.
We had to ask for it, but the vendors were indeed willing to provide support whenever we asked. However, it was always on an exception basis, and generally violated the core premise of our report, which was that we need to stop thinking only about fixing stuff that’s broken and start thinking about how to help people get value out of their technology. Everyone was professional and helpful, but their only goal was to fix whatever the immediate issue was and end the call. At no point in the process did anyone ask a question about how we intended to use the products, offer to point out helpful features, check up on how we were doing, ask if we were satisfied, or even find out if we were actually using the stuff.
2. Design the product with support in mind.
The basic design presumption seemed to be that nothing was going to go wrong. Certainly no one seems to have anticipated any problems other than, “Your Internet connection isn’t working” or “You forgot to plug it in.” There was no built-in troubleshooting, even for fundamental things anytime connectivity is involved, and even though the hub and devices were PC-accessible, no software or guides were provided to check anything.
3. Make support a natural part of the process, not a separate experience.
There was nothing “natural” about the support that was provided. That’s true almost by definition whenever support is limited to “break/fix.” Each encounter was an exception process that essentially involved an admission of failure, either of the gear or the user, and the best possible outcome was not a happier customer or more useful product adoption, but just an elimination of a problem that shouldn’t have been there in the first place. In other words, you spend a lot of time and energy to wind up no better off.
4. Provide contextual guided assistance to both support personnel and end-users.
Not even close. Nobody asked who we were and they had no way to know if we’d called before. Every encounter started from scratch, with the users (us) having to recount (endlessly) everything that had gone on during the previous support encounters, including the basics of the technical configuration that even a dime-store CRM could have logged.
5. Gather data aggressively and optimize continually.
As far as we could tell, nobody gathered any data at all. The write-up referenced above describes how only the last (and most experienced) in a string of tech support agents really knew how to solve the problem. It’s a safe assumption that we weren’t the first ones to encounter it, so the way this last agent solved it was never distributed to any of his colleagues by support center management. If they did gather any information about these support encounters, it was all anonymous, since nobody ever tried to identify us for future reference. Only the first agent we called was following any kind of procedure, so it’s possible she was logging suggestions and outcomes, but probably not. Even if she had been, what kind of useful insight do you gain by asking the customer to try the same solution half a dozen times?
If you read the detailed write-up, you’ll get a better feel for what a frustrating and time-consuming experience it was. My colleague who lived through it swears he wouldn’t buy a fire extinguisher from that company if his shoes were on fire.
The most exasperating part of it as far as I’m concerned? Nexus could have solved half of those problems.
The company is now #1 on our prospect list.