IPCC 7.0: How to configure skill level?

[ipcc_designer]

Hi there,

Does anyone know how to configure skill level so that the most experienced agents would always answer the calls first. If they are all engaged, then the inexperience agents would then answer the calls.

I am using CCM 4.1.3, not legacy PABX.

Thanks in advance.

[adignan]

Your best bet is to create different skill groups for example:

English_1_SG

English_2_SG

English_3_SG

English_4_SG

English_5_SG

Then in your Skill Group node in your ICM script just list English_1_SG first, English_2_SG seconds, etc, etc.

Assign your agents to the appropriate skill group. With 7.0 you have the agent re-skilling web page so administrators could easily move people in and out of the skill groups.

please rate helpful posts.

adignan - berbee

[ipcc_designer]

Thanks for your information.

In legacy PABX, which we can actually define the skill level for each agent so that only one skill is needed to be created, we wonder if this is feasible with CCM and IPCC. How about the base-skill and sub-skill group? Or these are target to integrate with legacy PABX only?

[adignan]

Using subskills is not recommended because it causes issues with reporting. IPCC Express offers "skill levels" but with IPCC Enterprise this is your only option.

please rate helpful posts.

adignan - berbee

[ekumpel]

Adigan,

Can you elaborate on the reporting issues that this creates? I currently have a center running with the sub-skillgroups.

Thanks,

[Zin.Karzazi]

While they are not recomended to use (Reporting issues, although you can adjust your script so you get the right statistics) see here for example:

?If you have configured sub-skill groups, you should queue calls only to those sub-skill groups, not to base skill groups. If you queue to the base skill-group when sub-skill groups are configured, queue statistics are not counted against the sub-skill groups. You must queue to the sub-skill groups to see correct queue reporting data on the agent desktop reporting applications and WebView.?

We are using subskillgroups too. The Script is straight forward:

2 Select Nodes with LAA

2 Skillgroup Nodes

the first LAA nodes points to a Skillgroup Node (in which you select your Pri Subskillgroup) from the first LAA you go to the second LAA select node and do the same with Subskillgroup Sec...etc. This should route Calls to the most experienced Agents (which must be Re-Skilled in Pri Subskillgroup) if they are all busy the call will go to the Sec Subskillgroup.

also read this doc (subskillgroups):

Cisco IP Contact Center Enterprise Edition Administration Guide IP Contact Center

[tb33mid]

Good Information, is there official documentation in regards to this? We have an issue where the Supervisor looks at their teams, if someone is skilled as a 10 it is displaying as an 8.

Thank you,

Todd

[Riccardo Bua]

Hi all,

trying to wrap up as much info I could on this, sorry for being so long.

The skill group queue depth with different levels pertain to the world of TDM switches where the ACD will report on different skill group layer via PIM/OPC to the router and the record will be properly flagged by the router on the skillgroup level if the key is modified.

This is always a challenge to explain when dealing with customers coming from the TDM side where they have a/some feature/s enabled to create different set of agent layers in skillgroup priority.

To share some words from a peer on this topic:

“The problem with using sub-skills in most (all) ACDs is that when the ACD picks the "most skilled agent" for a call type, it will overwork the highest skilled agents and often not send any calls to the lower skilled agents, which burns out the best agents faster in the call center.

ACD vendors have developed work-arounds like "least occupied agent" in their selection routines to fix this and similar bug in their routing code.

We actually avoid that logic trap all together by not automating any of the agent selection outside of the control of the IPCC routing script.

Even if you enable sub-skills in IPCC, you have to route to them individually, in "detail" vs. trying to route to the "base skill."

Assuming a basic call flow like this, with a "gold" and a "silver" skill group that the agents are skilled for, then you also have specific call types for a "gold inbound" and a "silver inbound" call.

When a "gold inbound" call comes in, you would offer the call to the "gold" agent first using a "LAA" against the "gold" skill or a "queue to skill" pointing to the "gold skill."

To overflow the call to a "silver" agent, we could insert another LAA node for the "silver" agent skill if the "gold" skill doesn't have any available agents -- if there was a silver agent available, the call would overflow directly to that agent.

If there were no silver agents available, the call could be queued to both gold and silver agent skill groups -- or it could escalate in queue that during the queue loop, after 30 seconds add another queue to skill node for the silver agents.

As you can see, there is a lot of flexiblity in what groups we send calls to -- and when. All under control of the IPCC script, visually.

Personally, I prefer to be able to see what my calls will do vs. having an ACD hide the logic in the config of the skill or priority."

