by CallCenter702 » Tue Sep 11, 2012 12:32 pm
Thanks for the quick response.
I have thought about using that, but that didn't seem like it fixed my issue. Wouldn't I still be required to choose the number of remote agents I would need at one time? IE if I expect up to 100 calls at one time I still need 100 agents allocated right? Thus tying up resources? Plus they all point to one number in the extension group and I need to diversify my calls over 4 different centers.
Here is how I am set up. DID points to In-group 1 If no agents logged in drop to In-group 2. I have 4 remote agents in this group. Each are allocated a different number of lines (for proportioning the calls) and each have a different extension.
I have found that if I use a "drop to" extension I drop 10% less calls then when using the remote agents. I get a lot of "noagent" 0 time drops even though I have at least 100% more allocated than what I need. (I have also tried allocating the exact amount with same results). It seems the system doesn't like to forward so many calls over those multiple agents. The one good thing though is that with multiple agents and line allocation I can fraction the calls proportionality to the other call centers. IE if I get 100 calls I know I can set remote agent 1, to 10 lines and they will receive 10% of the calls, remote agent 2, to 25 line, 25%, etc.
In a perfect world I guess I would need remote agents that act as "drop to" extension (where you don't have to allocate the number of lines) but also be able to chose the percentage of calls that agent will receive.
Or a setting like this on the in-group
No agent no queue Action: Multiple Extensions
Extension 1 _________ call % 10
Extension 2 _________ Call % 50
Extension 3 _________ Call % 35
Extension 4 _________ Call % 5%
Etc.
But this would also need to show in the reporting. I notice if I do drop to extension everything becomes a transfer. And I can't load up the drops to call them back. But with the remote agents I do get all the system statuses, but then I incur the large % of drops and system load issues.
Let me know if you think there is an option around this or what you think this would cost to be implemented. Thanks!