nanog mailing list archives

Re: Bad Support Bots


From: Michael Thomas <mike () mtcc com>
Date: Fri, 15 Jan 2010 10:14:54 -0800

William Hamilton wrote:
On 15/01/2010 16:57, Michael Thomas wrote:

The difference is that nobody wants to "talk" to a robot when they're
the victim
of a false positive which is causing business impacting interruption. A
robot is not
empowered to go beyond its instructions, and if it's programmed either
wrong or with
inadequate nuance, there is no escalation.

Sure, and that's understandable.

Let's not forget that IVR mazes and their modern day counterparts have
been built in
large part not to resolve problems but to reduce the cost of "support"
by expensive human
automatons to the point that it's often incidental if they actually
solve problems. This is not
a well kept secret, and when you're trapped by one especially when it's
produced a crisis,
its rather disingenuous and maddening for the IVR's keeper to cop attitude.

A much better approach -- assuming that the goal is actually to resolve
problems rather than
shield resources -- is to at least make the escalation process
transparent. Knowing what you
have to do in order to get ahold of some of something empowered to
resolve problems is a
lot better than a robot telling you to take the next turn in a twisty maze.

I agree it's perhaps not clear how to get hold of a human, but you can't really argue that it's not clear how to progress the issue in general as the message quite clearly tells you to respond if you wish for it to be re-opened.

I can't accept that the instructions that the bot provided were unclear, but can organisations in general (again, not SORBS-specific) do better when dealing with their "customers"?

Here's the general problem I have. As "customers", we've gone from the expectation that support was there to support us, to the general presumption that the "customers" are the problem and need to take Turing Tests, and jump through all manner of hoops in order to be deigned worthy of help. That's great if your base motivation is to reduce the bottom line of support costs, but lets not equivocate that the experience isn't on average far, far worse for those on the receiving end of these systems.

In this particular case, it isn't whether the instructions aren't clear per se. It's that there isn't any recourse if for whatever reason they are not. Badgering the "customers" who don't understand your process is either cynical or clueless. If your customers don't understand, that's your problem. Always. Assuming
that support is there to support, of course.

So in general, it's this new age attitude of "you must conform to my cost targets" toward support that sucks.

Mike


Current thread: