Response Groups help facilitate call transfers within Lync’s infrastructure. They let you direct calls to where the caller needs to go: Sales, Marketing, Customer Service, Support, etc.
They do require a little setup time, to organize agent groups, create workflows and so on. So their management is a necessary component of Lync Server administration.
Here’s how they work.
30-Second Response Group Overview
You (the Lync administrator) set up a Response Group for a group of people in your organization. Sales, for example.
Someone calls the Sales office.
Since the number they called is set up with a Response Group, the call is routed to one of the right people (called an “Agent”).
Who gets the call depends on the Response Group’s selected routing method (Serial, Longest Idle, Parallel, Round-Robin, Attendant). If no one is available, the caller is placed in a queue.
Pretty simple, right? Good caller management, entirely configurable by you.
Response Groups have stayed pretty much the same from Lync Server 2010 to Lync Server 2013. Except for one area: Management.
How Response Groups are Managed in Lync Server 2010: 1 Administrator Role
For Lync 2010, you had one administrative role: CsResponseGroupAdministrator. This role could create and modify Response Groups, its agent lists, queues and workflows. Every Response Group setting was available to configure.
However, other administrative roles could also modify Response Group settings. The CsVoiceAdministrator, CsServerAdministrator, and CsAdministrator roles all could. And these were all all-or-nothing roles; you couldn’t set much in the way of granular permissions.
It worked, but only just. If you had multiple administrators, you could lose track of Response Group configurations quickly.
To improve things, Microsoft changed the administrative structure for Response Groups in Lync Server 2013.
How Response Groups are Managed in Lync Server 2013: Manager & Adminstrator roles
You have two management choices for Lync Server 2013 Response Groups: A Response Group Manager role or a Response Group Administrator role.
What’s the difference? An Administrator can do everything for any Response Group, just like its 2010 counterpart. But Managers can only manage Response Groups to which they are assigned. And even then, there are some settings beyond a Manager’s control.
–Managers can’t create or delete a workflow.
–Managers can’t modify some Response Group settings, like their SIP URI or phone number.
When to Use the New Manager Role
Some good practices we’ve determined, when it comes to Response Group management:
- If you have more than 3 Response Groups, use Managers for each one. (Fewer than 3, just stick with the Administrator role.)
- Install a Manager at any branch sites, in case you must troubleshoot call routing errors.
- Use Managers for critical Response Groups.
Wait, why did I say use a Manager role (lower-security) on a critical Response Group?
Because essential Response Groups – such as Help Desk or Sales – need immediate support if they don’t function properly. If calls aren’t making it through, someone has to fix that Response Group ASAP.
It’s best to have more than one person available to do so – if the Administrator isn’t available, a Manager better be.
Which I think is at least half the reason Microsoft added the Manager role – you can share responsibility & support between people.
Response Groups are a setup-once-and-watch-it-work sort of functionality. It’s only when calls fail to route that you need management. Having someone to call if the administrator is unavailable means you can repair incoming call management again.
How does your organization use Response Groups? Do you use Managers? Let us know!