In my last post, I covered how to have a Response Group Queue overflow/timeout action send a call to a PSTN number. That means you can send a call to an analog phone (maybe a cordless one), a mobile, or any other PSTN number. That’s awesome for overflow and timeouts, but there’s still a hole in Response Group functionality: how can an IVR option deliver a call to a PSTN destination?

Every once in a while, you need to get creative in your solutions to meet end-user requirements. The solution here is tricky to figure out, but simple to configure once you know what to do.

To review, a Response Group IVR is when someone calls a workflow number, hears options, and presses a corresponding key. The native workflow options are to deliver the call to a Queue, or to ask another series of questions. There is no option to deliver a call to a PSTN number.

If we look deeper at the Queue configuration, the only place to specify a PSTN number is in the overflow and timeout options. If we could set the workflow to deliver a call to a Queue, and set the Queue to overflow immediately to a telephone number, we’d be set. We can do that by setting the Maximum number of calls in the Queue configuration to zero:

And if you try the call, it will not work. As it turns out, a Queue will error out if there is no Group assigned to the Queue. The fix is simple: create a user in AD, enable them for SfB and enable Enterprise Voice, create a new Response Group group and assign the new user as an Agent. Assign that Group to the Queue:

And things will work – a call to the IVR, where the caller selects the option for the mobile number, will be forwarded to that mobile phone immediately. The Queue process throws an error when it see there isn’t a Group with at least one Agent assigned, it never gets far enough in the process to look at the overflow options.

I don’t recommend that you use a real user’s SfB account for this. Create a fake account, and make sure you add comments or notes to indicate the purpose of the account, so that it’s not deleted or changed.

If you’re going to use this solution for a number of different workflows, you can use a more generic name for the User and Group, and use the same User and Group for all the Queues, as the destination is configured in the Queue.

A few years ago, I worked with a two different organizations who had the same scenario.  They had a main number for the security department. This number was for a Response Group Workflow, which would ring the security staff and a couple of additional phones in the security area, such as the break room.

That worked well when there was someone in the security office to answer the call, but it meant that calls would go to voicemail if there were no security staff in office. This happened often, especially in the one organization that was closed at night and the security staff member had to do patrols.

The solution for both was to setup the Response Group Queue timeout and overflow actions to “forward to telephone number”:

Note the formation for the telephone number – you need to enter it as if it’s a SIP address, with your SIP domain after the @.

Yes, all of my lab environment domain names are colors! I set the desktop background of all the servers to be the domain name color, which helps me stay straight on which environment I’m connected to.

Okay, that’s cool, we can forward calls to a mobile or analog or any other phone as a timeout action on a queue. Tune in next blog post, where I show you how to send a call to any PSTN destination from a Response Group IVR.

I previously covered some simple solutions for main number handling for smaller offices. Now let’s have a look at larger offices.

I’ve worked with several organizations that prefer a human voice answer the phone wherever possible, and when that can’t happen they would allow the call to handled by an Auto Attendant.

The simplest way to configure this is to have the main number be a response group workflow. The receptionist is added as an agent. In the Queue, set the timeout (and optionally the max calls) overflow destination to the SIP address of your Auto Attendant. Callers now ring the agents when they first call, and then get the Auto Attendant if no agent can take their call.

Up next, some scenarios where you might want to add a second group of agents.

We’ve setup and explored almost all of the functionality that Response Groups have to offer. The remaining part is Interactive Response Groups. You may know these as IVR, or Interactive Voice Response, or call trees.

Interactive Response Groups allows you to play a message, and have the caller press a key or say a response, in order to direct them to the most appropriate Queue.

Configuration Differences vs Hunt Groups

In comparison to Hunt Groups only Step 7 in the configuration process differs. In Step 7 for Hunt Groups, you simple select a Queue to send the call to. For Interactive Response Groups you need to specify, at a minimum:

• A welcome message, either icky text-to-speech or a recording
• Two options for your callers to choose from, along with Queues to deliver them to

With the response details collapsed, Step 7 looks like this

Note that Responses 3 and 4 are optional, use the checkbox to enable them.

The configuration options within each Response are the same. First, you specify what response from your caller corresponds to this Response option:

You can configure keypresses of 0-9, *, #, or nothing. You can also provide voice-recognized words for your callers to use. Note that a blank keypress means your callers must use a voice response. Given that crummy cell phone calls can interfere with speech recognition, you should always include a keypress option. For voice recognition options, you can include multiple responses separated by a comma. For example:

If you want to offer more level of questions, you can choose to ask another question instead of sending a call to a queue

Here again, you must provide at least two options, and you have an option to provide up to four.

With the four “level one” options, and then 4 more “level 2” options, you can ask you callers a maximum of two questions, and direct them to 16 different Queues based on their response. In my experience, that’s more than sufficient to prevent annoying your callers, but to also get them to the right agent. If you need more options, you can use PowerShell to configure more, Anthony Caragol provides a great overview of that process. That doesn’t look like fun, and if you build a mess and hand it off to a co-worker, I’m pretty confident you won’t be getting any Christmas cards from them. Worse would be if you build a mess, and then have to come back and change it yourself in several months.

