Support by Twitter

Something happened this afternoon that, although unremarkable on its face, wouldn't have worked without a couple of new technologies.

I was monitoring my Twitter stream when I saw that one of our customers was having a problem with the new code issues feature in CodeRush. He'd posted a short tweet (aren't all tweets short?) about all code issues turning into "Complex member (no fixes available)". Sounded weird so I twittered back asking for more details. Unfortunately, at the time, Twitter was going through one of its "slowdowns" — not quite a Fail Whale but close — and so minutes were ticking by.

Although Mark was online, he wasn't physically present, so I asked the customer to record a video of the problem (our IDE productivity tools are designed to reset a invalid mode on a build, for example, so it's imperative to get a look at the problem before anything like that occurs). He didn't have Camtasia, but Rory Becker stepped in, also on Twitter, with the hint that Jing (also by those terribly nice people at TechSmith) is free.

While the customer was recording, I asked him for an IM account that we could talk over. Twitter is just not real-time enough for a series of back and forths that a support session would entail. You're throttled to only 100 updates an hour, plus as I said Twitter was being really slow. We switched to Live Messenger; meanwhile he'd emailed me the screencast and Mark was back. We started up a conference IM and I essentially left them to it.

Very quickly Mark was able to see the problem and understand the reason behind it. In essence, it was a user experience (UX) problem where the "complex member" issue was being prioritized over the other issues. A quick workaround later, and the customer was able to continue with his work.

Now, before you jump all over this and say: this is how support should work, let me point out a couple of things that meant this particular case was successful.

1. I was lucky to see the original tweet. I happened to be following this customer for a start, but I don't read everything from everyone I follow (I have real work to do, you know). I don't have a search for 'DevExpress' or 'CodeRush' active all the time, so I could quite easily have missed this particular tweet.

2. I was lucky to spot the tweet within a couple of minutes. That meant the customer didn't do something like rebuilding, or exiting/restarting Visual Studio and losing the 'mode' he was in, before I jumped in and started asking questions. That's lucky as I say: I usually go for an hour or more before I take a look; it depends on the workload.

3. I'll say it again: Twitter is unreliable for important things. The fact that you had granola for breakfast is unimportant and I could easily miss that tweet without it affecting your (or my) life in the slightest, but a request for support is somewhat more significant for you. You want a reply, dammit, so there had better be someone watching the stream. (Oh, and I prefer muesli so would have ignored your granola tweet, doubled.)

4. I was lucky that Mark was online and ready to help. In other words, I had the world's greatest CodeRush Subject Matter Expert (SME) already at my beck and call. (Well, OK, he happened to be online but ignoring me.) The thing about DevExpress SMEs is that they're usually hard at work designing and implementing the Subject Matter at which they're Expert. They are not support guys. Disturb them, and we lose efficiency. You all know what it's like when you're deep in some programming problem and your manager pops his head round the door and asks "how's it going?" Your concentration is blown and it takes time to get it back. Same for our guys.

5. The customer was willing to take the time and trouble to record a screencast. Not only that, he was willing to take the time and trouble to download the recording software so he could do so. Now, the thing is — I'm going to tread carefully here — a lot of times, customers take the position that their original support ticket description should be good enough to find the source of an issue and then take umbrage when the support person asks for more details, say by including an example program that reproduces the problem or even providing a screencast showing the issue in action. And here we had a customer who was willing to go the extra mile to help us help him.

(I cannot stress this enough, by the way. Yes, I know bugs suck. Yes, I know your time is disrupted when you come across something that doesn't work the way it should. We feel the same way. So help us help you by giving us all the information you can about the issue you run into. Example programs take time to create, sure, but damn if they're not the best thing since sliced bread at nailing what the bug is and how to resolve it and get you the workaround or fix quickly so you're on your way again. I read somewhere that you should treat tech support as if they were a bunch of six-year olds. Not pejoratively, but in the sense that you should explain every little thing in detail so they understand. Don't make assumptions that they'll comprehend through some sort of osmosis or by reading the subtext in your message: they haven't been living and breathing your code like you have.)

6. The issue (and the reason for the issue) was visible in the screencast and Mark was quickly able to write some code that mimicked the problem and thereby work out the workaround. This is an SME win, in a way: I'd looked at the screencast, saw the issue, but had not a clue about what could have produced the problem. Mark had the intuition to grok the kind of code that could produce it, and verified his assumption with an experiment.

As I say, it was a confluence of lucky coincidences that gave the good result in this case. I can quite imagine that in other scenarios it wouldn't have worked out as easily.

Note that there was no logging of the support — when you use the Support Center or email, each item is logged, queued, and handed over to the correct person and you have a guarantee that your issue will get looked at and you'll be notified of its resolution. When you use the Twittered Julian and non-Twittered Mark, you have no such guarantee. We're unreliable but support is not.

Another point to make is that support in this manner is very inefficient and costly for us and for everyone else who is waiting in line. It's great for the person being looked after right this very moment, but for everyone else, meh. You know what it's like to be caught in a phone queue: "all our agents are busy right now, please hold and listen to this tune from an 80s band you've never heard of". Of course, this points to the idea of providing premium support and all I can say about that is that we're not there yet.

So, all in all, an interesting and fairly rewarding experience. but not something we'll make a habit of.

Free DevExpress Products - Get Your Copy Today