It's been quite a while since I've blogged about Lync. I've been a very busy boy trying to finish renovating my basement before the weather turns too nice to be stuck indoors. Thankfully, the crappiest spring I can remember has allowed me to get a lot done. Between that and my day job, it hasn't left me with much free time or energy to blog.
Last night, I was helping a client complete their migration from a legacy PBX to Lync Enterprise Voice. Their receptionist was going to use the Lync Attendant Console to manage incoming calls via a simple Response Group. Since there were a few people who rotated into the receptionist role throughout the day, we needed a simple way to ensure that calls would only go to the person currently on reception duties.
I set up a RGS group via the Lync Control Panel called Receptionists. I set the Participation Policy to Formal (#1 in the picture below) and the Routing Method to Attendant (#2).
The Routing Method determines how calls are routed to queue participants. You can select from Longest Idle, Parallel, Round Robin, Serial, and Attendant. The Attendant method means that queue participants will see all the calls in the queue and can select whichever call they want to answer (as long as they are using the Lync Attendant Console), unlike the other methods, which presents calls to users one at a time.
The Participation Policy defines how users are signed into their appropriate queue. Setting it to Informal means the user will be sent calls from the queue whenever they are signed into Lync. Setting it to Formal means the user controls whether or not they are signed into a queue. In the standard Lync client, users can click on Options - Tools - Response Group Settings, which will bring them to a webpage where they can select which queues to be signed into.
Last night, I was helping a client complete their migration from a legacy PBX to Lync Enterprise Voice. Their receptionist was going to use the Lync Attendant Console to manage incoming calls via a simple Response Group. Since there were a few people who rotated into the receptionist role throughout the day, we needed a simple way to ensure that calls would only go to the person currently on reception duties.
I set up a RGS group via the Lync Control Panel called Receptionists. I set the Participation Policy to Formal (#1 in the picture below) and the Routing Method to Attendant (#2).
The Routing Method determines how calls are routed to queue participants. You can select from Longest Idle, Parallel, Round Robin, Serial, and Attendant. The Attendant method means that queue participants will see all the calls in the queue and can select whichever call they want to answer (as long as they are using the Lync Attendant Console), unlike the other methods, which presents calls to users one at a time.
The Participation Policy defines how users are signed into their appropriate queue. Setting it to Informal means the user will be sent calls from the queue whenever they are signed into Lync. Setting it to Formal means the user controls whether or not they are signed into a queue. In the standard Lync client, users can click on Options - Tools - Response Group Settings, which will bring them to a webpage where they can select which queues to be signed into.
However, there isn't a similar method to reach the website from the Lync Attendant Console (which seems like an oversight to me). So, for Attendant Console users who are signing into formal queues will have to browse to the website manually. The website will be located on your site's external web services URL (defined at the server level in your topology). It will be something like:
Hopefully, this oversight will be corrected in a future Lync Attendant Console update.
Can you clarify, why do you need to provide the external URL for Response group formal group management, instead of the internal webfarm URL for this functionality?
ReplyDeleteDid you send feedback to MS regarding the missing RGS group membership option in menu?
I chose to provide the external URL because that's what is used by the Lync client. It will work either way, but this gives users a single URL to use, no matter if they are internal or external at the time.
ReplyDeleteI haven't sent feedback to MS about this yet. I suppose I should.
Thanks for the question!
Ken
Very interesting, thank you.
ReplyDeleteHow would this work in a multi-office, multi-time zone deployment? Let's say I have three offices: New York, Denver and Los Angeles. When the NY receptionists goes home for the day, can the calls to NY office be answered in Denver or LA?
Which leads to another question: if the offices are connected via a private MPLS network, would one need Lync servers in all three offices or just one, main office?
Thank you
You can have as many users as you want in the Response Group. The Denver/LA receptionists could log into the queue when the NY receptionist goes home. Another option would be to forward after-hours calls to the Denver/LA queues. Lots of different ways to do it.
ReplyDeleteIf your offices are all connected with reliable links, you could just have a single deployment at one site. It all depends on the number of users, bandwidth availability and that sort of thing.
As I know, this is the only way for another user to receive calls from a rgs.
ReplyDeleteThis is too bad there is no way to make the current receptionnist to forward the call flow to another user... for exemple when she's going for a pee...
When I set groups to parallel - the calls still do not get answred in FIFO manner.
ReplyDeleteIt seems the calls are presented to agents randomly?
We use the Longest Idle response group option. However, it seems that phone calls still go to someone who is already on the phone or who has clearly not been the person who has been idle the longest. I have reviewed all of the settings in the groups and queues and workflows. Have you seen this before? Is there something I am missing? (Yes, I do know that the Longest Idle will go to both the Available and Inactive users)
ReplyDeleteAny suggestions would be helpful as I have not been able to find similar issues on the web.
Hey Jeanne,
ReplyDeleteSorry, but I haven't come across that behaviour before. Try posting about your issue in the Lync forums (http://social.technet.microsoft.com/Forums/en-US/category/ocs)
Ken