Main Number Handling – PSTN number as a Response Group IVR Destination

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:

Queueoverflow0

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:

Group in 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.

 

 

Main Number Handling – Putting it all Together, Response Group Calls to a non-SfB number

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”:

call action PSTN

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.

Main Number Handling – Putting it all Together in Larger Offices

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.

Main Number Handling – Putting it all Together

A number of months ago, I kicked off what I thought would be a short and simple overview of the various ways you could handle a main number in SfB. As it turns out, there was nothing short about the process! However, now that we’ve covered the various components that you can use to handle calls to main numbers, it’s time to tackle some common main number scenarios that I see in organizations I work with. Along the way, I’ll throw in some tips and tricks from my list of ways to make life easier.

Before we do that, you should hop back to my first post in this series, where I talk about some of the non-technical things you should consider, and how you should approach designing a solution to handle your main numbers. You shouldn’t just rush in and set things up, as some of them take time. It’s also important to ensure that you’re getting the best SfB solution for your users, and not just a clone of what they had previously.

“I find that it’s often the case that SfB has all of the functionality to meet the same goals as users expected from a previous PBX. However, that functionality is often implemented differently.  That’s not because SfB is weird, but rather because it’s a UC system and not a PBX. There are multiple modalities to consider, as well as things like mobility and presence.  Tag for status change alerts is a good replacement for “Camp on” in the PBX world. While it may require you to take the additional step of click “call”, this does give you the opportunity to use a different modality to contact the user once they’re available, such as IM. Of course, you could always choose to IM the user who’s on the phone and thus avoid the entire requirement for Camp on functionality”

The Solutions

The first solution that I’m going to list, will also be the first one that I recommend that you not implement, and that’s to simply use the receptionist’s phone as your main line. If your receptionist goes on a break or vacation, then someone needs to know their password to check voicemails. That’s bad for security, but it also sucks for the privacy of the receptionist’s account. And what greeting gets used – the receptionists, or the organizations? Yuck, better to just move on to the next solution.

The second solution is suitable for small offices. You setup a standalone or “phantom” account for the main number, and leave the receptionist with their own account. We had a look at the good and the bad around this solution here so I won’t rehash that discussion.

Up next, we’ll have a look at options for scaling up to larger offices.

Main Number Handling – Cloud PBX Call Queues

I’ve covered Response Groups in a number of earlier posts. Microsoft has started implementing similar functionality in Skype for Business Online, called Call Queues.

Where Response Groups are quite comprehensive and have “lite” call center functionality, Call Queues aren’t there yet. There are a number of key differences between the two. First up, let’s have an general overview of Call Queues, then we’ll compare them with Response Groups.

General

The purpose of Call Queues is to provide automated call distribution to a group of users, called agents. You can have up to 50 agents assigned to a Call Queue. Agents are assigned to a Call Queue using distribution lists, or mail enabled security groups. The Call Queue can handle 200 simultaneous calls. If you’re handling 200 simultaneous calls, you should evaluate contact center software to see if it offers you additional functionality that you can take advantage of.

As with Cloud PBX Auto Attendants, you can upload a corporate greeting. If you don’t have a favorite application for this, try Audacity. You can also specify a music on hold file, that’ll be played while callers are in the queue waiting for an agent.

When you setup group, you need to allow time for the group to sync from Azure Active Directory to Azure Address Book Service.

Calls are distributed to all of the agents in the groups you configured, to a maximum of 50, or there is a global setting to reduce this count further. If you’re using groups with larger membership, be aware that not everyone will be offered every call. If you want more certainty in who is offered a call, create custom groups.

Overflow

Each Call Queue has an overflow threshold, after which new calls will have some configurable action taken on them rather than the call being added to the queue. This can be 0 to 200, but has a default of 50.  You can select actions of DisconnectwithBusy, Forward, or Voicemail.

There is also a timeout option, so that after a certain amount of time in the Queue, calls are send to another Call Queue, Auto Attendant, Voicemail, or User. You can also just disconnect the caller.

Consider whether you want to use the disconnect options. While the caller will hear a busy tone, you may want to forward the call to voicemail, and play an informational message. I would never recommend a disconnect for the Queue timeout – why would you disconnect someone after they’ve been waiting in the queue for 10 minutes (or however long you configure).

You’ll need a Cloud PBX Service Number to assign to your Call Queue, and you can use both tolled and toll-free. You can use a new service number for setup and testing, and port in your existing number.

The timing of the port may prove awkward if this is your main number. You can setup your Call Queue with a new number, and have your existing main number forwarded to it. When you receive notification that the number has ported, you can edit your Call Queue to use the new number directly.

Your Tenant needs to have E5, or E3 plus Cloud PBX licensing, in order to have Cloud PBX Call Queue available.

If you want your Cloud PBX Call Queue to direct calls to a voicemail box, you should setup a phantom user (a user account with no real human attached to it), and have that mailbox be the target of Queue.

Call Queues allows Online SfB users with a Cloud PBX license to be agents, regardless of what region they’re in. A PSTN Number or PSTN Calling user licenses isn’t required. Agents must be using the SfB 2016 or Lync 2013 desktop clients, or a Cloud PBX-certified IP phone. No Mac or mobile clients are supported according to documentation from March 2017, however I have seen the iOS client in action as a Call Queue agent.

