I'm trying to decide on the best place to stick some code that is going to modify (or take over) how calls are being routed via ACD based on some decisions made on customer profile/historical data. I'm looking at doing so in CustomACDInitiateProcessing. Would this be the most appropriate place to do so?

Usually in CustomIVRWorkgroupQueue, and do the ACD Initiate Processing from there, since you need to assign skills and categories, etc. before transferring into the ACD processing.

Originally posted by GGanahl;34731
Usually in CustomIVRWorkgroupQueue, and do the ACD Initiate Processing from there, since you need to assign skills and categories, etc. before transferring into the ACD processing.

Good to know, thanks. Could you tell me where in the handler call stack CustomIVRWorkgroupQueue comes? I've never seen a diagram of ACD call flow, so it would be handy :)

Yeah...handler maps...old-timers remember when we used to have those in the help. CustomIVRWorkgroupQueue is in SystemIVRWorkGroupQueueAlert. Just before it goes back to Interaction Attendant for standard ACD processing. CustomIVRWorkgroupQueue is for use with Custom workgroups. You need to make sure to set p_bTransferred to True right after the ACD Initiate Processing.

Originally posted by GGanahl;34734
Yeah...handler maps...old-timers remember when we used to have those in the help. CustomIVRWorkgroupQueue is in SystemIVRWorkGroupQueueAlert. Just before it goes back to Interaction Attendant for standard ACD processing. CustomIVRWorkgroupQueue is for use with Custom workgroups. You need to make sure to set p_bTransferred to True right after the ACD Initiate Processing.

Thanks! But... now I'm more confused. Attendant is responsible for dealing with ACD processing, not Interaction Processor?

You have to specifically configure everything to kick off the ACD processing properly. Now, I should have asked you more about what you are trying to accomplish. Does it involve setting skills or something to influence which agent will get assigned the call, or is it trying to decide which workgroup gets the call?

Originally posted by GGanahl;34737
You have to specifically configure everything to kick off the ACD processing properly. Now, I should have asked you more about what you are trying to accomplish. Does it involve setting skills or something to influence which agent will get assigned the call, or is it trying to decide which workgroup gets the call?

It may involve one, both or neither :) One processing path will assign a skill to the interaction, and another will specify a target workgroup, and both or neither may be followed depending on influencing factors.

Ok, I guess I should have explained a bit more. My apologies! Quick ACD lesson... ACDServer is the subsystem which actually does all the decision-making, based upon the settings passed to it by Interaction processor from the ACD Initiate Processing tool step. There are two basic types of ACD workgroups, ACD and Custom. For an ACD workgroup, you can set everything up in Interaction Attendant...but Attendant merely passes those settings along to ACDServer via Handlers (which form the basis for all Attendant processing). The settings in Attendant that have a "Q" on the toolbar icon (like Queue Audio) do not get overridden when using a Custom workgroup and CustomIVRWorkgroupQueue as the customization point. Only Skills and Priority get wiped out by the custom functionality. Now, getting back to CustomACDInitiateProcessing...that subroutine is used in the Interaction Attendant handler paths...but it is called from 9 different other handlers, so you will have to analyze exactly how that will affect your handling of calls for all the different scenarios. That's a long response. I went for the too short one at first, but it's still probably valid to avoid complexity, presuming you're willing to go the route of Custom workgroup for the Skills and Priority...

Originally posted by GGanahl;34739
Ok, I guess I should have explained a bit more. My apologies! Quick ACD lesson... ACDServer is the subsystem which actually does all the decision-making, based upon the settings passed to it by Interaction processor from the ACD Initiate Processing tool step. There are two basic types of ACD workgroups, ACD and Custom. For an ACD workgroup, you can set everything up in Interaction Attendant...but Attendant merely passes those settings along to ACDServer via Handlers (which form the basis for all Attendant processing). The settings in Attendant that have a "Q" on the toolbar icon (like Queue Audio) do not get overridden when using a Custom workgroup and CustomIVRWorkgroupQueue as the customization point. Only Skills and Priority get wiped out by the custom functionality. Now, getting back to CustomACDInitiateProcessing...that subroutine is used in the Interaction Attendant handler paths...but it is called from 9 different other handlers, so you will have to analyze exactly how that will affect your handling of calls for all the different scenarios. That's a long response. I went for the too short one at first, but it's still probably valid to avoid complexity, presuming you're willing to go the route of Custom workgroup for the Skills and Priority...

