Protecting agents

[djsanction]

Come to a bit of a dead end with something, perhaps someone might have an alternative solution...

The aim here is to keep a set number of skillet test_1 agents available at all times for any new calls, only flowing calls to test_2 if the number of IDLE agents in test_1 is >= to the integer set in the variable

i.e. if variable is set to 0 then all new calls will flow to test_2, if set to 2 then the calls will sit queuing for the phantom skillset containing no agents until there are 2 or more IDLE agents in test_1

(There is a seperate script for the incoming calls to test_1)

GIVE MUSIC gv_source3

SECTION agt_chk_loop

IF IDLE AGENT COUNT test_1 >= gv_test_integer THEN REMOVE FROM SKILLSET phantom_skset_ltsb_agent_check EXECUTE Loop
ELSE
QUEUE TO SKILLSET phantom_skset_ltsb_agent_check
WAIT 4
EXECUTE agt_chk_loop
END IF

SECTION Loop
QUEUE TO SKILLSET test_2
WAIT 50
EXECUTE Loop

This works to an extent so if the variable is changed then any new calls follow the logic but any existing calls will not pickup the new value of the variable and will sit queuing for the phantom skillset.

There is obviously a fair amount of this script missing in terms of best practice etc but the core is here.

I think there must be an easier way to do this but my heads gone..

Cheers!

 

[captaingadget]

You need to put the test for IDLE AGENT COUNT in a holding loop else it will only work for new calls not existing. The way you have the test written, if the number of idle agents in test_1 IS NOT greater or equal to the variable then the script will go straight to the END IF. There is no way back to the agt_chk_loop from there.

 

[djsanction]

Cheers for the response, so glad the question made sense. Just so I'm clear are you suggesting moving the END IF up one line as below ?

IF IDLE AGENT COUNT test_1 >= gv_test_integer THEN REMOVE FROM SKILLSET phantom_skset_ltsb_agent_check
EXECUTE Loop
ELSE
QUEUE TO SKILLSET phantom_skset_ltsb_agent_check
WAIT 4
END IF
EXECUTE agt_chk_loop

 

[captaingadget]

That would certainly do it. The call would whiz round the agt_chk_loop every 4 seconds and only execute the loop section when the IF statement is true.

 

[djsanction]

Cheers captaingadget, I did have a go with this earlier and it still seemed to sit and queue for the phantom skillset..

Can't see why it wouldn't follow the logic. Is it possible that a call will only take on the value of the global variable once in its life cycle ?

 

[captaingadget]

Yes, I realised almost as soon as I pressed submit that calls already in the loop section would never test for the variable. So you need to put the variable check in the loop section also, if that is what you want.

 

[BeWiser]

I have found issues with the scripting that you have to re duplicate the command by sending it round in a loop to get it to re trigger the event, as such I have repeated the command using the good old copy and paste and put a longer delay in so as not to have to put to many duplicate commands in the script. Sounds daft and can be a nightmare, but this was the only way I could get it to work in the past for me.

 

[captaingadget]

I agree with you BeWiser, complex holding loops are sometimes the only way of achieving the desired effect. CC6 always complains and warns you that you have duplicate commands. It is not smart enough to realise that sometimes that is the only way.

 

[djsanction]

Thanks chaps, glad its not just me...

I don't suppose any of you have any alternative solutions on how to acheive the same goal - How to protect certain agents... Only allowing calls to be offered to one skillset if there are a set number of agents available in a more important skillset when all of destined the agents share both skillsets...if that makes sense!

Something screams call priorities but I think I need a fresh look at it..

 

[BeWiser]

Have you looked at Skillset priorities and agent priorities within the skillset for the agents.

Increase call priority if Calls waiting exceeds or agents available less than x.

Alternativerly have you thought about going to a second level application if the agents available fall below the desired level, which then has the new skillset. Go through this and then loop back to the start of the primary level application.....Have not tried it myself in this way, but have used it for similar reasons.

For Good quality Insurance call 0800 954 95 45

http://www.BeWiser.co.uk

 

[captaingadget]

The trouble with agent priorities within skillsets is that is not dynamically adjustable. i.e. you cannot change an agents priority within a script. At least using the method outlined above and using different skillsets you can adjust the queuing parameters in the script. Maybe you could use a more automatic method by introducing a calculation based on ratios of idle agents in each skillset?

 

[djsanction]

Hi Captaingadget, can you possibly ellaborate on your calculation suggestion? cheers

 

[captaingadget]

Lets say you have 2 skillsets - skilla and skillb. You could have:

IF IDLE AGENT COUNT skilla > IDLE AGENT COUNT skillb THEN
QUEUE TO SKILLSET skilla
ELSE
QUEUE TO SKILLSET skillb
END IF

This will ensure that skilla only gets calls if it has a greater number of idle agents than skillb. In this example skillb will be the primary target for ansering calls and in the event of a queue calls will queue against skillb.

Instead of greater than you could apply whatever arithmetic/calculation you like.