Error Proofing a Voice Prompt System
The other day, I had a DirecTV service tech coming to the house to make a repair (their customer service has been FAR better than my recent experiences with Verizon, I’m happy to say).
I received a “robo-call” the day before, confirming my appointment. All systems are a go, but I think I discovered a chance to error proof their process a bit…
I answered the call on my iPhone and was told, “If everything is working and you want to cancel the appointment, press 1. If you want to keep the appointment, press 2.”
I pressed “2”. I think. Actually, I got a confirmation that I did re-confirm my appointment.
When this happens, I’m sure it creates a lot of re-work and extra phone calls to DirecTV (adding cost). And, the customer might have their service delayed if you lose your place in the queue.
My unsolicited advice to DirecTV would be to have the keys be “1” to cancel and “9” to confirm.
With the extra spacing, customers would be less likely to press the wrong key. I’d bet the cost in terms of changing the phone software would be pretty low (or it would have been free if they designed it that way to begin with).
I think this shows that error proofing is not a “tool,” it’s a way of thinking — you often don’t recognize effective error-proofing when it’s there, but you notice it when it’s missing.
So maybe today’s challenge is this: if you’re designing anything:
- Some software code
- A piece of machinery
- A system or process
Can you anticipate something that might go wrong and design in a way that makes the error impossible (or much less possible)? Hanging a “be careful” sign doesn’t count!