How to differentiate two CLs by skills within one routing strategy?

[fourteen]

Hello everybody.
My goal is to make two calling lists within one outbound campaign (and one routing strategy respectively) and to differentiate them in some way, so that calls from CL1 will be handled only by agents with skill1 and calls from CL2 will be handled only by agents with skill2.
Have no opportunity to make another strategy for new CL2 as unfortunately we have got no spare RPs.
So my plan is:
1. Create CL2
2. Add it to campaign
3. Create a new campaign group Campaign@Skill2
4. Modify routing strategy in some way. Current strategy is pretty basic, it has a Selection object with target selection:
Type Skill
Name Skill1 > 0
Do I understand correct that if I add Skill Skill2 > 0 to this Selection object, both calling lists will be handled by operators of both skills?
If so, than I have to add one more Selection object for Skill2 but I have to add some Segmentation or "If" kind of object to differentiate between two Selections. And I have no idea which parameter or function I can use for that purpose.

Would be very grateful for any piece of advice!

[fourteen]

Sorry, mixed it up a bit, while talking about creating CLs & modifying Campaign shoud've used Agent Groups instead of Skills.

[Kubig]

If you want to write/develop simple strategy, which will be usable for many campaign, do not write any "hard-code" things to the strategy, all data read from KVP or other source and write strategy in general view. However, as a first I suggest to you read the doc about routing , to clearly understand all possible functions and scenarios and then make own test with routing.

[fourteen]

Thank you!
I'm into Genesys' guides for two days, still can't find a solution.
By "all data read from KVP or other source" you mean sth like UData or SData, right?

[Kubig]

Udata = UserData = KVP = AttachData
Sdata = Statistics

I mean Udata, ListObjects, database store and etc

[fourteen]

Thanks! I never met term KVP while reading docs & using IRD, always refered to it as UData.

I can fill in the field agent_id while creating CL2 (it will be used for one agent only), in CL1 this field will remain empty. So I can make a condition: if agent_id = 1001 (for example) than go to Selection with Skill2, else go to Selection with Skill1. That will perfectly suit my goal.

Is it possible to extract agent_id field, that is assigned while making CL from UData? If so, how exactly syntaxis should look?

Unfortunately I have no experience with this, in previous strategies we used UData only after we assigned it ourselvesves somewhere during the strategies. Can't find how it looks  like "on its own"

Would very appreciate any help, feeling a bit embarassed for such a rookie questions..

[Kubig]

Does not spam this forum with rookie question pleas. As I wrote above, read the doc first for clearly understand what Genesys is, can and what routing scenario provides, read the ref guide for routing, that describes functions in IRD and contains simple sample of specific routing scenario.

[cavagnaro]

[quote author=fourteen link=topic=7820.msg34047#msg34047 date=1369121951]
Hello everybody.
My goal is to make two calling lists within one outbound campaign (and one routing strategy respectively) and to differentiate them in some way, so that calls from CL1 will be handled only by agents with skill1 and calls from CL2 will be handled only by agents with skill2.
Have no opportunity to make another strategy for new CL2 as unfortunately we have got no spare RPs.
So my plan is:
1. Create CL2
2. Add it to campaign
3. Create a new campaign group Campaign@Skill2
4. Modify routing strategy in some way. Current strategy is pretty basic, it has a Selection object with target selection:
Type Skill
Name Skill1 > 0
Do I understand correct that if I add Skill Skill2 > 0 to this Selection object, both calling lists will be handled by operators of both skills?
If so, than I have to add one more Selection object for Skill2 but I have to add some Segmentation or "If" kind of object to differentiate between two Selections. And I have no idea which parameter or function I can use for that purpose.

Would be very grateful for any piece of advice!
[/quote]


Voice Target must be different RP for each campaign, you can't use 1 single RP for all the campaigns. It will affect your Outbound dialing in a BAD!! way

[JTL]

[quote author=Kubig link=topic=7820.msg34053#msg34053 date=1369131679]
Does not spam this forum with rookie question pleas. As I wrote above, read the doc first for clearly understand what Genesys is, can and what routing scenario provides, read the ref guide for routing, that describes functions in IRD and contains simple sample of specific routing scenario.
[/quote]

Out of interest, where should someone post "rookie" questions in that case?

It does seem that some hardcore people on here do not want to help out those who, for whatever reason, haven't grasped (or have not had properly explained) some of the basic concepts.

I've been using Genesys for over 12 years, and have barely scratched the surface on some parts of the solution, and I do not have a coding / developer background either - but I find some people to be really quite dismissive if they think a question asked on here is "too simple", and quite often told "go and read the documents" - when often the answer is not contained within the documents, or else it is not easily understood.

Since not everybody has access to a sandpit / development environment, it isn't always possible to "go away and experiment" either. If I made large-scale changes to our environment, for example, "just to see what happened", I wouldn't last a week.

Please can we try and be just a little more forgiving on here!?

[dmans1]

Hi,

We are doing our outbound campaigns using a single table access and a single Voice Target for all of our campaigns.
    Proper record selection is done via a filter, which is different per calling list.

    All campaigns have the same voice target. Call Segmentation is done via a Segment node in the strategy that looks up a specific Attached Data keyValue which is unique per calling list. The data is attached by using a User Defined field in the table format and setting a "send_attribute"in it's annex.

One catch in this approach is that you have to properly index your table according to what you will use in the filter.

[cavagnaro]

You do know that calls in queue are considered also in dialing algorithm, right? so if you queue more than the calls you just distribute to a single calling list will produce poor dialing performance. Does it works? Yes, sure, basic logic. Is it correct? No, it is not the correct way to do it

[dmans1]

No issue here since the strategy targets different groups and  logs  interactions to a different VQ per calling list.
I'm not talking here theoretically.We are using this approach for the last 3 years and it works/performs as expected.

[cavagnaro]

Well OCS doesn't care about VQ. As said, it works but is not the best way.

[Grand_Master]

[quote author=cavagnaro link=topic=7820.msg34131#msg34131 date=1369753845]
Well OCS doesn't care about VQ. As said, it works but is not the best way.
[/quote]

I think you didn't read properly, cavagnaro

If they are using multiple campaigns the algorithm shouldn't be impacted by the use of VQs in the target strategy.  It would only be an issue if they used a single campaign for all calls.

[cavagnaro]

3 Campaings (sample) with 1 unique Routing Point as Voice Transfer
On the RP you load an strategy that based on an attached data does transfer to different targets (3 in this sample) with different AG
As all 3 campaigns have 1 single RP the retrospective Stats from the RP go to OCS (queued calls, entered calls, abandons, droppeds) therefore all 3 campaigns have false information and the dialing algorith is build with wrong information.
On the target he configures VQ for REPORTING issues, not for ROUTING

So I do know how OCS works, I do understand their statement, but he thinks that as it "works" it is OK and leads to a bad configuration for the initial poster.
Again, it will work based on OCS and URS basic principles, BUT IT IS A BAD IMPLEMENTATION