<html><body><span style="font-family:Verdana; color:#000000; font-size:10pt;"><div>I've worked with a few of these commercial systems, so let me provide my perspective. Or just skip to the end for my solution. Disclaimer: I am not an expert with all things mod_fifo can do.</div>
<div> </div>
<div>First, I don't like the idea of using the work "skill" because I am one of those in the camp that the work to predict the specific needs of a incoming call is not worth it. However, the general concept of queueing callers in buckets is very useful.</div>
<div> </div>
<div>In general "skill"-based ACD has two parts, a series of buckets that callers are funneled into based on their issue, and a collection of agents that have knowledge in or can assist with issues in one or more buckets. From what I've seen, a true ACD needs to go beyond this. Some common issues are:</div>
<div><STRONG></STRONG> </div>
<div><STRONG>How the caller is treated while on hold</STRONG></div>
<div>What happens while a caller is waiting to speak to an attendant. Popular things are to play music, announce their position in the queue or estimate their time before being answered, and interrupt music with one or more advertisements for products. </div>
<div> </div>
<div>using mod_fifo: There is of course the ability to play music or other audio. However, I remember reading once that FS loads the entire audio file in memory during playback (my knowledge may be outdated here) which may be a resource issue with lots of callers and large audio files. Regardless, if I want to play some music, then play an ad, more music, ad, etc. I have two options. either string all the audio together in one large file and loop it, or break the caller out of the queue and re-add them with the next audio clip. The latter option risks losing their position in the queue (again, not sure, never tried the option).</div>
<div> </div>
<div><STRONG>How the caller is prioritized into the queue</STRONG></div>
<div>Many customers have simple straight-forward requirements as to allocating callers into buckets. Some, however have complex decision processes that may take into account the customer's support SLA, time of day, number of agents on duty, how many times they've called in the last X days, the particular issues they are having, the state of the company/systems. In practice every customer's requirement is simple logic, but different from every other customer.</div>
<div> </div>
<div>using mod_fifo: the 10 buckets that you can allocate callers to will be great for the simple cases. Although one could make an arguement for more buckets. The more complex cases could be handled by pre-calculating the priority using a scripiting language then placing them in a bucket, however that does not account for the situation where the caller's priority might change as theiy are waiting (One SLA required that if a caller waited more that 10 minutes, they were immediately bumped to a level 2 tech support engineer).</div>
<div><STRONG></STRONG> </div>
<div><STRONG>Which queues the agents can accept calls from</STRONG></div>
<div>This is easier to deal with, in most of the cases the agents have a set knowledge set, and will take calls from a set number of buckets. But there are a few gotchas. One example is the level 2 support agent that knows product A and B. Does he pull calls buckets A-2, B-2, A-1, B-1 or from buckets A-2, A-1, B-2, B-1 The answer may depend on how many calls are in each of the buckets at the time </div>
<div> </div>
<div>using mod_fifo: Again, the 10 buckets and assigning agents to multiple buckets works great for the simple cases, the more advanced cases however are not supported directly, and will require scripting.</div>
<div> </div>
<div><STRONG>Number of agents active so all calls are answered</STRONG></div>
<div>Agents-to-buckets is one issue, Agent availablity is also a question. Part of this is actually a staff forcasting problem. But many commercial ACDs will provide reporting, if not out-right do this activity. I've even seen some systems that will tell the agents when to take lunches/breaks based on active call volume and historical information.</div>
<div> </div>
<div>using mod_fifo: There are a few variable that will asist with this type of reporting but nothing that will actual assist in doing the work of determining staffing and scheduling breaks. One can make a very valid arguement that this really isn't the switch's problem. But, customers do ask for it, and the more you can do with the least number of systems, the more you are likely to win a bid.</div>
<div> </div>
<div><STRONG>My Solution </STRONG></div>
<div>I sat down to answer this thread because it touches on a larger question. Where does the switch stop and the application begin. FS can do a great many things, but in my opinion, some of the modules and capabilties go beyond what a switch would do and are more of what a telephony application should do. Looking at the architecture of FS I see four methods for implementing a feature:</div>
<div>1. write it into the switch core </div>
<div>2. write a module to be loaded into FS address space</div>
<div>3. write a script to be executed on a channel</div>
<div>4. write an external application that uses ESL to control FS and it's channels</div>
<div> </div>
<div>Some features have very obvious choices for which method to use, like bridge two channels (#1) or CDR geneation (#2). Others, like IVR systems can work equally well as 2, 3, or 4.</div>
<div> </div>
<div>In my view FS is a switch, and anything that is not CORE to the switch's operation should not be in it's address space. Therefore I would place an ACD system as #3 or #4. Looking only at those two options, to provide a universal solution, #3 is far more promising, as working with #4 requires the end implementer to lock into to whichever framework, language, libraries, etc that you used to implement ESL.</div>
<div> </div>
<div>Thus, if there is an interest in creating a "professional" ACD system (don't get me wrong, there are a lot of bad systems that still cost lots of money). The way to go would be to gather the requirements from those users that are interested in one, compare existing solutions from "the big boys" and create a script-based solution that meets the requirements, is expandable, well-documented and available for end implementers to tweak.</div>
<div> </div>
<div>Specifically, the ACD should remove the concept of "buckets", each caller should be placed into a script that loops whatever the company desires as long they are waiting. This may be as simple as a script that streams an audio field, or something more complex that looks at a customers account and plays an ad targeted for them. As each agent becomes available, a "selection logic" should be executed that looks at the agents capabilities, the current queue, and the rules of the company and selected the next caller for that agent. Proper entry points and coding practices will allow an end user to customize on-hold script and selection logic with minimal effort. A db-agnostic set of SQL can be generated for the necessary storage or active callers, users, etc.</div>
<div> </div>
<div>This solution methodology can be expanded to cover many aspects/features that users are looking for in FS. I have created LUA libraries to ease many common tasks in FS such as ASR/TTS integration, DB access, data processing (CSV, JSON, XML, etc). I am working on getting those libraries released to the FS contrib project for those that need them (really its a matter of finishing the documentation).</div>
<div> </div>
<div>Personally, I use FS at my day-job, but working on these kind of "challenges" is what I do for fun (well, that and Rock Band) I will offer my LUA coding and Product Management skills to anyone that has requirements they are looking to get implemented, as long as the end result is generally useful and released back to the FS community. In fact it might be useful to create a section of the FS Jira for larger projects like this as well as some of the bounty projects listed in the wiki, as a means of collaberation. That way we can aggregate requirements from many people. </div>
<div> </div>
<div>-pete</div>
<div> </div>
<div> </div>
<BLOCKQUOTE style="BORDER-LEFT: blue 2px solid; PADDING-LEFT: 8px; FONT-FAMILY: verdana; COLOR: black; MARGIN-LEFT: 8px; FONT-SIZE: 10pt" webmail="1">
<div >-------- Original Message --------<BR>Subject: Re: [Freeswitch-users] skill-based ACD<BR>From: Michael Collins <msc@freeswitch.org><BR>Date: Thu, September 17, 2009 4:22 pm<BR>To: freeswitch-users@lists.freeswitch.org<BR><BR><BR><BR>
<DIV class=gmail_quote>On Thu, Sep 17, 2009 at 4:13 PM, Phillip Jones <FONT dir=ltr><<A onclick="return true;if(window.location==top.location){Popup.composeWindow('pcompose.php?sendto=pjintheusa%40gmail.com');}else{top.Popup.composeWindow('pcompose.php?sendto=pjintheusa%40gmail.com');}; return false;" href="mailto:pjintheusa@gmail.com" target=_blank mce_href="mailto:pjintheusa@gmail.com">pjintheusa@gmail.com</A>></FONT> wrote:<BR>
<BLOCKQUOTE style="BORDER-LEFT: rgb(204,204,204) 1px solid; MARGIN: 0pt 0pt 0pt 0.8ex; PADDING-LEFT: 1ex" class=gmail_quote>
<DIV>I would be interested in this too....</DIV>
<DIV><BR></DIV>Concerning mod_fifo - can you restrict an agent to a slot. So lets say DNIS A is for product A and DNIS B product B - some agents know both - some know just 1 product - would that be possible?
<DIV><BR></DIV></BLOCKQUOTE>
<DIV><BR>Per Tony's post:<BR><BR>when you assign an agent to take calls off hook you can set a fifo_pop_order variable that tells you which array indexes to service and in what order.<BR>so if you pretend slot 1 is for general problems and slot 2 is for hard problems you can put one agent in 1,2 and a more stupid agent in just 1 <BR></DIV></DIV><BR>So it's a matter of setting up the routing on the calls and the priorities that the agents are allowed to answer.<BR>-MC<BR>
<HR>
_______________________________________________<BR>FreeSWITCH-users mailing list<BR>FreeSWITCH-users@lists.freeswitch.org<BR><a href="http://lists.freeswitch.org/mailman/listinfo/freeswitch-users" target=_blank mce_href="http://lists.freeswitch.org/mailman/listinfo/freeswitch-users">http://lists.freeswitch.org/mailman/listinfo/freeswitch-users</a><BR>UNSUBSCRIBE:<a href="http://lists.freeswitch.org/mailman/options/freeswitch-users" target=_blank mce_href="http://lists.freeswitch.org/mailman/options/freeswitch-users">http://lists.freeswitch.org/mailman/options/freeswitch-users</a><BR><a href="http://www.freeswitch.org/" target=_blank mce_href="http://www.freeswitch.org">http://www.freeswitch.org</a><BR></DIV></BLOCKQUOTE></span></body></html>