I am not alone when I say that I don’t like being forced to repeat myself. I dislike 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 that I often tell the contact center agent that I hope my call “is being recorded for quality reasons” 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 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.
The problem with traditional CTI like TAPI and TSAPI is that collected data doesn’t travel with the call. Instead, it 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. Those failed contact centers tell me 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 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 store all gathered data into call’s context. When you are finished with that step, remove the IVR unit and conference in an agent. The data that was gathered by the IVR unit is still within the conference/context enabling the agent to have 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? With context management all that and more are possible.
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 place a customer’s information into a SIP message ensuring that data remains with the call for its entire life. You won’t see that 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?
Tao, Zen, and Tomorrow 