Main Number Handling – Response Groups Pt 2 – All About Queues

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 ‘’. 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 ‘‘ where 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 ‘’. 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.

Main Number Handling: Solution Overview

In the first post in this series, I provided some basic guidance on how to plan for you main number scenarios. In this post, I’ll outline each of the technical options that you can use to address you main number requirements.

Your call handling functions include:

SfB Response Group Hunt Groups

Response Groups are a hunt group/IVR solution built into SfB on-prem. Response Groups have three components: groups, which are your users who will handle calls, queues that present the calls to groups, and a workflow that will play a greeting and send the call to a queue.

Workflows have options for business hours, holidays, music on hold, recorded or text-to-speech greetings. A call can be distributed to a queue, or based on work hours and holidays it can be disconnected (really? Who would ever do that?) or forwarded elsewhere.

Response Groups have some other features like Agent Anonymity so that you don’t reveal the name, SIP address, or number of the agent receiving or placing a call. A Response Group can be Formal or Informal. With Formal Response Groups, Agents must log in and out of the Response Group, whereas with informal Response Groups they’re always “logged in”.

You can also scope a Response Group to a manager, so that you can easily delegate all the fiddly settings like greetings and hours and group membership to an administrator.

Once the call is in a queue, there are a variety of timeout and overflow options. Within Groups, you can set the method used to pick which agent(s) is offered the call, and how long the call will ring before it’s sent back up to the queue for alternate handling.

SfB Response Group IVR

The Response Group type I described above is a Hunt Group, where an incoming call has only one destination queue. An IVR Response Group allows you to provide options to the caller, and route their call to a different queue based on their responses. This can be via keypress or speech recognition. You can also record that ubiquitous “Please listen carefully as our menu options have changed” greeting that everybody seems to have, regardless of how old their IVR structure is.

Response Groups are pretty versatile (and free) and are commonly used because of this. However, they’re not without their limitations. I’ll explore these more in a future post.

Exchange Auto-Attendants

Exchange Auto-Attendants aren’t an SfB feature, they’re a component of Exchange Unified Messaging. They’re available online or on-prem, and are fairly simple to configure. When an Auto Attendant is called, a greeting is played and the call can do things like an address book looking, enter an extension, or similar to the IVR Response Group, press keys or use voice recognition to play messages or reach destinations. You also get business hours and holidays, and can change behavior based on these.

Unlike Response Groups, there are no queues or groups in Auto Attendants, however the Auto Attendant doesn’t care what’s at the number that you forward a call too, so you could forward a call from an AutoAttendant to another AA, Response Group, user, or your annoying coworker’s mobile.

SfB Standalone/Phantom “user” or Common Area Phone

You could also chose to have a main number ring a regular phone or SfB client, typically one that isn’t assigned to a person. I’ve seen these called “Standalone” phones or “Phantom users”. This solution is common when your call volume is low, or when you have a rotation of people through a reception desk. The users can logon to the PC as themselves, and would have a phone on the desk for the main number. I have also seen organization load an Attendant console on a small form factor PC with a touch screen, and have this sit on the desk beside the regular office PC.

You can use a standard SfB user for this, or a Common Area Phone. Using a SfB user consumes a license, where a CAP does not. However, CAPs are not yet available in SfB Online, and cannot offer voicemail.

SfB Team Ring or Delegation

When a standalone phone or phantom user proves too limiting, such as when there isn’t a reception desk or you need a ring a group of people, you can use Team Ring or Delegation.

Team Ring allows one user – your phantom user – to have their calls ring on their teammates SfB clients or phones after some delay (0-15 seconds). They’ll get a unique ring/toast so they can identify that the call isn’t to their individual number.

Team Ring and Delegation are very similar, with one key difference. With Team Ring, you can only answer calls on behalf of the phantom user. With Delegation, you can receive and place calls on behalf of the phantom user.

This is a popular, free (other than the SfB license for the phantom user), self-serve option, but it’s not a scalable solution.

SfB Simultaneous Ring

A similar option to Team Ring is to use the Simultaneous Ring feature. However, Simring only allows you to assign one destination user or phone number, so you can’t alert multiple people for an incoming call. This option is useful for a single user or phantom user, when the person who would normally answer the call is away from their desk – an admin person making some photocopies, or a security officer doing a patrol. They can setup simring to a mobile or cordless phone, and wander away from their desk while being able to answer the phone. Note that options for call transfers are limited in this scenario.

They could also simring a coworker who is staying at their desk, who would have the usual SfB call transfer options.

Call Pickup

Call pickup is a relatively new option in the SfB world. The idea is that when your phone is ringing, your coworkers can enter a code on their phone to pickup your call. This was a popular function in traditional PBX environments that didn’t have things like delegation or team ring. Call pickup is a bit of a pain to administer. Frankly, I get the feeling that this feature was added to SfB to satisfy a large customer, or to gain another point or two when organizations are scoring RFP responses.

Shared Line Appearance

A Shared Line Appearance is another legacy PBX features that has crept into the SfB world, at least partially. The idea here is that you would have a button (or two or three) on your phone that would be a duplicate of the line on another phone. Think of an admin who can have buttons on their phone for the main number, the bosses’ number, and maybe a coworker. They can hit this button to answer the other line(s) when they ring. In most legacy PBXs, the button also offered a busy light, and could either act as a speed dial to call that person, or a “place call on behalf of” function. In SfB, this functionality is limited at present to just Polycom VVX phones, it’s not available on other phones or the SfB clients. The button also doesn’t do anything other than answer the call.

