Skip to main content

Agent configuration for queues

Posted by andrewyager on Wed, 08/13/2008

Hi,

As far as I can tell, the default agent implementation registers extensions at the local-extensions context.

This means that agents obey individual extensions preferences for voicemail, which is bad in a call centre environment.

We've switched over to a dynamic queue member structure, which works much better; but is there a standard way of avoiding this problem?

Thanks,
Andrew


Submitted by thirdlane on Wed, 08/13/2008 Permalink

Hi Andrew,

We are just about to change the way we handle queues/agents.

Please send your suggestions (and configuration files) my way.

Erik, please do the same :).

Best regards,

Alex.

Submitted by raven on Sun, 08/17/2008 Permalink

My customer wants to use agents and queues in the latest single tenant release. I can't figure out what to tell them as far as how it works. Does it work now in some kind of form? Where does the agent login?

Submitted by andrewyager on Sun, 08/17/2008 Permalink

To get the agent to log in, you must create a Feature Code attached to the Agent Log In application. This will allow them to log in from an extension. The caveat is that extension should not have voicemail enabled for this to work properly.

This works moderately well, but we have decided to disregard this implementation, and go for Dynamic Queues instead.

We have a number of basic scripts that log users in on the basis of their extension number.

Submitted by dbenders on Mon, 08/18/2008 Permalink

Hi Andrew, can you tell us why you said that dinamic queues work much better? Also, can you tell us how to implement it? We are using the standar queue implementation and work fine, but have lot of problems as for example the voicemail. BTW, we are using QUEUEMETRICS for statistics and work very well, is this compatible with the dinamic queues configuration?

Submitted by eeman on Mon, 08/18/2008 Permalink

Quemetrics would work with dynamic queues in single tenant. Queuemetrics is very tricky to get to work in MTE at all, and won't work with static channels or dynamic members for MTE. Queuemetrics strips everything after the first hyphen '-' so the MTE naming convention of SIP/111-tenant would strip the tenant and only match against SIP/111. Given that there could be multiple SIP/111 among multiple tenants it makes it nearly impossible at the moment.

The best way to use dynamic members is to use the AddQueueMember application but replace the channel name with a fixed name (membername). I am working through the concepts for the PBX manager interface to show status from within the user portal, join different queues that have been authorized to join, log back out of the queue etc.

the one advantage agents had was tracking calls of an agent seperate from the phone itself. So an agent could sit at any station and take calls, but have the queue_log report on their performance. This is where I see the 'membername' value coming to life.

Submitted by raven on Tue, 08/19/2008 Permalink

Thanks for the response. Is there any documentation anywhere to use as a template setup? Like a step by step procedure?

Submitted by amagurie on Fri, 08/22/2008 Permalink

We use AddQueueMember with membername which we populate it with the old style 'Agent/1234' (entered as part of the login script). Dynamic members can also be paused which is great.

We use this Asterisk patch http://svn.digium.com/view/asterisk?view=rev&revision=125585 to be able to get the extension they are logged into for realtime statistics.

We also use Asternic Queue reporting, which required some modifications to working with this setup.

Regards

Allister