This post is part of my series on Main Number handling. The most feature-rich call handling solution native to SfB is Response Groups. Response Groups, while nowhere near a full contact center, offer a great deal of flexibility and capability for an organization.

In the overview post, I provided a brief outline of Response Groups – they are an on-prem solution that offers hunt groups or IVR trees to assign calls to a Queue, and you can designate agents to handle the calls within that Queue. Response Groups are comprised of a Workflow, that receives and processes the call, passing it off to a Queue. Queues have Agents that are offered the call. To “Offer a call” is Microsoft’s terminology for the Response Group service ringing a particular Agent’s phone, so that they have the option to answer the call.

You might think at first that the Workflow would be the best place to begin any kind of deeper explanation. I’ve found that the opposite is true, so let’s being by taking a look at Groups, and since a picture is work a thousand words, here’s a screenshot of where to find the Response Group configuration page in the SfB Control Panel:

You can see the three components: Groups, Queues, and Workflows. The components are homed on a Front-End Pool, so you will need to select a pool each time you create or edit one of these objects.

Diving into Groups and selecting New, we see this page (it’s the same page for editing):

Note that while these components are homed on a particular pool, users who are Agents in a Group can belong to any on-prem pool in your organization.

The Name and Description fields are self-explanatory. Note the red star indicating that the name is a required field. You can edit the name after creation, but make things easy on yourself and come up with a naming scheme before you start.

Note that you’ll need names for Groups, Queues, and Workflows. If you call all three components “sales”, life can get confusing for you, especially if you find yourself in PowerShell. The easiest way to alleviate this is to add _Group or _Queue to the end of the name for these components. Users never see these names, so don’t worry about confusing them.

Great naming standards are always a win in my books, but do feel free to leave notes in the description field that provide more insight into the purpose of the group.

Participation Policy has two options, Formal and Informal:

• Formal requires your agents to sign in and out of the Response Group. You do this via a web page and not just a button on a phone or in the client. I personally find this annoying. The lack of other Contact Center functionality in Response Groups makes Participation Policies somewhere i
• Informal means there’s no login/logout required. You are essentially always logged in. This is the most common selection that I see.

Alert Time  is generally how long SfB will offer a call to the Agents before it’s passed back to the Queue. There are two timers in Response Groups, one at the Group level and one at the Queue level. Any decent conversation about these timers needs to include how the two timers work together for you (or against you, if you’re not careful) so more on timers in the upcoming post on Queues.

Routing Method is the pattern that the Response Group service user to select Agents to offer calls to. Your options are:

• Longest Idle: The Agent who has been idle the longest, as long as their presence is Available or Inactive.
• Parallel: The call is offered to all Agents whose presence is Available or Inactive.
• Round Robin: The call is presented to each Agent based on the list of Agents, so long as they are Available or Inactive. The RG service keeps track of the last agent that was offered a call, and will start with the next agent for the next call. Over time, you will get a roughly equal distribution of calls, assuming your agents have similar presences statuses for similar amounts of time.
• Serial: Similar to Round Robin, but follows the order of the agents as you have them in the Agent list, so long as that user is Available or Inactive. Unlike the Round Robin option, the RG service will start again at the top of the Agent list for the next call. This is a great way to prioritize your agents so that one person typically answers calls, but calls will immediately go to their backup(s) if they’re not available
• Attendant: The RG service will offer the call to all agents, regardless of their presence (Save for DND and Offline). One key difference is that the calls will “stack up” in the Agent’s notification window, and they can cherry pick which call they answer. On the downside, agents will hear ringing and see toast for each call that is coming in. If you have a lot of calls stacking up, this gets really annoying. (Use Queue overflow settings to alleviate this)

Agents are last. We have a dropdown that allows you to build your own ordered list of agents, or select an existing AD distribution list. The distribution list can be a great option however there are a couple of gotchas:

• The Response Group service is updated overnight through SfB maintenance processes. If you need to add an agent to a group faster, you can either fiddle with triggering updates manually or use the “customer group of agents” option instead.
• The Response Group service can’t take advantage of nested groups. Only direct members of the group you select become agents.
• Agents must be enabled for Enterprise Voice.

Gotchas to watch for when adding a user as an Agent to a Group in a different SfB Topology Site

• An user in the same site as the pool hosting the Response Group will receive a banner on their client advising that they’ve been added to the Response Group as an Agent. A user outside of that site will not receive any notification that they’ve been added to a Group.
• An Agent in one site cannot place calls on behalf of a response group in a different site.
• When an agent hits their default logon/logout page via the client, it will only have Response Groups from their own site. They’ll need to manually bookmark the login/logout page for any other sites that host Response Groups that they are a member of.
• You can leave a group without any agents defined, but you cannot use that group for anything. (Stay with me here, this applies in a more advanced call handling scenarios that I’ll get to later).

And that’s it for Groups. Next up will be a post on Queues, where all of the interesting stuff happens.