I am trying to use the Query Queue tool step to get a list of call ids in a queue. After I get this list, I want to use the GetAt tool step to retrieve them one at a time and send them to the Query Media Type to determine what type of interaction it is; call, callback, email, chat, etc. But I am not able to get this to work. Do I need to send the List of Call IDs to a string and then parse the string and have the Query Media Type check it then? Or is there a better way of doing this. My idea is to have a handler that checks a queue and reports on how many voicemails, calls, and callbacks are in that queue at that particular time. I think we would find this beneficial if we are about to max out the number of lines we have so we could be proactive before customers or agents get the "No Available Lines" message when attempting to place a call. Thanks, Andrew

I got it working now. Just a few questions still, if this is checking approximately 30 workgroups with the most 300 interactions, will this be detrimental if this handler runs everytime a call comes into the system? Could this be putting more load on the server than its worth? Any suggestions would be greatly appreciated. Thanks, Andrew

Andrew, The thing about handlers that you need to keep in mind is that they are, more or less, an interpreted language much like Java - sure, it gets compiled into a "binary", but it's not really an executable binary, it's just converted to something more efficient for the engine to run with. This, of course, means efficiency is key. With that in mind, every action you take in a handler represents a cost. Having a handler that performs the tasks you mention EVERY time a call comes in would most certainly be detrimental, but to what effect depends on your hardware and average system load - is the IC server virtualized? Is it hosted on its own dedicated hardware? Does it have plenty of RAM? CPU power? Keep in mind it's also your IC server that interprets and executes your handler code. The quickest way to measure these effects is with a "timer" type handler - basically an intermediate handler that begins a timer function, executes your handler, then returns and captures the end timer to give you the difference and thus telling you how long it took to execute your code. Force it to perform the requisite number of steps to get your "realistic" expectation for a single interaction coming in and triggering your handler - then do the same thing with 10 calls hitting your system at once and you'll start getting a real picture of the cost associated with what you're wanting to do. By "requisite number of steps", I mean... if you expect it to run against 300 calls, you can still do this with only one call in the system by simply having it create a completed list of 300 copies of your call ID. What, may I ask, is it you're trying to accomplish? I can almost guarantee there's a simpler, more efficient and effective way to accomplish the same end goal.

There are two things we are trying to accomplish, the first is if we are really deep in queue and are running out of available lines. This makes it hard for the agents to get a line out when making a callback request. My idea was to have this handler run and if the number of connected calls was 10 less than our maximum amount of lines, then they would be automatically sent to a call back request option, this would prevent them from waiting in queue and tying up one of the lines. My second idea for the handler is to have it check our main queues, and if the number of calls waiting in each queue is greater than a number we choose, say X, then it would give this call the ability to over flow to our second call center. Let me give you some perspective on this, currently we have our main call center which handles all the calls, but we have a smaller call center that does more accounting type stuff, but if needed they can take calls. Everyone is a part of the same workgroups, so we have been using the Logical transfer which looks at the calls in the queue and if it is below our threshold, we assign the call a skill named "Main Call Center". All of the agents in the main call center have this skill so they are able to take these calls, while the smaller call center agents do no. If during the logical transfer the number of calls is higher than the threshold, then we do not assign the call the "Main Call Center" skill, which effectively allows the call to be answered by anyone in the main call center or the small call center. The problem we have found with this is that it is not checking the number of calls waiting, but the total number of calls in that workgroup, so we were having calls rollover to the small call center even if there were only 2 calls waiting in the workgroup queue. Please let me know if I need to describe this in more detail. I will definitely look into the timer handler and see what it comes back with. Thanks, Andrew

Could you also give me an example or some guidance on how to create the timer handler? I believe this would definitely be beneficial to have in the future. Thanks, Andrew

Andrew, Whew, what a drive... 2h for 25 miles. Yeesh... Talk about slippery roads! I also see my previous reply hasn't been "approved" by moderators yet, so I'll simply continue as if it has... Maybe they'll get the hint. ;) Anyway... I don't have Designer where I am right now, but... I believe I can provide sufficient description to get you on your way if you're looking at playing with it tonight... Assuming the post goes up tonight, that is... Essentially, you create a "wrapper" handler. Its inputs will match the inputs of your initial handler. Instead of calling your initial handler, you would substitute the wrapper handler - feed the wrapper your inputs and then let the wrapper ultimately call your initial handler with the supplied arguments. In this way, your existing logic remains intact and you can more easily inspect timing elements. Now... Attached to your initiator, you should have an assignment operator assigning the CURRENT time into a DateTime variable. Once you've retrieved this value and stored it, you simply execute the same step on the other side of your handler exit and assign the new CURRENT time into a secondary variable. Then, using the built in date/time operators, you can get the difference in the time. Your series of steps should be fairly similar to this: [Handler Initiator] -> [Assignment->Current Time:dtStartTime] -> [Call to original handler] -> [Assignment->Current Time:dtEndTime] -> [Assignment->Time Difference:dtDifference] -> [Breakpoint] This will tell you how long it takes to execute your handler as you've outlined its design. When you execute the handler in debug mode, just tell it to break on the breakpoint you insert - then inspect the handler variables to see the value just after it completes your routine. IIRC, this will get you down to about 3 decimal places (thousandths of a second), but I'd have to check again as I don't keep all of this in my head all the time. :) Hopefully I've been clear enough, but if you still need an actual example let me know and I'd be happy to create one for you. -Kevin

Andrew, The first can be accomplished on your lines tab within Administrator - just set the maximum inbound calls to 10 less than your maximum available lines - all calls beyond that should be rejected (I think they'll receive a congestion tone on the caller side, I don't recall offhand). [ATTACH]596[/ATTACH] The second can be accomplished completely via Attendant by using Queue Operations, advanced workgroup options and logical transfers. Advanced operations are only available on ACD groups, however. There are other more obscure and undocumented methods to deal with station groups and non-acd workgroups to accomplish things, too. Specifically, you can test for queue statistics via the Logical Transfer step within Attendant, which you're already familiar with but may not have fully explored yet: [ATTACH]597[/ATTACH] Overall though, it seems like your system could benefit from an analysis of your needs and a tailored solution to meet those needs. If you're trying to do things in handlers without taking the more efficient route of Attendant and Queue operations when they're available, I'm curious what else could have been done with the built in tool set that is now done with custom handlers... The company I work for just happens to do those very things, if you are interested. :) Our website can be found here: http://www.emergentnetworks.com/ I hope this helps to save you a few hours of handler work. I know how it feels to spend hours on a handler or set of handlers, only to discover I simply reinvented the proverbial wheel... :) -Kevin P.S. I'll have to write something up when I get a moment to demonstrate the timer function I mention, it's an old trick really. I didn't miss it, I just don't have time to load up Designer just now and bang it out (on my way out the door to go home in this lovely white mess falling from the sky.) :)