Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations IamaSherpa on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Agent changes in Symposium

Status
Not open for further replies.

rfwhite

Technical User
Jul 25, 2003
246
US
We have an intermittent happening in Symposium. Occasionally an agent is not recognized as being logged in therefore the call is (mis)routed accordingly. Our admin folks have a bad habit of making changes to agent profiles 'on the fly' and I'm wondering if that is a clue. Anyone else experienced this?
 
Do you have admin rights for Symposium Server and the client? We use to admin right logins with different names, so we could trace who made the changes??? Take the admin rights and control the changes yourself, maybe?? Check the event viewer on symposium server and you can view these events through the client also, lot of information, but you can see what is going on!



Cheers,

Killian,

NextiraOne Ireland

 
Thanks.
We know who is making the changes. I have gone through the event viewer but am having some difficulty decoding the arcane errors. We have had some luck matching times and events. The scenario goes like this:
High volume callcenter. Some skillsets are limited and have only 1 agent at times. Supervisor calls agent1 & says "I'm changing your profile- want you to log off SKS A and onto SKS B", then calls agent2 & says "I'm changing your profile- want you to log off SKS B and onto SKS A".
It appears that if a call comes in that should be routed to the limited skillset Symposium defaults the call because it can't find a logged on agent. I'm suspecting that pending priority changes confuse things until the agents affected log off/on. Make any sense?
 
It does make sense, in the last company I worked for we had a similar issue, I changed the scipting, I made a default skillset and that all calls could go to this skillset if there were problems. If you play around with the scripting, you eliminate the supervisor changing skillsets all the time. If you tag the calls also and use the log command in your scipts, this helps alot to troubleshoot. Hope this helps you a little.

Cheers,

Killian,

NextiraOne Ireland

 
Right, I do have the problem calls dropping into a default SKS. I haven't played with logging so that's something I'll look into implementing. I'm always a little hesitant to make changes. This script has been performing flawlessly for about a year and it's only since the cc admin folks changed their skillset assignment methods that the problem started.
 
Sounds an odd way of changing agents skillsets. We have several that hop around so all i do is put the agents in all the skillsets required.

Then create an Agent skillset assignment group with the required users in and then you can chop and change as required, without the agent logging out. This may not be best practise, but we've never had a problem doing it.

Stu..

Only the truly stupid believe they know everything.
Stu.. 2004
 
Of course, you could rewrite your scripts with overflows, so if the number of calls exceeds x and number of agents is less than y then queue to another skilsets with both sets of agents in.

Stu..

Only the truly stupid believe they know everything.
Stu.. 2004
 
Thanks, folks. Stu, we do basically that as well. There is a timer that prevents a call from sitting even in the correct queue too long. It gets sent to the 'second choice' skillset.

We have trapped enough instances to sort out the fact that there are actually times that Symposium fails to recognize the longest idle agent. Vendor is checking to see if there is a patch to address the problem. I still think it is related to the changing skillset assignment game since we have several skillsets and this is the only one having troubles.
 
I agree with Stu re logging agents out to change skillsets. If agents have both skillsets in their profile (with the ones they don't want to answer calls on set to standby), there is no need to log them out. The change will set them to not ready, however.

Perhaps the admin folk could do the move in two parts:
1) Add Agent 1 to skillset B and agent 2 to skillset A (both agents now have both skillsets)
2) Set Agent 1's rating for Skillset A to standby and Agent 2's rating for skillset B to standby.
 
Right- understood. The additional logout/in isn't for call flow purposes. The cc folks want different logins for statistics generation. An agent may have as many as 5 logins for different skillsets depending on training and/or abilities.
 
You have piqued my interest!

What statistics does doing this give you that you couldn't get if you had a single profile that was modified as required?

 
to prevent this we have made one user (we named it "all skillsets") and added all skillsets to it, this user is logged in on a phoneset that is allways on not-ready. This way there is always at least one agent logged on each skillset, and calls are not bounced but queued in the right skillset.
 
DD, I don't get deeply involved with the reporting side of things. I'll pose the question to one of the folks and see. I'm guessing it may have more to do with the screen pop and billing side. (We have a home-grown custom Unix application here.)

carolien, interesting workaround but I think the timers would prevent that method from being effective here.
 
DD Ihave seen a scenario where they used 2 separate login ID because 1 login ID was used when you are on backup only and your primary duty was off phone work. This would increase the Not Ready time and they wanted to peg the Not Ready against the off phone work.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top