You cannot use SfB on-prem users, Cloud PBX users with have PSTN connectivity through an on-prem connection, either through CCE or a full on-prem pool. You also can’t use on-prem only services like response groups, and you can’t distribute a call to an external PSTN number.

Comparison with Response Groups

Call Queues have some of the functionality of Response Groups, however at this point Response Groups have far more flexibility and functionality.

Call Queues lack IVR capability. If you need this, you can front a Call Queue with a Cloud PBX Auto Attendant. Have the Auto Attendant deliver calls to the Call Queue.

Response Groups have a richer management story. It’s possible to delegate management of a Response Group to a user (like a help desk manager) and relieve IT of the management burden. This isn’t possible with Call Queues.

Response Groups have the concept of Formal and Informal mode. Formal mode requires the user to logon to the Response Group to receive calls. Informal mode is where the user is always “logged on”. Call Queues offer only Informal mode.

For overflow scenarios, Response Groups allow you to act upon the oldest call in the queue or the new call. Call Queues only allow you to act upon the new call.

When it comes to distributing calls to agents, Response Groups offer 5 call routing methods: Attendant, Parallel, Serial, Round Robin, and Longest Idle. At this point, Call Queues offer only Attendant routing.

And lastly, when you’re building a list of agents, Call Queues use only distribution lists or email enabled security groups. Response Groups can use DLs, but also allow you to manually build a list of agents.

Outside of these major differences, the two services are very similar. I would expect that additional Call Queue functionality will be released often. Be sure to check the Office 365 Roadmap to see if a feature you’re interested in is on the way.

You can provide feedback on what features you feel are important with Skype for Business. The Skype Operations Framework academy page has online training for you to learn more.

Main Number Handling – Cloud PBX Auto Attendants

We’ve covered how to setup an Exchange Auto Attendant for your Skype for Business environment. Microsoft has recently released a new offering, the Cloud PBX Auto Attendant.

