“Please don’t make me repeat myself.”
I am positive that I am not alone in that feeling. I hate calling a company’s 800-number, punching in my telephone or account number along with the reasons why I am calling, only to find that when I finally do reach a live human being I am asked the exact same questions all over again. In fact, I get so frustrated with this that I tell the contact center agent that I hope my call “is being recorded for quality purposes” because I want someone to hear just how aggravated I am. To make matters worse, I know that if my call needs to be transferred to another agent (and we all know how common that is) I will have to go through the exact same song and dance all over again.
For the first 24 years of my professional life I was a software developer. I began working on operating systems, moved into unified communications (before anyone ever called it that), and eventually ended up writing applications for contact centers. I say this because way back in the 1990’s I was writing code that attached data (e.g. a caller’s account number) to a telephone call at the point where the customer entered it. We called it Computer Telephony Integration (CTI) and used tools such as Microsoft’s TAPI and Novel’s TSAPI to make it happen.
There is a problem with traditional CTI like TAPI and TSAPI that is clearly evident in all those contact centers that force you to repeat the same information over and over again. Traditional CTI relies upon some outside entity to ensure that data gathered in one place is pushed to everyone and everything that needs it down the line. For instance, you can ask for a customer’s account number at an Interactive Voice Response (IVR) unit and associate that number to a telephone call, but something needs to ensure that it remains associated and that it gets delivered to the agent who takes the call. Clearly, in all those failed contact centers that something isn’t doing its job very well.
All of this leads me to something relatively new in the contact center space – context management. To understand context management it’s easiest to think of a conference call where you continually add and remove participants from that call. Now, when you call into a company’s 800-number you are immediately put into a conference call. If an IVR unit is necessary to gather information about why you are calling (press “1” for this, “2” for that), add it to the conference call. The IVR can then add all gathered data to call’s context. When you are finished with that step, remove the IVR unit and conference in an agent. All the data that was gathered by the IVR unit is still within the conference providing the agent with immediate access. If that agent needs to transfer the call, simply add the new agent to the conference and “voila,” that agent has the data, too. No more repetition and no more frustrated customers.
Let’s take this even further. What if we added the customer’s calling history to that context? Or how about his or her previous emails and web chats? What if we empowered the agent with all sorts of relevant information about the customer (i.e. me) and why he or she is calling?
So, how does this magic come about? SIP, of course. You need a protocol that’s media agnostic with a clear separation between signaling and the media. Additionally, the open architecture of SIP allows you to physically place a customer’s information into a SIP message ensuring that data remains with the call for its entire life. Y0u won’t see this with H.323 or an older TDM protocol.
It’s my dream that one day every contact center employs the principals of context management and no longer will I be asked for my account number again, and again, and again, and again. Not only will it save everyone’s time, but I’m positive that customers will be happier and agents more productive. Sounds like a win, win, win, doesn’t it?