Enable Agent Anonymity and How this Works with Response Groups

Iron Contributor

We have our switchboard operator set up to use Response Groups. It is working great! However, they would prefer that their name not show up when transferring calls to other areas of the campus. I noticed in the Response Group screen that I could "enable agent anonymity" and thought that is perfect, that will resolve the concern. I enabled the feature and then they started reporting problems with transferring calls to other response groups.


Has anyone set up anonymity for their Response Groups that can explain what this does or the limitations? I did some Google searches and see others talking about it, but it sounds more like about the ability to call out as the response group number instead of how the calls are transferred.


I had to back out of what I did for the campus switchboard, but I have a test group set up now so I can test to see what happens. I wanted to check with others to see if others have done this and figured out a solution to keep operator names private.


Thank you!




2 Replies

Hi John, you're quite right. Agent Anonymity is a masking process that applies to calls whilst they're in the remit of the response group service, so transferring calls (even although they might have come in via RGS) to another user can't leverage that functionality.


Agent Anonymity gives you 'call on behalf of' functionality for outbound calls, where you're masking your own ID in place of the response groups - just like you said. For inbound calls, where another Skype user might be calling the response group, it also masks the answering agents ID on the callers client - this wouldn't be applicable for a PSTN call as you don't see the display name... or even have a client per say.


Unfortunately the setting won't help you with the transfer scenario you've explained. When you blind transfer the call from the switchboard user, it will display the "transferred by....." toast. If you were performing consultative transfers then you could call out to the user on behalf of the response group and then compete the transfer - but there's more effort involved in that, and if consultative transfers aren't a requirement then it somewhat makes things less fluid for the switchboard operator.


Regarding the problem with transfers when anonymity is enabled. I recall this being an issue in Lync server (and assumed it was fixed). The work around was that you had to explicitly click the drop down menu next to the 'call' option, and select 'Lync Call'... simply double clicking or select call on a user resulted in a fail. I thought they fixed that and didn't know if it existing in SfB... but it sounds an awful lot like what you mentioned. The limitation around anonymous RGS calls are all the fancy things like screen sharing, file transfer, whiteboard... all the good conference stuff that relies on Agent ID / SIP addressing.


I'm not sure there's an easy way to meet your requirements through blind transfers.


Kind regards


Thank you for the response and information. I was afraid that this would not work for them. The concern is that when our switchboard operators transfer calls to other people within our institution, the department will tell the person calling from outside the institution that so-and-so called. I am trying to decide if it is worth creating generic accounts (i.e. Switchboard Operator) that would take the calls to transfer. It seems like a lot of work to do just so names do not show up on campus phones when transferring from the switchboard.

For now, I have talked to the staff to say we will see how this works and whether we get negative feedback that individual names are showing up when calls are transferred instead of 'switchboard operator' and see what happens.

I thought I had found a way to resolve it as I described and then started getting reports the calls could not be transferred. Sigh!

Thanks again!