From my prospective since IPCC do not provide such a layer queue depth or agent abilities have no particular meaning, even if something might be coming in the future on a newer Release enabling a complete different feature set, to this moment enabling different layers of skillgroups has no meaning in an IPCC world and could have impact on the scripting and reporting side causing an agent state transition not to be properly reported if the change does not occur in the default or base skill group too(hence why we always create the default skill group to get the right reporting features and enforced the documentation in that direction) as others rightfully said.

One of the way to deal with the scenario as Andy mentioned was to

1. Create a 'skill' per agent

-- agent1skill

-- agent2skill

-- agent3skill

-- etc.

2. Assign each agent to their own 'skill' as 'primary'

-- agent1 -> primary for agent1skill

-- agent2 -> primary for agent2skill

-- agent3 -> primary for agent3skill

-- etc

3. Assign agents as secondary to all but their 'skill'

-- agent1 -> secondary for agent2skill, agent3skill

-- agent2 -> secondary for agent1skill, agent3skill

-- agent3 -> secondary for agent1skill, agent2skill

This would be the recommended way to deal with this, if you decide to stay on the approach of dividing your agents in skillsets. Caveats below.

Riccardo

[Riccardo Bua]

Caveats:

As others said Base groups are recommended over sub-groups to avoid confusion when reading reports, and scripting.

Sub groups are supported and will continue to be supported.

"The caveats to sub-groups are:

1. Sub-skill groups do not imply priority in scripting. You need to script priority in with separate nodes for each sub-group if you want to give one sub-group priority over another. This is the most common area of confusion for those new to IPCC/ICM.

2. If you queue against the base group when sub-groups are configured, queue statistics will not be counted against the sub groups. You need to queue against the sub groups in order to get the queue reporting correct in AW/reporting and at the agent desk top. The reason is that if you against both sub-groups, calls queued would roll up as 2 calls queued in the base group, which was also confusing.

3. When mapping services to skill groups, you can indicate which skill groups are primary members of the service, which just gets confused with the primary sub-skill concept. They are unrelated.

4. When selecting "agent skill group" reports, the base agent skill group is available in setting up the templates, and will return no data since we only report on the agent level sub-skill groups the agent is logged into. Agents are not allowed to be assigned or log into the base group if sub-groups are available.

5. When selecting "skill group" reports, if you select base and sub groups at the same time, it may appear that there is double counting in the summary since the base skill group is a roll up of the sub groups. To avoid this, only select either base or sub-skill groups.

6. Each sub-skill group is pretty much treated like a separate skill group by the ICM and Router. The only difference is the automatic grouping and associated roll-ups into the base group.

Finally on the documentation side look at

http://www.cisco.com/univercd/cc/td/doc/product/icm/ipccente/ipcc60d/ipccent6/ipce60ad.pdf

Page 45

>> Note, however, that primary and secondary skill groups do not, by themselves, affect the priority given to them in an ICM routing script.

If you wan to use subskill groups as primary and secondary skill groups, understand that primary and secondary skills alone do not guarantee routing priority. You must build that priority into your routing scripts. You can do so by including separate Queue-to-Skill Group nodes in your routing script, and placing the node that points to the primary skill group before the node that points to the secondary skill group. <<

For the plus on using them see next one,

Riccardo

[Riccardo Bua]

Subskillgroup enablement:

I think the main benefit of sub-skill groups is that it provides the ability to have a built in overflow group.

Some set of agents would be in the primary group, if no one is available for x amount of time, the script would try the overflow group.

In this way, you can see when a secondary agent takes a call what skill group it was meant for when looking at skill group or agent skill group reports.

You can do this because the overflow group is specific to the skill group.

The other way to do it is to have one catch all skill group which serves as an overflow for all skill groups.

If any skill group does not get serviced in x amount of time, dump out to the overflow which all agents are a member of. This works functionally, but you lose a level of detail in reporting.

If you have 5 skill groups in contact center and one catch all overflow group, when an agent takes a call on the overflow, you lose track at a skill group level what the call was intended for.

You really can't tell which skill groups are understaffed by looking at the catch all overflow.

Having a distinct overflow for each skill group will let you know which types of calls a particular agent took, or how many calls did or did not get handled by a particular primary group.

You can do the same thing today by using skill groups and enterprise skill groups instead of subgroups and skill group roll ups.

It just requires about 6 more steps to add a separate overflow skill group and then add an enterprise skill group, and then set up an appropriate report.

With sub-groups, these steps are pretty much built in.

Another place where I see sub-skill groups being useful is when you are trying to set up language support for different skills."

Regards,

Riccardo

PS Please remember to rate useful posts.