Brian West
2003-Aug-09 12:06 UTC
[Asterisk-Users] app_queue, fewestcalls and leastrecent logic
First of all I would like to thank Mark for getting roundrobin to go roundrobin. Good job. Now we have some options here for leastrecent and fewestcalls strategy. It needs some work on the logic and Mark recommend that I ask the list and get some input before he makes any changes to it. fewestcalls from what I have seen would always ring the agent with the fewestcalls first then go into roundrobin if that agent didn't answer. Next new caller would ring fewestcalls agent first then start roundrobin. What do you think should happen in fewestcalls? Right now it just rings the agent with the fewestcalls over and over with current app_queue logic. leastrecent from what I have been looking at will ring the agent that has least recently take a call first then if they don't answer go into roundrobin. Then the next new call coming from queue would first go to the leastrecent first then try every agent in roundrobin till answered then starting over again. New caller from queue hits leastrecent agent first. Same thing happens in leastrecent strategy. The leastrecent agent will ring over and over with current app_queue logic. Now some of you might recommend autologoff options. But that also might need some work. I don't want to log off an agent for not answering the phone only once. So here is how I would like to see autologoff work. Example: queue timeout = 20 agent autologoff = 60 The agent would have to not answer their phone 3 times in a row to get logged off. As it stands now they did not answer just once and get logged off. Thus allow for an employee to use the excuse for not working when they should be logged in and taking calls. Unless i'm wrong here. Please post your input on these options and how you would like them to see them function function. Thanks, Brian CWIS Internet Services
Simon Woodhead
2003-Aug-09 12:30 UTC
[Asterisk-Users] app_queue, fewestcalls and leastrecent logic
Hiya, First off, thanks to everyone involved in app_queue. Its a great addition to an already great system. For my two penneth (or cents!), I think the following would be good: - the fallback method should be optional if at all possible, so it can be set up for, say, fewest calls with ring all as the fallback rather than roundrobin. - it would also be good to have no fall-back at all but to stay in fewestcalls / leastrecent mode such that if the no. 1 in the league of fewestcalls / leastrecent calls doesn't answer, it goes on to no. 2, then 3 etc. etc. The second one may actually be how you see roundrobin working as I'm a little confused as to how it actually works in queue scenarios. I've only ever used for passing unanswered calls to a specific extensions to other members of the workgroup. In a queue scenario, what order does it rotate? Will the same person always be the first and the order thereafter always the same? W ----- Original Message ----- From: "Brian West" <brian@bkw.org> To: <asterisk-users@lists.digium.com> Sent: Saturday, August 09, 2003 8:06 PM Subject: [Asterisk-Users] app_queue, fewestcalls and leastrecent logic First of all I would like to thank Mark for getting roundrobin to go roundrobin. Good job. Now we have some options here for leastrecent and fewestcalls strategy. It needs some work on the logic and Mark recommend that I ask the list and get some input before he makes any changes to it. fewestcalls from what I have seen would always ring the agent with the fewestcalls first then go into roundrobin if that agent didn't answer. Next new caller would ring fewestcalls agent first then start roundrobin. What do you think should happen in fewestcalls? Right now it just rings the agent with the fewestcalls over and over with current app_queue logic. leastrecent from what I have been looking at will ring the agent that has least recently take a call first then if they don't answer go into roundrobin. Then the next new call coming from queue would first go to the leastrecent first then try every agent in roundrobin till answered then starting over again. New caller from queue hits leastrecent agent first. Same thing happens in leastrecent strategy. The leastrecent agent will ring over and over with current app_queue logic. Now some of you might recommend autologoff options. But that also might need some work. I don't want to log off an agent for not answering the phone only once. So here is how I would like to see autologoff work. Example: queue timeout = 20 agent autologoff = 60 The agent would have to not answer their phone 3 times in a row to get logged off. As it stands now they did not answer just once and get logged off. Thus allow for an employee to use the excuse for not working when they should be logged in and taking calls. Unless i'm wrong here. Please post your input on these options and how you would like them to see them function function. Thanks, Brian CWIS Internet Services _______________________________________________ Asterisk-Users mailing list Asterisk-Users@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-users
Hi, We have our * box configured to receive inbound SIP calls from FWD and enter into an autoattendant where someone can enter an extension directly. However, the inbound DTMF is not being correctly detected in most cases. Entering 8050 results in a correct detection, but enter 9003 results in only 90 being detected. Entering 700 results in 70 being detected. 799=79, etc. It appears that repeated digits do not get detected. 8750 works, but 999 results in only 9 being detected. Has anyone else experienced this problem? We are using X-lite as the client on the FWD side to test.
Richard Lyman
2003-Aug-10 11:56 UTC
[Asterisk-Users] app_queue, fewestcalls and leastrecent logic
well if you ask me, the leastrecent part would work if you reversed the logic on the metric. my other last_used mod would do a time_t on that agent the last time it was 'tried' (ast_request'd) then (i was using arrays) qsort so that (new agents) '0' would be on top, and the agent that got the most recent attempt would be on the bottom '1057174447' (below is an example) -- sorted agent array: 317 last_used: 0 -- sorted agent array: 318 last_used: 0 -- sorted agent array: 319 last_used: 0 -- sorted agent array: 300 last_used: 1057174447 that way, (for leastrecent anyway), you are always working with a full stack of agents. Brian West wrote:>First of all I would like to thank Mark for getting roundrobin to go >roundrobin. Good job. > >Now we have some options here for leastrecent and fewestcalls strategy. It >needs some work on the logic and Mark recommend that I ask the list and >get some input before he makes any changes to it. > >fewestcalls from what I have seen would always ring the agent with the >fewestcalls first then go into roundrobin if that agent didn't answer. > >Next new caller would ring fewestcalls agent first then start roundrobin. > >What do you think should happen in fewestcalls? Right now it just rings >the agent with the fewestcalls over and over with current app_queue logic. > >leastrecent from what I have been looking at will ring the agent that has >least recently take a call first then if they don't answer go into >roundrobin. Then the next new call coming from queue would first go to >the leastrecent first then try every agent in roundrobin till answered >then starting over again. New caller from queue hits leastrecent agent >first. > >Same thing happens in leastrecent strategy. The leastrecent agent will >ring over and over with current app_queue logic. > >Now some of you might recommend autologoff options. But that also might >need some work. I don't want to log off an agent for not answering the >phone only once. So here is how I would like to see autologoff work. > >Example: >queue timeout = 20 >agent autologoff = 60 > >The agent would have to not answer their phone 3 times in a row to get >logged off. As it stands now they did not answer just once and get logged >off. Thus allow for an employee to use the excuse for not working when >they should be logged in and taking calls. > >Unless i'm wrong here. > >Please post your input on these options and how you would like them to see >them function function. > >Thanks, >Brian >CWIS Internet Services > > >_______________________________________________ >Asterisk-Users mailing list >Asterisk-Users@lists.digium.com >http://lists.digium.com/mailman/listinfo/asterisk-users > > >
Adam Goryachev
2003-Aug-11 02:44 UTC
[Asterisk-Users] app_queue, fewestcalls and leastrecent logic
> First of all I would like to thank Mark for getting roundrobin to go > roundrobin. Good job.Exactly, the whole queue system seems significantly better than it was not so long ago. Thank very much!> Now we have some options here for leastrecent and fewestcalls strategy. It > needs some work on the logic and Mark recommend that I ask the list and > get some input before he makes any changes to it.IMHO, leastrecent and fewestcalls should order the 'queue' based on those parameters. The members of the queue should be called in that order. (Of course, the priority parameter should be respected first though). Now, roundrobin should work by always ordering the members in the same order, but the next interface it tries is always one after the previous one it tried. We should also have a type of 'ordered' or similar, which is like roundrobin but always starts from the same spot. (eg, always call the receptionist first, then overflow to the accounts person, and then the marketing person etc...> Now some of you might recommend autologoff options. But that also might > need some work. I don't want to log off an agent for not answering the > phone only once. So here is how I would like to see autologoff work. > > Example: > queue timeout = 20 > agent autologoff = 60 > > The agent would have to not answer their phone 3 times in a row to get > logged off. As it stands now they did not answer just once and get logged > off. Thus allow for an employee to use the excuse for not working when > they should be logged in and taking calls. > > Unless i'm wrong here.This sounds very nice, but perhaps there should also be some sort of indicator to the user that they have been logged off. If you forget to logoff before you go to the toilet, you come back, and start doing 'stuff' while you wait for some calls to arrive and don't realise you have been logged off. Some options: a) Send them an email when they are auto-logged off (a lot of 'agents' may not have an email account) b) Send them a voicemail when they are auto-logged off (might have MWI which provides a visual indicator that you have been logged off) c) Don't actually log them off, just ignore their extension for a configurable amount of time. This might even re-act similar to qmail's logarithmic back-off retry times. ie, suspend for 10 minutes, then retry, suspend for 30 minutes, retry, suspend for 1 hour, etc... (need a way to log back on tho) d) Should also log to cdr when someone is auto-logged off, this way reporting will show that agent 232 is lazy and never answers the phone, resulting in always being logged off .... Other people with more experience in a call centre might have other ideas on notification methods... Regards, Adam
McAughan, Matt
2003-Aug-12 05:30 UTC
[Asterisk-Users] app_queue, fewestcalls and leastrecent logic
Most idle or longest idle should have nothing to do with how long your last call was, or total call time. Longest idle is supposed to be the agent who has been sitting there the longest since the last call was taken. Now if your an agent that gets the 5 minute calls well then your just the lucky one. Or someone needs to tell your friends to stop calling! If your taking 3 hour calls someone needs to teach the agent how to wrap things up and close the sell, or again tell your friends to stop calling! ;) But with longest idle at least everyone gets an equal amount of "off the phone" time, not an equal amount of "on the phone" time. -----Original Message----- From: Richard Lyman To: asterisk-users@lists.digium.com Sent: 8/12/03 1:29 AM Subject: Re: [Asterisk-Users] app_queue, fewestcalls and leastrecent logic ok and what happens when agentA in on a 3 hour call? once again i think this type of 'senario' should be covered by 'in house' policy.. not some super queue tweek <G> Brian West wrote:>Ok just had my boss point something out: > >"I'd think dumping calls on most-idle would be fairly straightforward,but>could be skewed if agentA is on a 40 minute call, agentB has a bunch of5>minute calls" > >So total call time should be counted in the logic somewhere. > >bkw > >On Sun, 10 Aug 2003, Brian West wrote: > > > >>I think we are starting to see what type of logic people are wantingin>>fewestcalls and leastrecent strategy. >> >>bkw >> >>On Sun, 10 Aug 2003, Richard Lyman wrote: >> >> >> >>>i disagree, instead of thinking 'fallback' how about 'order' theagents>>>(by effecting the 'metric') so you 'target' the agent you want first >>>then if fail they go right to the next one in the 'ordered' list. >>> >>>Brian West wrote: >>> >>> >>> >>>>leastrecent suffers the same fait as fewestcalls onlying ringing the >>>>leastrecent agent over and over endlessly. It should have afallback>>>>option. >>>> >>>>roundrobin with leastrecent first >>>>roundrobin with fewestcalls first >>>> >>>>I would like to see a roundrobin with leastbusy first option. >>>>(just because you have taken less call or leastrecent doesn't meanyou>>>>haven't been a busy agent!) >>>> >>>>I'm sure better autologoff logic as per my first email would be agreat>>>>idea also. >>>> >>>>bkw >>>> >>>>On Sun, 10 Aug 2003, Richard Lyman wrote: >>>> >>>> >>>> >>>> >>>> >>>>>well if you ask me, the leastrecent part would work if you reversedthe>>>>>logic on the metric. >>>>> >>>>>my other last_used mod would do a time_t on that agent the lasttime it>>>>>was 'tried' (ast_request'd) then (i was using arrays) qsort so that(new>>>>>agents) '0' would be on top, and the agent that got the most recent >>>>>attempt would be on the bottom '1057174447' (below is an example) >>>>> >>>>> -- sorted agent array: 317 last_used: 0 >>>>> -- sorted agent array: 318 last_used: 0 >>>>> -- sorted agent array: 319 last_used: 0 >>>>> -- sorted agent array: 300 last_used: 1057174447 >>>>> >>>>>that way, (for leastrecent anyway), you are always working with afull stack of agents.>>>>> >>>>> >>>>> >>>>>Brian West wrote: >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>>First of all I would like to thank Mark for getting roundrobin togo>>>>>>roundrobin. Good job. >>>>>> >>>>>>Now we have some options here for leastrecent and fewestcallsstrategy. It>>>>>>needs some work on the logic and Mark recommend that I ask thelist and>>>>>>get some input before he makes any changes to it. >>>>>> >>>>>>fewestcalls from what I have seen would always ring the agent withthe>>>>>>fewestcalls first then go into roundrobin if that agent didn'tanswer.>>>>>> >>>>>>Next new caller would ring fewestcalls agent first then startroundrobin.>>>>>> >>>>>>What do you think should happen in fewestcalls? Right now it justrings>>>>>>the agent with the fewestcalls over and over with currentapp_queue logic.>>>>>> >>>>>>leastrecent from what I have been looking at will ring the agentthat has>>>>>>least recently take a call first then if they don't answer go into >>>>>>roundrobin. Then the next new call coming from queue would firstgo to>>>>>>the leastrecent first then try every agent in roundrobin tillanswered>>>>>>then starting over again. New caller from queue hits leastrecentagent>>>>>>first. >>>>>> >>>>>>Same thing happens in leastrecent strategy. The leastrecent agentwill>>>>>>ring over and over with current app_queue logic. >>>>>> >>>>>>Now some of you might recommend autologoff options. But that alsomight>>>>>>need some work. I don't want to log off an agent for notanswering the>>>>>>phone only once. So here is how I would like to see autologoffwork.>>>>>> >>>>>>Example: >>>>>>queue timeout = 20 >>>>>>agent autologoff = 60 >>>>>> >>>>>>The agent would have to not answer their phone 3 times in a row toget>>>>>>logged off. As it stands now they did not answer just once andget logged>>>>>>off. Thus allow for an employee to use the excuse for not workingwhen>>>>>>they should be logged in and taking calls. >>>>>> >>>>>>Unless i'm wrong here. >>>>>> >>>>>>Please post your input on these options and how you would likethem to see>>>>>>them function function. >>>>>> >>>>>>Thanks, >>>>>>Brian >>>>>>CWIS Internet Services >>>>>> >>>>>> >>>>>>_______________________________________________ >>>>>>Asterisk-Users mailing list >>>>>>Asterisk-Users@lists.digium.com >>>>>>http://lists.digium.com/mailman/listinfo/asterisk-users >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>_______________________________________________ >>>>>Asterisk-Users mailing list >>>>>Asterisk-Users@lists.digium.com >>>>>http://lists.digium.com/mailman/listinfo/asterisk-users >>>>> >>>>> >>>>> >>>>> >>>>> >>>>_______________________________________________ >>>>Asterisk-Users mailing list >>>>Asterisk-Users@lists.digium.com >>>>http://lists.digium.com/mailman/listinfo/asterisk-users >>>> >>>> >>>> >>>> >>>> >>>_______________________________________________ >>>Asterisk-Users mailing list >>>Asterisk-Users@lists.digium.com >>>http://lists.digium.com/mailman/listinfo/asterisk-users >>> >>> >>> >>_______________________________________________ >>Asterisk-Users mailing list >>Asterisk-Users@lists.digium.com >>http://lists.digium.com/mailman/listinfo/asterisk-users >> >> >> >_______________________________________________ >Asterisk-Users mailing list >Asterisk-Users@lists.digium.com >http://lists.digium.com/mailman/listinfo/asterisk-users > > >_______________________________________________ Asterisk-Users mailing list Asterisk-Users@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-users -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.digium.com/pipermail/asterisk-users/attachments/20030812/8216fc26/attachment.htm