Genesys have started to make some marketing noise about Social Engagement aligned with PA of the Genesys Social Messaging Server component on 17/12/2010 as part of the eService 8.0.2 Suite – previously known as Multichannel Routing (MCR) and Internet Contact Solution (ICS).
The concept is to simply extend eServices to add “Social Media” channels e.g. monitor popular sites (Twitter and Facebook) and automate the process analysing the message to take into account the following:
- Actionability – is the author looking for assistance or just expressing an opinion?
- Sentiment analysis – is the message positive, negative or neutral in tone?
- Influence of the author – how large is the author’s social network?
Social messages are then assigned to the appropriate queue with the appropriate priority.
Ok, so far so good!
However, technically when you delve into the solution you find some compelling reasons NOT to be an early adopter (in my opinion). Here are the reasons:
For eServices 8.0.2 if you want to use the sample Interaction Workflows (Business processes) that handle social media interactions you will need to upgrade a few components:
- Interaction Server to 184.108.40.206
- Universal Routing Server to 220.127.116.11
- Interaction Routing Designer to 18.104.22.168
If you are on URS 7.x don’t forget to get 8.0 license features (FEATURE router_seats genesys.d 8.0)
Twitter and Facebook API Limits
The interfaces used by the Social Messaging Server component are subject to API limits. For Twitter these are:
- 150 Anonymous requests per hour
- 350 Authenticated (OAuth) requests per hour
- Requests to resources that do not require authentication are not subject to the unauthenticated rate limit – rather they are subject to the rate limit restriction of the currently authenticated account
- Fetching new tweets takes 1 call
- Fetching new entries for a New Followers takes 1 call per column
- Viewing a user profile takes 3 calls.
- Sending a tweet does NOT affect your API limit
This means that if you make too many requests in 1 hour you will have to wait until the start of the next usage hour to fetch new social interactions. Of course it is possible to configure how many fetches are made to manage the API limits but at the end of the day it is still possible to have periods when it will not be possible to retrieve interactions in realtime.
This is not a Genesys specific problem and all direct social integrations have this problem. The only solution I can see is to use some sort of social aggregation service instead …
Most organisations would deploy Social Messaging Server component(s) behind a corporate firewall. However, according to Genesys support the Twitter and Facebook drivers currently do not support the configuration of a proxy server (or this has not been tested). I find this quite an oversight given that the Twitter driver is built on top of Twitter4J which does support proxy settings (setHttpProxy).
UPDATE: This can be done by editing the file “JavaServerStarter.ini” and add these Java runtime startup options:
In eServices 8.0.2, Genesys Agent Desktop (GAD) provides the agent user interface. In eServices 8.1, Genesys Interaction Workspace will provide the agent user interface.
If you are “unlucky” enough to be using GAD at the moment you will need upgrade the advisor desktop to Interaction Workspace (and buy an Interaction Workspace GAD Upgrade license) in the future.
Worse still, if like the majority of real world users you do not use GAD on the desktop you have no real way of handling Social Media interactions.
In eServices 8.0.2, Classification Server (so you need to install this as well) is used for Sentiment and Actionability screening. Even then, the screening rules OOTB are pretty limited:
Find(“Fail”) || Find(“help”) || Find(“how to”) || Find(“how do”) || Find(“assist”) || Find(“trouble”) || Find(“: (“) || Find(“(“) || Find(“dislike”) || Find(“frustr”) || Find(“bummed”) || Find(“unhappy”) || Find(“stink”)
There is currently no support for influence analysis which is quite important in determining interaction routing. In eServices 8.1 I am expecting some big improvements in this area.
In eServices 8.0.2, messages and responses are stored in UCS. In eServices 8.1, messages and responses will be stored in Context Services e.g. Context Services REST APIs will be used to provide access to UCS data entities via HTTP and URI paths.
Therefore, if I am an early adopter I will need to perform some re-configuration in UCS to move to eServices 8.1 later in 2011.
Given all of the above I think my advice would to be to wait for eServices 8.1 to be GA.