Contact Centre

Diaries of the voice portal (part 2)

Few weeks ago I wrote about the first voice portals, back in ’97.

Fast forward 5 years. VoIP communication is all the rage and we all merrily jump in the wagon (we do love us a new technology, don’t we) and start working on the network. All without knowing a thing about IP stuff, hoping that the behavior of our nice little voice toys, on IP transport, would be the same. And obviously it is not. images (1) I remember getting a call from a customer one afternoon timidly complaining that their voice responses (and in fact the whole contact center) was not answering calls: it was, in fact,  dropping calls. Now, dropping calls in a telephony environment is like the worst thing that could happen, only second to a complete major outage of the platform (or death in the family), so I righteously panicked and called the network guy that was in charge of the VoIP configuration. He answered calmly that he got the customer call as well and that he did get immediately into the system, checked his beloved router and saw that all was fine, so he scheduled the support for a more convenient day. He would look at the issue the next day as soon as he was in the office.

WTF?!?

Well, that was my first encounter with the “network guys”, where a bit of network outage did not mean _panic and destruction_ but only a few packets lost here and there, no fuss, no big deal. Hence the first lesson learned with VoIP: synchronous communication does mind if packets are lost, and even a few seconds outage IS a big deal and will probably at best miss portions of the interaction, at worst drop the whole connection. In the end it was the carrier’s fault and the connection with the voice gateway took all the blame, but after this occurrence the network guy never missed a “dropped calls” alert again. 🙂

Advertisement

If I were a user (#2)

Why would I want to call a number, be harassed by an automated voice and stay in a queue for excruciatingly long minutes if I can do anything by myself on a website or mobile app?

Because somewhere in your self-service or company strategy, a process is broken and the end user cannot find the answers, that’s why!

5489048492_2dbc68bd1b_b

A few weeks ago I got a package from Amazon that I did not order. I double checked my orders – being a Prime customer, I have quite a few in my backlog 🙂 – and realized I had to tell them that there was no order with that ID, although it was sent to my correct name and address. Of course I checked on the website first, to see if I could do it myself, but nope, no way I could return an item that I did not order in the first place.

In the end I had to call customer care (with an odd callback policy, but they will call you back within seconds from your request, so totally forgivable) and even the agent could not fix the issue, so they sent me an email confirming that I could keep the item as they had no way of having me return it. This is obviously a good example of customer experience: although there was a broken process within the company, they made it as smooth as possible for the end user, but how many companies can claim they can cope with a broken internal process so neatly?

It’s not enough to provide omni-channel customer care with all the latest technology and the coolest strategy, if the internal processes are weak or missing: the customer journey plan begins always with content. It doesn’t matter to plan the “how” if you don’t have the “what” ready.

Diaries of the voice portal

I have been working on one of the first “I.V.R.” (Interactive voice response, for those not familiar with the acronyms) back in 1997. It was a huge thing back then, especially as ASR and TTS (the natural language way of speaking with a machine) were really early technology and to say the least, a bit immature. I remember that we randomly called people from all over the country and recorded the calls for the ASR engine to get all the slang and accents.The embryo of today’s voice portal was in my hands and it looked awesome and cool and as an engineer, the potential seemed so high that we imagined these things would replace humans in just a few months!

So after a while we enthusiastically rolled out our first scripts: developed, tested, re-tested, documented and highly appreciated by the techies, only to find out that

…they were a complete disaster once in the hands of the end users.

They lacked some instructions, albeit the intuitive menus, some quick fallback to a nice sweet helping voice, the speech recognition was funny and bizarre and text to speech failed to be comprehensive, but most of all, we assumed that common users did prefer a machine to a human. I am still convinced that some of the errors we made back in the old days are still haunting us because guess what? People remember.

Now things have changed a lot, but again not so much from those years:

  • We still develop scripts for the user to play with – sometimes we also provide some sort of independence for the users to develop their own dynamic script during the interaction. This still has lots of potential but is inexorably linked to the target users.
  • Adoption rates largely vary according to the service, the target demographic and the goodness of the script. And I am not mentioning here those ivr trees that are specifically developed to confuse and deflect people from calling.
  • ASR and TTS are still not widely accepted for many reasons that have nothing to do with the technology, which is even more awesome and amazing than ever (have you tried it?) : namely the end user willingness to accept the use of natural language in their game with an automated response thingy.
  • Self-service is still somehow big: people love to find their own answers and browse safely on the web or on any other device that will guarantee some degree of anonymity: similar to the unparalleled satisfaction of mounting our own Ikea piece of furniture (for those of us who don’t end up with a weird library and a bunch of unused screws), we love proving to our self that we can be self-sufficient across different channels and fix our own problemsMounting Ikea furniture
  • A human representative is still the choice of election for those problems that are not in the Q&A, not in the FAQ, not in the knowledge base and not in any automated script and therefore require the human brain to solve it.

How are we doing with this? 18 years and still dealing with ivr scripts? There must be something new in our technological horizon, something that will lift us to the point where users will find 99% of their answers and the 1% will be answered by a super-human agent who is someone like Mr Wolf, only “solves problems”.

The Wolf

For now, I guess we’re far from that target and I really need to call my isp support to fix this upload issue… 😦

“Know me” or “Stalk me”?

There is a great hype today about being recognized and cherished as a customer by any company.stalker-main_1405037a

We, in the works, sell it as the next best thing: you contact a company and suddenly you and your history with the company and any private, related information is out there, and the company is very proud of having invested good money in the technology and processes that work together to give you this great customer experience….

…kind of like when you shop around and suddenly google is displaying the very things you were sneaking at, right in your face…

I am not sure this is all good. In fact, I am sure there is a boundary between “knowing me” and “stalking me” and it largely depends on the company, the product, the situation and definitely the individual involved. For me as a consumer, this boundary is very close to the name and maybe the address: any information after that I perceive as invading, not appropriate, not even wanted.

customer experience

Where’s the boundary?

So I am asking you users out there: where is your boundary? What of your personal information would you give away in exchange for a good customer service?