I’ve seen limited uptake of this feature, and again I suspect it’s to provide some level of comfort to a large SfB customer or for RFP scoring. There are better, less limited ways to handle most scenarios where SLA is mentioned.

Coming soon to the SfB offerings are Cloud PBX Organization Auto Attendant and Cloud PBX Call Queues. These are meant to offer functionality similar to SfB Response Groups in Online deployments, and to eliminate the need for the Exchange UM role for Auto Attendant functionality. These features are currently in preview, and I’m hopeful that they’ll be released soon so that I can provide more concrete details.

AudioCodes Auto Attendant

AudioCodes offers an application that they call AutoAttendant, though it’s more like the Response Group than Exchange Auto Auto attendant. There are no directory lookups, but there are decent options for queueing and IVR handling of calls.

Full-blown Contact Center

If these solutions don’t meet your requirement, you may need to look at a full blown contact center solution like Computer Talk ICE, Clarify Connect, or Enghouse’s offerings. This isn’t as daunting of a concept as it once was. You no longer need to deploy one or more servers and installing software. Most call centre software is now available in the cloud as a service, with functionality and pricing on a per-user, per-month basis.

Next up…

In the next several posts, I’ll provide more in-depth details on each of the items above. If I’ve missed your favorite main number handling option, hit me up in the comments!

Main Number Handling

A topic in every SfB deployment I’m involved in is main number handling, and rightly so. Callers to your organization deserve a first class experience, and that experience needs to also meet your organizations objectives. For example, do you want a caller to first reach a live receptionist and only overflow to an auto attendant, or are your calls best handled by an automated system?

Over the next several posts, I’ll review the organization characteristics and requirements for main numbers, and the features in SfB for main number handling. I’ll then dive deeper into each feature to show how they work and what the benefits and drawbacks of each may be. I’ll then outline how the features can “snap together” to provide a more detailed solution, and give some real-world examples that I’ve seen.

30,000 Feet

A main number is any phone number that reaches your organization, but isn’t assigned to any one particular person or phone. A regular user, Common Area Phone, subscriber access, and conference room phone aren’t main numbers. Main numbers are things like reception, help desks or support lines, team phone numbers, or even things like enterphones/door buzzers.

The beginning is a very good place to start

Jumping in to the technical features of SfB is a terrible place to start this process. Your technology products need to address your business issues, so let’s start with business processes and people.

If you’re migration to SfB from another system

A migration means that you’re already handling your main numbers in some fashion. Document how the number is currently being handled. Review what you’ve documented with the users that are involved with handling calls to the number. This includes anyone who might answer the phone, but also those who receive calls from an Auto-Attendant, for example. Your goal here is ensure that you have accurately and completely captured how things are working today (and not necessarily how they’ll work in SfB)

  • If you’ve identified phone numbers, voicemail boxes, departments, recordings or greetings that you don’t know anything about, you will need to ask around. Call those unknown numbers, leave voicemails in those odd looking voice mailboxes and ask people to call you back. I’ve seen one organization that just couldn’t track these down set up bounty-hunter prizes for staff members who solved the mystery of the unknown number. (Some people will do anything for a Starbucks gift card!)
  • During this process, be sure to ask stakeholders about any toll-free numbers that might be involved. Typically, a toll-free number is delivered to a regular number at your organization. Make sure you don’t disconnect the regular number, or port it away to a different carrier without also bringing the toll-free number.

Next, review what you’ve discovered and documented. Your current system might be decades old, and may have grown organically and uncontrollably since then. Ask those involved if they like how it functions, or if they’d like to see any changes made. Draw up a new plan based on their input, as if you were deploying a new number – which brings us to the next section…

If you’re deploying a new main number

A net-new number can be easier or more difficult that a migration. It can be easier because there isn’t any legacy baggage of “we’ve always done it this way”. It can be more difficult because sometime people don’t know enough to provide useful input.

Meet with those involved in handling calls to the main number, or receiving calls from it. Establish what their requirements are, and how they would like to see the system work. Again, stay away from technical features – focus on what people want and what the business needs. Draw up the new plan, and review it with those involved.

Designing and Documenting

Whether you’re migrating or deploying net-new, don’t aim for one rigid plan that you’re now going to try to implement in SfB. Instead, capture ideas and concepts like “if reception doesn’t answer within a couple of rings they might be busy, so also ring accounting, then if nobody answers after 30 seconds, go to voicemail”. Whiteboards, post-it notes, and the Office Lens app on your smartphone are your friends here.

You may wind up with multiple plans or ideas for handling some numbers. That’s fine, and maybe even useful as you being to map those requirements to features available.

Mapping Requirements to Technical Features

Now that you have a handle on your current deployment and what the desired functionality is, you can being to examine the technical options for implementing that functionality. As you progress, you may need to rework your desired functionality because of technical limitations, or new ideas that arise when you map your desired functionality to the technical options available. If you have multiple possible plans or ideas for a number,

In the next post, I’ll jump into an overview of the (many!) options within SfB. Stay tuned!