I want to briefly describe a recent encounter I had with Cisco’s WebEx support. I do this only because this sort of script-based customer service is, while efficient when training new reps, grossly wasteful in situations not covered by the script. And by wasteful, I mean it pointlessly uses up hours of the customer’s time.
So here’s the deal: After months and months of WebEx working flawlessly, the client application started crashing during the meeting setup process. This occurred on all of our users’ workstations.
I knew that between the time it had been working and the time it stopped working I had pushed out no Windows updates and I made no changes to the network (firewalls, IP ranges, NATting, etc.)
I was pretty sure it was a bug in their application, and having no way of fixing that I had the user call WebEx support. After about 30 minutes of no progress and my constantly entering the admin password to re-install WebEx software packages I took over the call.
The first thing I asked the rep: Have you recently pushed out any software updates?
His response: Absolutely not.
I didn’t look at the release notes until later, but it appears that he was lying or ignorant of this fact. Either way that’s a scary prospect, because looking at the notes they made a lot of changes in this release.
I should note that our conversation occurred on October 2, and the release is dated September 12. They must have issued a minor release during that time, as the release notes are for version 1.3.9 and the current version of the software is 1.3.9.0.8.
The rep then went on to insist that we must have made some kind of “network” change that caused the client to stop working.
He took control of the computer, and spent a great amount of time changing browser/internet settings in both Chrome and Windows. He insisted that it was a browser problem, and that the WebEx add-in was crashing or “being blocked”.
I asked: It looks to me like the application is running outside the browser, so why would it be a browser issue?
He insisted that the application was running in the context of the browser and that it was the browser settings causing the trouble. With me entering the admin password when prompted, he proceeded to weaken the security settings of the browsers to near-nothingness.
Even if that had worked, making my workstations less secure is not a viable solution. Nor would it be in any corporate environment.
He disabled our antivirus program and Windows Firewall. All of this was to no avail.
But all this faff over the browsers was completely tangential and pointless because the app would crash at the same point when starting a meeting in the WebEx Productivity Tools. This is done without the use of any browser.
So over an hour of our time was wasted trying to “fix” various web browsers when it was provably not a web browser issue.
Then the rep asked me to log him into the local administrator account. I did, and he was able to create a meeting without the application crashing.
HE THEN INSISTED THAT IT WAS A NETWORK ISSUE.
Not a permission issue, not a profile issue, not a bug in their application, but A NETWORK ISSUE.
At first I thought that he was perhaps confusing “Active Directory” with “the network”, but no. He directed me to a WebEx knowledgebase article about opening various outbound ports on a firewall.
We have never restricted outbound firewall ports, and more importantly if it were a network issue then the application would still crash when logged in as an administrator.
Also, I find it hard to believe that their application would crash due to a lack of connectivity. (And by “crash” I mean full-out “send error report” style crashing.) If it were a network connectivity issue then the app would likely give an appropriate error.
The worst part is that I can guess as to what’s going on:
The app probably has a bug wherein it tries to modify something to which it doesn’t have permission (a registry key, a file, Windows Firewall settings — whatever) in such a way that Windows does not ask the user for appropriate (e.g. admin) credentials, and then the app crashes rather than handling the permission exception properly.
Obviously that’s just my 2c, but it seems likely based on what I observed.
To summarize, here’s what really aggravated me about this encounter:
- The support rep claimed that there were no recent changes to their software, despite there having been a release with significant changes less than 3 weeks prior.
- The support rep insisted that we had made changes to “the network” despite that fact that I told him unequivocally that I had not, and that I’m the only person that would have the ability to do so.
- The support rep’s ultimate diagnosis of the situation was that our network was at fault, despite blindingly obvious evidence to the contrary.
All in all Cisco wasted about 2 hours of my and my user’s time.
Today we gave their support another try. Despite a different rep doing much the same as the first rep there was no progress. Their rep promised to call us back “between 12:00 and 12:30 EST”.
It’s now 13:50 and we’ve received no call back. I’ve also now missed lunch waiting for this phantom call.
The rep said that he leaves work at 14:00 EST, and I’m not very optimistic about getting a call from him in the next 10 minutes.
Update (2014-10-11):
Needless to say, I never did receive that call back.
Another amusing-slash-irritating find on the WebEx site: They apparently did not get the message about all the post-2000-era TLDs.
There’s a big difference between a fake email and an invalid email. I’m assuming that there’s no lumpy.bacca@hoth.guru, but it is plausible.
Yet good ol’ Cisco doesn’t believe in .guru, nor do they believe in a number of other perfectly valid (though stupid) TLDs. I guess that’s fine, because giving them a fake .com email is just as easy as giving them a fake .museum. (Speaking of which, don’t forget to submit a really, really improbable fake email. Poor john.smith@gmail.com must be sick of getting all those notifications!)