Right, that's clearer, thanks! The custom processing I'm putting together should occur for every interaction that passes thru the system, so the fact that other handlers touch on CustomACDInitiateProcessing as opposed to just Attendant and CustomIVRWorkgroupQueue is actually a plus in this situation. So if I plug this into CustomACDInitiateProcessing, then every interaction should be subject to it, correct? And I should be able to assign skills, change the target workgroup queue, agent queue, etc. And if so, I shouldn't have to use the Acd Initiate Processing tool, since CustomACDInitiateProcessing precedes that anyway, yes? If I am going to assign it to another workgroup queue or a specific agent queue in CustomACDInitiateProcessing, what would be the best method to do so at this point in processing?

With the ability in newer versions of CIC to set the queue, skills, priority, etc. dynamically by attribute in Attendant, it is possible to use the customization point to perform its logical steps and set the attribute values to the call and then still perform ACD processing in Attendant (allows for easier call flow management).

Hi, I figured I'd pitch in as well! Any chance you could give us a full overview of what it is you are actually trying to achieve? Are your decisions based on caller input or call-center metrics? Maybe you are referring to a database? Can you talk us through two or three typical calls and how you would handle each / change your routing? I used to work with George in Education and I lost count of the number of times that a question about how to do something fairly specific was raised in class, which upon further investigation turned out to be a completely different question! As you have seen, there are many customization points to choose from, if using a Handler. Add to this that many common Handler-based solutions have been rolled into the base product, or at least provided for (a good example is the ability to use attributes to dynamically allocate Workgroups etc., as pointed out by dcurrier. Another is the ability to change Skills as a call waits in the queue.) You may well find that what you are trying to do is actually provided for (at least in part, if not fully) by the base product and not require such extensive (or maybe even any) Handler work. The less you have to custom-code, the less you have to support and the smaller the risk of it all going horribly wrong (either immediately, or after an update.)

Originally posted by Wierdbeard65;34750
Hi, I figured I'd pitch in as well! Any chance you could give us a full overview of what it is you are actually trying to achieve? Are your decisions based on caller input or call-center metrics? Maybe you are referring to a database? Can you talk us through two or three typical calls and how you would handle each / change your routing? I used to work with George in Education and I lost count of the number of times that a question about how to do something fairly specific was raised in class, which upon further investigation turned out to be a completely different question! As you have seen, there are many customization points to choose from, if using a Handler. Add to this that many common Handler-based solutions have been rolled into the base product, or at least provided for (a good example is the ability to use attributes to dynamically allocate Workgroups etc., as pointed out by dcurrier. Another is the ability to change Skills as a call waits in the queue.) You may well find that what you are trying to do is actually provided for (at least in part, if not fully) by the base product and not require such extensive (or maybe even any) Handler work. The less you have to custom-code, the less you have to support and the smaller the risk of it all going horribly wrong (either immediately, or after an update.)