You might also consider Call Flow Manager which provides a much better interface and allows for more options.

However, be aware that if you configure a Response Group that has more options than your GUI of choice, you must resort to Powershell. Planning your IVR carefully means happier callers, and happier you. If you find yourself being forced into PowerShell to manage your IVR Response Groups, I’d say that’s a pretty strong indicator that you should have a look at contact center software.

When you’re configuring multiple layers, note that you don’t have to have two layers for every option. For example, if your first level question is “Sales or Support”, you can send calls for the sales team off to the Sales Queue, and then ask  a 2nd level question for those who chose Support.

There is a lot of flexibility in the Interactive portion of Response Groups versus a standard Hunt Group. Plan carefully to keep yourself happy when you to support what you’ve built!

In the last post, we covered the essentials that you need to get a Workflow (and your Response Group) up and running. In this post, we’ll cover the full seven steps to configure a Response Group.

Before we begin, a caution:

The Response Group Configuration Tool can hiccup every once in a while, especially if you are creating a number of Response Groups at the same time. I recommend that you  configure the bare minimum of SIP Address, Display Name, and Queue, then hit save.  Come back and edit the Workflow after that.

If you need to step away from the tool mid-build, or have configured some particularly cool and detailed settings, hit save often.

And lastly, you must have already defined the Queue that you will assign to handle calls. Saving after you configure the SIP Address, Display Name, and Queue will save you from getting to the end of the page, and doing a facepalm because you can’t save your Workflow config without a Queue to assign.

Step 1: Activate and Name the Workflow

Let’s break this one down into three areas.

The core of the Workflow

We covered SIP Address and Display name in the previous post. Telephone number is straightforward. Note the formatting here, they’ve included the tel: for you, unlike for user LineURIs. Display number should be the Telephone number, but formatted to however local users are used to seeing the number. Description is any text that you wish, and note that this text is published on the Contact Card for the Workflow object.

Workflow objects aren’t much different from user objects in Skype for Business from a contact list perspective. They are searchable, clickable, have contact cards, and you can add them to your contact list and favorite them.

Workflow Management

You have a managed or unmanaged Workflow. Setting a workflow to managed allows you to delegate the administration of the entire Response Group – Workflow, Queue, and Group – to one of more Skype for Business users. This is awesome, because it means that IT is no longer required to make every little tweak to the Response Group once it’s set up.

I think this is a terrible description of the function, because it affects Workflows, Queues and Groups.

Once you’ve delegated management of a Response Group, the manager can use the Skype for Business Control Panel and the Response Group Administrator Tool to manage things like Workflow hours, Queues and Groups, messages, schedules and IVR workflows – all the stuff that IT guys don’t want to do. They cannot create or delete workflows, or change the SIP address and telephone number – all the stuff that would break things that IT would then have to fix.

Note that when Response Group is set to Managed, the Queues and Groups cannot be shared with any other Response Group, even if they have the same manager. This makes a lot of sense, if one manager has created Queues for their business unit, another business unit manager shouldn’t be able to use or modify that Queue for their own purposes. You can assign multiple managers to a Response Group, if you need to.

The default is Unmanaged, which means that only members of the CSResponseGroupAdministrator group can create or edit Response Groups. It’s probably a bad idea to simply add a user like the manager of your account department to this group, it grants them too many permissions and then break all your stuff.

Activation, Federation, and Anonymity

Activation is straight-forward. Deactivating the Workflow means your Response Group isn’t going to take calls, but the number and configuration remain assigned. I use this often when I need to preconfigure a Response Group, but don’t want calls coming in to agents quite yet.

Turning Federation on means that users in Federated organizations can place a Skype call to the Response Group instead of needing to call via the PSTN. Since you can always call via the PSTN, turning this off offers no security benefit. If you do leave it on, make sure you test from a Federated client as well as the PSTN. I’ve seen some firewalls prevent a Federated caller from getting to a voicemail from a Queue timeout, but PSTN callers work just fine.

Enable Agent Anonymity is our last option. As the italic text from Microsoft indicates, this does limit some functionality. What it does do, is allow a user to place a call as the Workflow, so that their personal details are not revealed. This is great for helpdesk scenarios, where you don’t want people finding out how to contact your help desk staff individually and directly.

Gotcha! If a user is home on one pool, and a Response Group is on another, the Anonymity function is not available. The Skype for Business Windows client is the only client that I’m aware of that can do Anonymous calls – no phones currently support this function.

The limitations that Microsoft is referring to are minor for phone calls, and typically involve other modalities. For example, you can’t start an anonymous call with IM or video, you have to start with voice and then add the other modalities. If your goal was to have an IM session, it seems like overkill to have to phone the other person before you can flip IM on… Anonymous calls do not support conferencing, screensharing, file transfer, whiteboards, and recording.

Step 2: Select a Language

Use the drop-down to indicate what language you want the Response Group service to use for speech recognition and text-to-speech.

Step 3: Configure a Welcome Message

