Leaping into 2009
Many people ushered in the New Year a second too early, thanks to the necessity of the added leap second to account for deviations in the Earth’s orbit. I was more acutely aware of this occurrence on account of having just finished Jo Marchant’s “Decoding the Heavens”, deepening my interest in chronological precision. This follows the frustration of an unsuccessful search for a reliable NTP source. Pointing to any individual time server didn’t really work. The problem I observed was not in the accuracy of individual readings, but the availability of readings when I needed them. Many times I found the NTP servers unresponsive. Perhaps there is too much load on them, and in such circumstances the servers just don’t respond. Without regular readings, maintaining accuracy is impossible. The solution was to set up a local stratum 3 NTP server, accumulating time data from multiple external sources, seven in my case. Quite an advance over the astrolabes of the ancient Greeks!
So, this holiday I’ve consumed three popular science texts (and one to go), nursed a cold (bronchial and nasty), watched a modicum of TV (is it just me or is TV getting worse each year?) and eaten more than my fair share of roast turkey. There’s been some time on the computers too, but not as much as expected.
The year ahead looks challenging. Global markets are under immense pressure. Contractions, mergers and outright terminations are on the increase. Business growth is giving way to cancelled lines and cost cutting. Interestingly, the latter may be one of the few growth opportunities remaining: finding new ways to save money. Customer care is a good example. Unless you intend to go out of business, you don’t really want to cut customer care, though it can be a considerable business overhead. What you might consider is changing how you provide care to your customers. Do you really need to provide that telephone hot line? Can you afford to have people dealing with the phone calls? Would IVR do the job better?
I had an interesting experience with IVR recently. The first part was torture, as I was waiting in a call queue for nearly 20 minutes, and then I got through to the IVR. It gathered my details, confirmed them, narrowed my enquiry to a particular business line and then admitted that it couldn’t help anymore, so it put me into another call queue for a human operator. Fortunately that queue was answered in less than 5 minutes and the IVR had passed my account number to the operator. Unfortunately none of the other details I had entered via DTMF had been passed through, so I had to go through the list a second time. Eventually, after elaborating my enquiry, the operator said “well, that should be explained on our Web site.” It wasn’t, nor was it explained in the written Terms and Conditions, but we eventually sorted it out to my satisfaction. But that’s not the interesting bit. Following my conversation with the company, an engineer arrived on site a few days later as arranged, installed new kit and departed. Less than an hour later I get a phone call – from the IVR system. It was checking to see that the engineer had called to say he was on his way, that he had actually arrived on time and that the job was to my satisfaction.  (The answers were no, yes and yes, respectively.) While the original encounter with their IVR system was less than impressive, this IVR-based follow-up did have the effect of increasing my overall satisfaction with their customer care.
So how do we improve the initial experience? Well, first you have to remove that call queue, which is expensive as you have to allow for peak usage periods. Second you have to expand the scope of the IVR to cover more of the space for which you can automatically provide answers to customers. This is the hard part, as it’s difficult to anticipate everything a customer might ask and it’s even harder for a customer to keep the navigation in their head as they drill down to the answer they need. After a certain depth, people just get hopelessly lost and jump for the emergency button (e.g. pressing the “star” key to get a human operator).
A better solution, in my opinion, is a dedicated customer care Web site, fully adapted to a variety of usage context (especially mobile). This is not a Web version of the shop front window. This is the Web version of the back-of-the-store customer service desk. As customers reach for the phone to call customer care, they should be thinking “the alternative to queuing for 20 minutes for an IVR session is to go directly to customer care via the browser on this phone.” With the right mobile Web experience, this would be the perfect solution for the customers and for the business.
But how do you advertise the mobile Web version of the customer care service? One obvious technique is to put a link onto the home page of the company site, directing people to customer care. This only works if the home page will adapt to mobile devices, which without the right kind of sophisticated technology, is more difficult to achieve than would at first appear. A second approach would be to reserve a particular path on the site, such as example.com/cc, to be used consistently by all sites as the entry point for customer care. Getting such an idea universally accepted would be close to impossible, and is obviously biased to a single language (English). It would be far better to advertise the URLs as part of the header/footer of the bills and other correspondences where typically one finds the phone number for customer care.
A third option is to advertise the CC URL in conjunction with the telephone service. This can be done by the IVR itself (i.e. reminding you of the CC URL while you are listening to an awful loop of elevator music) or via the telephone directory (either the printed or dial-up variety). The key problem here is transferring the URL to the browser. There are two challenges: first the user has to remember the URL long enough to enter it faultlessly into the browser, and second the user has to be able to enter the URL despite whatever modality limitations are imposed by the mobile device. A solution to both of these is automatic delivery of URLs, typically via short text/multimedia messaging. An IVR could do this (just like it could call me at home to check that the job was done) and the dial-a-directory service can do it (just like they will send you a number via SMS). Even the printed variety can do it, using 2D codes, a camera, a back-end server with OCR and a push-message mechanism for delivering the recognised URLs.
Generally there are plenty of ways to encourage the use of mobile Web customer care solutions, augmenting existing IVR solutions. I doubt the IVR solutions will be replaced, but a lot of the expensive human-operated solutions (and their tedious queues) could be reduced, or at least directed to the most complex issues that arise, when the customer hits the panic button. As 2009 unfolds, I expect to see a lot more of these approaches being adopted.
Categorised as: Uncategorized