Thanks for the pitch, Wierd! I'd very much prefer to use out of the box functionality whenever possible, as reinventing the wheel is always painful and wasteful. The lack of documentation for higher level data flow and design is a huge hindrance, however. Here's the more in depth skinny, then: The company is going to be using ININ as a work distribution platform - calls, SMS, email, fax, Salesforce profiles, documents, etc. Work item distribution will need to be tailored programmatically based on a large number of factors such as the calculated value of piece of work, the customer and QA ratings of an agent along various dimensions, work status vis a vis business process as tracked in various CRMs, work processing as a function of what points have previously been visited in ININ processing (eg, is this the second time a call has been transferred to a workgroup during the life of the call?), etc. Data sources include caller input DTMF, database dips, CRM API calls and agent actions via Desktop. Some simple use cases include (a) determining which agents are currently at work (regardless of other status) and ranking them on a curve for caller survey ratings in order to prioritize those agents for receiving high value callers, (b) examining the status of a caller in a CRM + determining the agent(s) assigned to their profile + assess where the caller is in the business process flow indicated by the CRM and IVR DTMF responses + determine whether the relevant agent(s) can take calls right now in order to route the call most effectively (eg, to the relevant agent(s) voicemail, directly to the relevant agent(s), or to a more general queue). The current strategy involves calling a handler based assessment engine from Attendant or other handlers, passing along relevant details and data for a work item. The engine then evaluates the work item details as per business process rules and sets various attributes for the work item. Then when the work is queued for assignment (eg, ACD), another handler based distribution engine will be called to evaluate the flags set by the assessment engine as per business process rules, and make any changes necessary to route the work according to the results. This can involve adding a required skill to the call, routing to a particular agent or workgroup, altering ACD factors on the fly, etc.

Ouch! Ok, FWIW, I would go for setting attributes on the call based on what the assessment engine determines. In attendant you could use Logical Transfer operations to filter out between "Send to agent" and "Send to Workgroup" and then, as dcurrier said, use the dynamic abilities of the transfer to Workgroup etc. I did get involved in a situation a while back in Handlers class where the student had a need to route to agents based on account ownership, with contingencies for the agent not being available and also allowance for excluding certain agents based on a perceived conflict of interest. I ended up posting a blog about the solution we came up with. It might give you some ideas! http://blog.inin.com/how-to-targeted-routing-with-custom-acd/#sthash.7J3gQRE5.dpbs Hope that helps :D

Originally posted by Wierdbeard65;34755
Ouch! Ok, FWIW, I would go for setting attributes on the call based on what the assessment engine determines. In attendant you could use Logical Transfer operations to filter out between "Send to agent" and "Send to Workgroup" and then, as dcurrier said, use the dynamic abilities of the transfer to Workgroup etc. I did get involved in a situation a while back in Handlers class where the student had a need to route to agents based on account ownership, with contingencies for the agent not being available and also allowance for excluding certain agents based on a perceived conflict of interest. I ended up posting a blog about the solution we came up with. It might give you some ideas! http://blog.inin.com/how-to-targeted-routing-with-custom-acd/#sthash.7J3gQRE5.dpbs Hope that helps :D

Actually, it's rather a fun project to architect; I've been enjoying that part of it. Using Attendant in order to distribute work is out of the question, however. As I mentioned, this will be used for distributing a wide variety of work items - not just calls. Your example sounds neat, thanks! I've actually implemented something similar to it, using Categories to limit call routing to individual agents or groups of agents. I didn't need to create a one-to-one skill for each agent, as I could just read the agent username from the call attributes. Your example reminds me of a question I can't find an answer to, tho: what, *exactly*, does having a queue of type "Custom" entail? Does regular ACD processing still happen either way, and in the case of "Custom" queues that just means that the "CustomIVRWorkgroupQueue " handler is called as opposed to regular ACD where it is not? The Admin help for "Workgroup has Queue" says "For more information about CustomIVRWorkgroupQueue, see the Interaction Designer Help." but a search thru the help file for Designer produces zero hits for CustomIVRWorkgroupQueue.

Originally posted by samandiriel;34757
Your example reminds me of a question I can't find an answer to, tho: what, *exactly*, does having a queue of type "Custom" entail? Does regular ACD processing still happen either way, and in the case of "Custom" queues that just means that the "CustomIVRWorkgroupQueue " handler is called as opposed to regular ACD where it is not?