You can choose to play a welcome message to callers, either text-to-speech or something you record. Text-to-speech is great for testing, but not very professional sounding. You can use Audacity or the Windows sound recorder to record a WAV or WMA format greeting, and upload it here. Greetings that you’ve uploaded remain available. You can record all of your greetings at one time, upload them, and then select them as you need them. I’ve seen “closed unexpectedly due to weather” or special holiday greetings used.

Greig has a comprehensive post on audio formats on his blog. I either remember that he’s done this work and refer to it, or I find it in the top results when I do a search.

Step 4: Specify Your Business Hours

This section lets you configure your timezone and business hours, and set actions for when you are outside of your business hours.

You can define preset schedules via Powershell and select them here, or you can select “use a custom schedule” and enter your hours in the table. Note that opening hours start at the beginning of the minute, and closing hours end at the end of the minute. When you see 00:00 to 23:59 as defaults, that’s a full 24 hour day. You have two open and close times available, which lets you close over lunch time (or nap time).

There options for you to play a “sorry, we’re closed” message, these are the same as the greeting.

Finally, there are options for how to handle the call after-hours, these are self-explanatory. If you’re going to disconnect the call, please be kind and tell the caller to call back later in the after-hours message.

Step 5: Specify Your Holidays

This option is similar to the after-hours configuration, but is for entire days versus hours or minutes. You configure “holiday sets” via Powershell, but please don’t do this unless you have an irrational love for PowerShell.  These two tools the Holiday Set Editor and Lync Tools will save your sanity.

Step 6: Configure a Queue

This is where you pick the Queue that you want this Workflow to deliver calls to. If your Queue isn’t here, you likely started creating or editing the Workflow before the Queue was in the Skype for Business database. You can pick another Queue, save the Workflow, then edit it again to pick the correct Queue. If you haven’t yet created a Queue, you’ll need to start your Workflow configuration again.

Step 7: Configure Music on Hold

Response Groups come with a default music on hold that will play when users are in the Queue. You can configure your own music, by uploading the file here. There are no options for having a voice pop in every few seconds to remind people about how important their call is. If you want to do this, you’ll need to splice together your messages and your music file. Audacity can handle this for you.

I’ve seen a couple of organizations who have a recording of ringback that they use as hold music. This is illegal in some jurisdictions, but it’s also pretty annoying as the caller has no idea that they’ve been Queued unless you have a greeting. Be nice, configure a greeting, and play the default music or another music file suitable for callers to your organization.

Up next: Response Group Timers and Group Routing Method

I’ve talked a bit already about the two timers in Queues and Groups, as well as the Group Routing Method. I feel that these items need at least one post of their own to get a good feel of how they work together, so that will be covered more in an upcoming post.

This post is a part of my series on Main Number handling, and you may want to start with the introduction first.

Queues are where all of the magic happens in Response Groups.  As with Groups, you need a Name and can provide an optional description. Naming standards are your friend!

Next up, you can specify a list of Groups to receive calls from this Queue. If you specify multiple Groups, you can order them and the Queue mechanism will use the list, in order. How long the Queue spends in each Group is up to the timer you configured in the Group – more on timer interaction in a future post.

Next up we have Time-out and Overflow handling options. They’re disabled by default, which means that the Response Group will cycle through the Groups you’ve allocated indefinitely. That is probably less than ideal, so let’s dive into setting up Time-Out and Overflow options. Note that both have “overflow actions” – the options for these are the same, so I’ll discuss them last.

The first thing you can specify is the Time-Out period, in seconds. It defaults to 20, but you can set it anywhere from 10 to 65535 seconds. For those of you who aren’t good at division in your head, that’s about 18 hours.

For Overflow, you can set any number between 0 and 1000, which should cover just about any scenario you’d deploy on RGS. (The ability to specify 0 calls is a hidden gem, since it can provide an instant overflow. More on how to use this in a future post.) Overflow allows you to select the first or last call into the Queue to perform the Overflow action on. Generally I see this set to the “last call”, otherwise someone who’s been on hold in the queue the longest gets kicked to voicemail (or wherever) and the next person in the queue might wind up being connected with an agent moments later.

Call actions are pretty comprehensive. You can:

• Disconnect the call (I’ve never seen anybody do this, but you can!)
• Forward the call to a voicemail. Use the format ‘sip:bob@domain.com’. Note that Bob has to be enabled for SfB an EV for this to work.
• Forward the call to a telephone number. Use the format ‘tel:+14255551212@domain.com‘ where @domain.com is your SIP domain. You would do this even if the phone number is external to your organization.
• Forward the call to a SfB user. Use the format ‘sip:bob@domain.com’. This is the same format as the voicemail example, so make sure you’ve got the dropdown set to the right destination type.
• Forward the call to a different Queue. This is nice when you already have a Queue setup. Let’s say you have a Queue for your Receptionists. reception gets overwhelmed with calls, you could have the Queue overflow to the Accounting Queue so that they can help out and answer some of the calls.

And that’s all for Queues. The next post will have an overview of Response Group Workflows, the third component of Response Groups, and the first part of the Response Group that handles your call.