Operational issues with Symposium and Genesys

[david donohoe]

We have a 5.1 outbound unit and have had to move from a 5.1 Meridian Link Tserver to 6.1 Symposium Link Tserver. All our routing is done by Symposium.

The issue we have is that the business require to be able to move agents quickly and seamlessly between campaigns, of which there are several.

Currently, answered outbound calls are routed to a CDN, which uses Symposium to deliver the call to an agent with an appropriate skillset (we use the same name for the CDN/ACDDN/skillset/place group/campaign eg. Outbound1, Outbound2 etc).

We have set Campaign Manager to look for ready agents in the respective place group to start dialing (under Meridian Link it would look at ready agents for the respective ACDDN) and this works fine when all is static.

The problem is that we are unable to move an agent from one campaign to another as Genesys doesn't take cognisance of this. When you are running with a few agents, this can mean an solitary agent doesn't initiate dialing in its new place group

ie. Campaigns A and B are both running.
Agent X is in the place group that corresponds to campaign A, which dials away happily.
If agent X is moved to place group B, campaign A continues to dial, campaign B doesn't dial at all.

As we generally run with 1520 or less agents over several campaigns, such movement causes the dialing to be skewed and we suffer from under and overdialing.

At the moment, agents are physically logging out of a phone and PC and moving to another desk to move beween campaigns. This is timeconsuming and disruptive and will soon be complicated by extra lists and outbound calling during the day.

Does anyone know of a way of being able to move an agent and their place from place group to place group without having to restart Campaign Manager/Tserver?

Your help would be greatly appreciated. Thanks

[Ritchie]

You will not have to restart tserver, but you will always have to restart campaign manager if you move agents form group to group. I can see 2 solutions. Either you upgrade to OCS 6.5, or you put your agents in all the groups at once, relying on the switch to do the routing.

[david donohoe]

Thanks for your reply Ritchie.

As we have login_ignore_queue set to true, having ready agents in several place groups at a time would cause the dialer to make several calls for one agent. This would cause overdialing, which is a big no o for us.

Is there any way that you could either a) have agents in several place groups, but with Genesys only making one dial per agent or b) use agent groups to kick off dialing? As I understand it, agent groups are used with inbound Genesys routing, but I may well be wrong

Thanks again.

[Vic]

Hello, Ritchie,

you know, I was playing around with OCS a while back trying to figure out the same problem as what you have just mentioned, and, you know, it worked.

ignore_login_queue value would cause OCS only to track agents based on their ThisQueue value, so what you do is assign your agents to all your agent groups that the agent will need to associate for the differnet campaigns and then have your agent simply relogin into a queue that is assigned to a particular campaign. This way, OCS would track only the agents that actually logged into an ACD queue assigned to the agent/place group, and not all the agents that are assigned to that group.

Here is the settings for OCS that I had:

[OCServer]
call_answer_type_recognition=telephony_preset
call_transfer_type=one_step
call_wait_agent_connected_timeout=6
call_wait_engage_agent_timeout=10
call_wait_in_queue_timeout=10
call_wait_original_establish_timeout=4
desktop_version=6
engaged_release_action=soft_previous
history_length=30
inbound_answer_action=soft_answer
inbound_release_action=soft_previous
internal_answer_action=soft_answer
internal_release_action=soft_previous
login_action=soft_not_ready
login_ignore_queue=no
outbound_answer_action=soft_answer
outbound_release_action=soft_previous
record_processed=yes
seized_release_action=soft_previous
stale_clean_interval=15
stale_clean_timeout=30
record_save_intermediate_results=yes
call_wait_connected_timeout=10
predictive_callback=yes
call_preview_record_on_desktop_timeout=2