You might think that, but no. Having said that, I can only speak from the perspective of Attendant, but I suspect similar effects would be seen elsewhere. If you send a call to a queue of type "ACD" from Attendant, as you know, it uses the default weightings and so on and processes it as an ACD call. If you send it to a queue of type "custom", then the customization point CustomIVRWorkgroupQueue is called. By the time that handler exits, the call is expected to have been dealt with (for example, put into a queue) which you indicate by setting the flag p_bTransferred = true. That flag indicates to the calling handler that it doesn't have to do anything further (as is the case with just about all customization points.) If the flag remains False, then Attendant will realise the call wasn't processed and return you to the menu. This happens quite a bit in class, when students are "playing", change a Workgroup to type "custom" and then can't figure out why their Attendant Labs don't work anymore!

Originally posted by samandiriel;34757
The Admin help for "Workgroup has Queue" says "For more information about CustomIVRWorkgroupQueue, see the Interaction Designer Help." but a search thru the help file for Designer produces zero hits for CustomIVRWorkgroupQueue.

That's what you get for listening to us and trying to RTFM! Seriously, though, I find the Dependancy Viewer in Designer to be a huge help in this kind of situation. You can do a search for the customization point subroutine and see all the handlers that call it. Then go and look at those handlers to see how it is called, when (and what happens afterwards!) HTH

Originally posted by Wierdbeard65;34758
You might think that, but no. Having said that, I can only speak from the perspective of Attendant, but I suspect similar effects would be seen elsewhere. If you send a call to a queue of type "ACD" from Attendant, as you know, it uses the default weightings and so on and processes it as an ACD call. If you send it to a queue of type "custom", then the customization point CustomIVRWorkgroupQueue is called. By the time that handler exits, the call is expected to have been dealt with (for example, put into a queue) which you indicate by setting the flag p_bTransferred = true. That flag indicates to the calling handler that it doesn't have to do anything further (as is the case with just about all customization points.) If the flag remains False, then Attendant will realise the call wasn't processed and return you to the menu. This happens quite a bit in class, when students are "playing", change a Workgroup to type "custom" and then can't figure out why their Attendant Labs don't work anymore! That's what you get for listening to us and trying to RTFM! Seriously, though, I find the Dependancy Viewer in Designer to be a huge help in this kind of situation. You can do a search for the customization point subroutine and see all the handlers that call it. Then go and look at those handlers to see how it is called, when (and what happens afterwards!) HTH

Ah, got it. I remember it being covered in my Attendant class, but it was kind of glossed over :) I have used Dependency Viewer, quite a bit, but it can really only take you so far when one doesn't know what the dependencies listed do either. I'm still hugely annoyed that there is no dictionary anywhere for the couple hundred subroutines in the libraries... why bother showing them in Designer at all, if what they do is impenetrable other than by extensive research and analysis and even then likely to be incomplete? There might be incredibly useful things in there, but there's no way to find out other than by initiating a massively time consuming research project on a third party product that we've already paid for in order to make up for it's documentation deficits... :/

Originally posted by dcurrier;34748
With the ability in newer versions of CIC to set the queue, skills, priority, etc. dynamically by attribute in Attendant, it is possible to use the customization point to perform its logical steps and set the attribute values to the call and then still perform ACD processing in Attendant (allows for easier call flow management).

Unfortunately trying in Attendant to implement the logic required to meet specs is not possible.

Originally posted by GGanahl;34731
Usually in CustomIVRWorkgroupQueue, and do the ACD Initiate Processing from there, since you need to assign skills and categories, etc. before transferring into the ACD processing.

Also: would using the Acd Intiate Processing Tool here interfere with the default ACD processing with all the inputs being defaults? I don't know if there are other apps (Admin? Attendant?) or handlers that might have their intended effects neutered by using the defaults for the inputs for this tool?

Originally posted by GGanahl;34731
Usually in CustomIVRWorkgroupQueue, and do the ACD Initiate Processing from there, since you need to assign skills and categories, etc. before transferring into the ACD processing.

That also begs the question of what is appropriate for CustomACDInitiateProcessing then?