The two are very similar in their functionality, with some key differences. Firstly, Exchange Auto Attendants ( are an Exchange function, and not a Skype for Business function. Secondly, Exchange Auto Attendants can be in Exchange online or Exchange on-prem, work with SfB users regardless of where they’re homed, and can even integrate with other PBXs.

General

Cloud PBX Auto Attendants, being so new to the world, haven’t yet achieved a similar level of functionality. If you’re reading this blog a number of months after it was written, hit the Cloud PBX Auto Attendant tag to check for a blog covering updates!

When you’re configuring or calling a Cloud PBX Auto Attendant, the “look and feel” is nearly identical to that of Exchange Auto Attendants. You get the same informational, business-hours, and after-hours greetings.

When it comes to scheduling your business hours, Exchange Auto Attendants offer 15 minute granularity, where Cloud PBX Auto Attendants offer 30 minute granularity. You can, however, still set as many open/closed periods as you’d like.

Speech recognition is similar as well, and when you configure a name as a menu option, the Auto Attendant will recognize that name

Directory Search

Directory Search is an area where things differ between the two products. In Cloud PBX Auto Attendant, callers can speak or spell the name of any SfB ONLINE user, and that user can be homed in any of the regions that the tenant has. That user doesn’t need a PSTN Calling license, or a PSTN Calling number. The caller cannot reach a Cloud PBX user who has PSTN connectivity through an on-prem connection, either through CCE or a full on-prem pool, nor can they reach users who are home on-prem.

A feature of both Exchange Auto Attendant and Cloud PBX Auto Attendant is the ability to set a scope, or limit, of who callers can search for. You might want to protect VIPs, or only allow callers to reach sales staff.  If you happen to be part of an organization with more than 50,000 users, you cannot use name recognition to search for a user – but all other speech recognition works.

Operator

With Exchange Auto Attendants, you provide an extension for the operator, and when a caller presses 0, they are transferred to that extension. The “extension” can be any number, so long as you configure Exchange and your PBX/SfB to permit the call.

Cloud PBX Auto Attendant allows Online SfB users with a Cloud PBX license to be operators, regardless of what region they’re in. A PSTN Number or PSTN Calling user licenses isn’t required. You can also send calls directly to voicemail, or to a Cloud PBX Call Queue (the Cloud PBX equivalent of a Response Group).

You cannot use SfB on-prem users, Cloud PBX users with have PSTN connectivity through an on-prem connection, either through CCE or a full on-prem pool. You also can’t use on-prem only services like response groups.

Menu Options

Menu options are straight-forward. Indicate the dialpad button for a caller to press, and then the action to take when that button is pressed. One difference here versus Exchange Auto Attendants is that there is native functionality to transfer the call to a Cloud PBX Call Queue, instead of you having to indicate a phone number or SIP address.

The GUI is a bit different here compared to Exchange Auto Attends. You get buttons arranged in a row, with a list of the options you’ve configured below:

Buttons

Other Bits and Pieces

You’ll need a Cloud PBX Service Number to assign to your Cloud PBX Auto Attendant, and you can use both tolled and toll-free. You can use a new service number for setup and testing, and port in your existing number.

The timing of the port may prove awkward if this is your main number. You can setup your Cloud PBX Auto Attendant with a new number, and have your existing main number forwarded to it. When you receive notification that the number has ported, you can edit your Cloud PBX Auto Attendant to use the new number directly.

Your Tenant needs to have E5, or E3 plus Cloud PBX licensing, in order to have Cloud PBX Auto Attendant available.

If you want your Cloud PBX Auto Attendant to direct calls to a voicemail box, you should setup a phantom user (a user account with no real human attached to it).

Evaluation and Adoption

Your first step in evaluating and (possibly) adopting Cloud PBX Auto Attendants is to document the functionality of your current auto attendant. Then, review the functionality and the limitations mentioned above. If Cloud PBX Auto Attendant can do everything you need, then you’re all set – time to deploy!

If you identify some gaps, you have two choices. One, you can change your requirements to match what’s available now, or two, you can wait. Additional functionality is expected to be released as development occurs.

Be sure to check the Office 365 Roadmap to see if a feature you’re interested in is on the way.

You can also provide feedback on what features you feel are important with Skype for Business.

Learn More

Head to the Skype Operations Framework academy page to learn more!

Main Number Handling – Auto Attendant vs Response Group

I’ve covered Exchange Unified Messaging Auto-Attendants and Skype for Business Response Groups in some depth in previous posts, and I wanted to do a comparison between the two. The two share some overall similarities, with some major difference that will lead you to select one over the other, and minor differences that you’ll want to be aware of.

Microsoft recently released two Skype for Business Online features: Cloud PBX Call Queues and Cloud PBX Auto Attendant. These two SfBO features are roughly analogous to Exchange Auto Attendant and SfB on-premises Response Groups, however to be clear I am not referring to the Cloud PBX functions in this post unless I explicitly mention them.

Main Feature Comparison

In the following table, I state whether functionality is available in Response Group and Auto Attendant scenarios, and in some cases I provide some more clarity and detail beyond a “yes” or “no”.

Feature

Response Group

Auto Attendant

Anonymous call out

Yes, user can call as the Response Group

No

Management delegation

Yes, per Response Group (and associated Queues and Groups)

Not very granular, only to “Exchange UM” RBAC role within Exchange.

User lookup/dial by name (speak or spell)

No

Yes

Schedule

Scheduled to the minute. Two open periods per day, otherwise closed.

Scheduled in 15 minute blocks, any number of blocks may be open or closed.

After-hours and holiday support

Yes

Yes

Calls delivered to

Natively to PC SfB client. Voicemail and other timeout/overflow options available.

To any SfB client, or any phone number reachable by Exchange – including PBX extensions and PSTN numbers.

Honors Team-ring, Delegation, SimRing, Call pickup, mobile clients

No, only rings the user’s PC or desk phone.

Yes

IVR

Yes, multiple choices and levels. Calls delivered to Queue, not directly to an endpoint.

9 choices, one level. Calls delivered to a number, mailbox, and can play a message

Caller can dial 0 to reach operator at anytime

No

Yes

Call queuing

Yes – call is delivered to a queue

No – call is transferred to the number specified

Multiple language support

Yes

Yes

Voice recognition

Yes

Yes

Text-to-speech or recorded greetings

Yes

Yes

Can read location and business hours to caller

No

Yes

Formal agent logon mode (user logs into and out of a queue)

Yes

No

Online or on-prem server based?

On-prem servers only.

(Use Cloud PBX Call Queues for online deployments)

Both. Exchange UM Auto-Attendants have the same functionality on-prem and online.

Can deliver calls to on-prem user

Yes

Yes

Can deliver calls to online user

No, users must be homed on-prem.

Yes

Can assign multiple phone numbers to reach it

No

Yes

Can record greetings via telephone

No

Yes

The details in this table refer to native functionality of the Auto Attendant or Response Group solution. For example, you can only natively assign one Line URI to a Response Group workflow. If you wanted to have multiple numbers to reach a workflow, there are a number of ways outside of Response Group functionality that would permit you to do that.

Final Considerations

An additional consideration that you’ll need to make is the topology of the Exchange and SfB environments. If a call comes in from the PSTN via an SBA in a branch office and has to traverse the WAN to a central office to Exchange and SfB servers, the two solutions are equal. If you are using Exchange Online, calls to your Auto Attendant now have to traverse the Internet to the cloud.

In the not so distant past, I worked with a client in a “PSTN into the SBA” scenario, where calls had to traverse the WAN to reach Response Groups, and the WAN and an underspec’d VPN to a privately hosted Exchange system. That VPN was spec’d for email (and the specs weren’t even generous for that) not voice, so voice, Auto Attendant, and Subscriber Access suffered accordingly.

And finally, make sure you’re supporting REFER, and that your firewalls allow appropriate media flow between all of your clients and servers involved in these scenarios. Appropriate levels of bandwidth and QoS are also a must.

Up next: Cloud PBX Auto Attendants and Call Queues, the Cloud PBX cousins of Exchange Auto Attendants and SfB on-prem Response Groups.