QueueMetrics > Improving QueueMetrics

Checks on Add Member

(1/2) > >>

mudslide567:
It would be REALLY good to have a validity check on the Add Member [& Remeove Member] functionality for agents that are hot desking.  Specifically, we need to have a check on the validity of the extension they are entering [or else make the extension selection a select box from valid extensions]. 

Here is the issue:  I have an agent  who sits down and logs in etc ...gets to add member and instead of typing '6008' for the extension on her desk, she types in '6088'.  The program executes the relevant part of the dial plan and "Local/6088@from-internal/n" gets added to 5 [out of a total of 13 queues].  There is no extension 6088.  Realizing her error [because she gets no calls as well as the fact that we have a script that pushes "Agent XXX logged in" to the phone's LCD display] she hits Add Member again using the correct '6008'.... so now the queue has two entries, one bogus.  The queue has "leastrecent" ring strategy with autofill.  Now two calls come in...first goes to 6088 where nothing happens, while second call gets answered at 6008.  Now 6088 is seen as first priority under least recent algorithm because it has not answered a call, the first call keeps retrying 6088 first while calls keep sliding by... angry client and wasted server resources. 

We cannot prevent every error but we should be able to prevent entry of non existent extensions.  I have other examples of unthinking/untrained agents [they enter the agent code as the extension etc...]

QueueMetrics:
The problem is interesting - how do we address that? we specify a default extension per agent?

mudslide567:
I had not thought of that but I think that sounds like a very good idea!  I was originally thinking of having the extension selection made from a select box rather than a text field, where the select box might come from an extensions table in the database... maybe like the queues and agents, the extensions could start with a wizard filler tool from the dial plan [of course I see the problem that different distributions keep extension data in different files]. ... but you idea of a default extension would be a good start!

QueueMetrics:
Yes one could enter the default extension. or leave it blank if one wants the current behavior.

itcanadian:
I've run into this very thing, and the default extension poplating only works if users don't hotdesk.  In the case of users who change desks, and extensions, a default extension results in agents joining a queue from the wrong extension, and calls are then routed and unanswered affecting queue times.

Navigation

[0] Message Index

[#] Next page