Bad Support Bots
mike at mtcc.com
Fri Jan 15 18:14:54 UTC 2010
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
>> 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
> 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.
More information about the NANOG