Google - the next player in contact centre knowledge management?

I was looking through some material about Google Docs today as I'd been asked if any of it might be relevant to a customer I was working with.

The thing that stuck me was that while Google Docs probably weren't suitable (yet), the implications of the Google's search capability could be quite profound in the area of contact centre knowledge management. There's been speculation that Google could go in this direction for a while (see, for example, the UK technology site ZDNet writing in 2006) and obviously if knowledge management is seen as a search function then Google is an obvious answer.

Importantly, knowledge management in call centre is not just a search function. It can be about information categorisation, business processes and making available information other agents have learnt from experience. Yet none of these are things Google can't do or won't be able to do in the near future. Furthermore, the Kana and eGain type of application with a separate knowledge management database and proprietary approach to knowledge classification looks in danger of being made redundant but web 2.0 ideas like wikis and the ever increasing use of XML tags for data.

Despite this, I'd still recommend clients to look at knowledge management applications as a solution for specific issues. Where they white-label the contact centre for example (so agents handle many different processes depending on which brand they are representing) or where web-chat or e-mail is a consideration and knowledge management can provide an element of scripting and agent assistance. In these examples though, knowledge managment is providing more value than just a searchable repository.

Google isn't there yet, but I would not be surprised if knowledge management experienced the same trends as the rest of the application sector and a bout of consolidation.

e-mail in contact centres, process driven or response driven?

One of the interesting things I'm seeing around e-mail in the contact centre is debate on how to manage it.

With a phone call, things are relatively straight forward - you answer it. You might need to queue it, or gather some intelligence for routing but fundamentally you are talking about something that is real-time and a synchronous form of communication and contact centres handle that well.

By contrast, e-mail is not real-time and is an inherently asynchronous method of communication. It can be answered at an agent's convenience and an agent can handle multiple e-mail sessions concurrently. Furthermore, the agent can be given a lot of prompting and guidance (even scripting) from knowledge sources to help them respond. Furthermore, the text based nature of the medium makes it much easier to integrate content into other applications.

To date, most of the focus on e-mail management for the contact centre has come from specialist players like Kana and eGain. These applications provide the necessary functionality for e-mail, usually provide chat and often web co-browsing. My personal preference is for the eGain suite (and not just because Cisco OEM parts of it), but for Genesys users Kana has a number of attractions, not least that execs at one have often worked at the other. In my view the first phase of e-mail management is almost over and the niche vendors are starting to align with the CTI (Computer Telephony Integration) vendors. This may be quite a loose alignment (e.g e-Gain and Kana can be paired with a whole range of CTI applications), but none the less the debate is largely over as to whether e-mail should be managed as a stand alone application or integrated with the telephony control application.

The second phase that I suspect to be just beginning is the debate whether the CTI or CRM system manages e-mail. Most CRM systems today have an e-mail capability and try to integrate e-mail with the wider CRM process. By contrast the CTI systems focus on the process of finding the right person to answer the e-mail, getting it there and monitoring how long the agent takes to write the answer.

I suspect that both approaches will prove complimentary, but there is sufficient overlap to make it unclear as to which application will eventual dominate the e-mail space.

Ofcourse, there is a wildcard in the form of SOA. If it becomes more prevalent as an architectural approach in the contact cnetre, then talking about applications 'controlling' functionality will be redundant. But SOA would be a third phase and although I see signs of the foundations being laid now, it is not yet a reality.