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.

Cool Tool – Find duplicate LineURIs

Every once in a while – and by that, I mean ALL. THE. TIME. – I run into a situation where a number that I’ve been asked to provision as a LineURI for a SfB endpoint is already in use:

Failed

“Filter failed to return unique result” has got to be one of the most frustrating errors that you can receive. At least it doesn’t tell you to contact your system administrator…

Sometimes this is easy to figure out by searching for that number in the User Search section of the Control Panel:

UserSearch

And other times it’s not, because the number is hiding, assigned to one of the following:

  • User LineURI
  • User PrivateLine
  • CsAnalogDevice
  • CsCommonAreaPhone
  • CsExUmContact
  • CsDialInConferencingAccessNumber
  • CsTrustedApplicationEndpoint
  • CsRgsWorkflow
  • CsMeetingRoom LineURI
  • CsMeetingRoom PrivateLine

And you know what you don’t want to do? You don’t to have to dig out PowerShell and search all of these manually. What you need is a script to do this for you, and while there are a couple out there, the one by Lasse Wedø is my favorite.

It’s comprehensive, well-written, has nicely formatted output, and has a tonne of parameters available if you want to do a more complex search. The simplest form of search looks like this:

PS Search

which seems just about right to me. Download the script and give it a try next time you run into duplicate number issues.

Main Number Handling – Auto Attendants

I’ve written quite a bit about SfB Response Groups, so let’s dive into their Exchange cousin, the Auto Attendant – AA for short.

Auto Attendants allow Exchange to answer calls to your organization. You can play greetings, set schedules, allow callers to reach your users by saying or spelling a user’s name or dialing their extension, or you can provide them a list of options that they select by pressing a key.

Creation

To create an Auto Attendant, open the Exchange Admin Center, select UM dial plans, open the dial plan that you want the AA created under, and click the + in the Auto Attendant section.

You’ll need to provide a name, indicate if you want the Auto Attendant active immediately after you create it (you might not if you’re preparing for a future migration), indicate whether you want the AA to respond to voice commands, and provide a phone number to reach the Auto Attendant at. Note that you don’t *have* to provide a phone number, which is handy for lab work and setup before a migration. You will of course need to circle back and provide at least one phone number before anyone from the PSTN can use your AA to reach your organization.

If you’re in a SfB environment, you’ll need to run the New-CsExUmContact command to create a contact object so that your SfB environment knows about the AA endpoint. Non-SfB environments will need to follow different setup steps which I won’t cover here.

Options

Now that your AA is created, you can double-click it to configure additional options.

ConfigMenu

General

Under General, you see the same options as when you created the AA, joined by a few others: setting a language, business name, and business location. Set the name and location accurately, as they can be read to a caller by the Auto Attendant. Here, you can also set a backup Auto-Attendant, that callers can be sent to when voice recognition isn’t working well.

Greetings

Under Greetings, you can set business hours and after-hours greetings. You can also add an informational message, and optionally set this message so that callers cannot skip it. This is useful for things like unexpected closures dues to weather

Business Hours

Under Business Hours, you can set the timezone for the Auto Attendant, and then you can configure your business hours  as granular as 15 minute intervals. Here, you can also specify your Holidays using a start and end date, and specify a Holiday Greeting. Note that the holiday greeting is played from 12:01am to 11:59PM on the day(s) you configure. You can’t have the holiday greeting start at the close of business on the last day of work. You can use the announcement feature for this, or sneak in at the end of the day and reconfigure the holiday greeting to have started that day. Note that after the holiday greeting plays, callers are sent to the after-hours greeting and menu.

Menu Navigation (or not)

I’m going to skip menu navigation for now…

Address Book and Operator Access

Under address book and operator access, you can specify what permissions callers have to reach users, user voicemail without ringing the user, for searching the directory for users,  and for transferring to an operator. Note that “operator extension” here is the operators actual phone number, not what key you want the caller to press.

Dialing Authorization

Under dialing authorization, you can set where users can dial via “outdialing”.

Menu Navigation (for real)

This section is the meat and potatoes of the AA is configuration. There are two sections, business hours and non-business hours. The options within each section are the same:

  • You can upload a record prompt file – if you don’t, the AA will read the options for each entry using text-to-speech.
  • You can enable or disable menu navigation, but you do need to enable menu navigation for your AA to work, so go ahead and enable it.

If you click the + or pencil button, you can created or edit a menu entry. You need to configure the prompt, which will be read by the AA using text-to-speech if you haven’t uploaded a greeting.

Entry Configuration

You can pick when key you want to assign this action to. You can select 1-9 or timeout. 0 is reserved for reaching the operator at the extension programmed earlier.

Menu Navigation Entry

When the key is pressed, you can optionally play an audio file. After then you can select one additional action:

  • None
  • Transfer to an extension (This can be an internal or external number, so long as it is permitted by the dialing authorization rules you configured above)
  • Transfer to another auto-attendant (this is useful if you want different languages, or transfer someone to a different country or group, but please don’t try to build an IVR solution with multiple Auto Attendants)
  • You can leave a voice message for a user, without ringing them. This usually goes to a generic voicemail box
  • You can have the text-to-speech reach your business hours (you entered this carefully under the “general” section)
  • You can have the text-to-speech reach your business location (you entered this carefully under the “general” section)

The business hours and location that are read out are what you entered in the “general” section. If they are pronounced funny with correct spelling, you may need to spell them phonetically so that they sound proper. The text string that you enter is never seen by users, so you don’t need to worry about weird spellings.

If you don’t set a timeout option, callers will be offered the same menu again. I prefer this option, since there is no explicit keypress to repeat the menu choices.

Up next

Response Groups and Auto Attendants share some common features, but differ considerably with others. Up next,  a comparison of Auto Attendant and Response Group capabilities and functionality.

Main Number Handling – Shared Line Appearance

There’s another SfB call handling option that we haven’t covered yet, called Shared Line Appearance, or SLA. Where Call Pickup Group felt like “let’s cram old school PBX functionality into SfB”, SLA feels like “Let’s cram old school key system functionality into SfB”.

CsServerApplication

The first step is to create a CsServerApplication, which provides the queue-like functionality. This runs on your FEs, and you only do this setup once.

Create a User

With SLA, you create a user object (that’s not assigned to an actual person, it’s like the phantom user concept), and assign the Line URI to that user.

 

CsSlaConfiguration

Next up is creation of the CsSLAConfiguration that’s not unlike what we saw for Response Group Queues:

  • Set a maximum number of calls
  • Set busy option, which is what happens when the maximum number of calls is exceeded (like a Queue overflow). Options are busy on busy – a busy signal!, voicemail, or to forward the call to another SIP address.
  • Set Missed Call (no answer) option – disconnect, busy signal, or forward to another SIP address.

I don’t understand why an organization would allow a call to ring, and then when it’s not answered, send a busy signal to the caller. One would think that voicemail – even a greeting with no option to leave a message – would provide a better option, but hey, there’s no option to send a Missed Call to voicemail!

CsSlaDelegates

The last bit of functionality that you configure is to configure user(s) as delegates of the SLA object created above.

When a call comes in to the Shared Line, all of the delegates phones will ring, showing the caller’s information. Delegates can also see how many calls are “queued”, and can see who has answered each call.

Limitations

Delegates cannot place an outbound call on behalf of an SLA. Further, SLA is only supported on certain models of deskphones. Windows, Mac, and mobiles do not support SLA.

Summary

I’ve never deployed SLA for a main number. In fact, I’ve never deployed SLA, have never met a customer who has, and could not find any coworkers who have, either.  Compared to Team Ring (or Delegation) of a phantom user, SLA is limited to certain devices and doesn’t allow outbound calling like Delegation (which is odd, since SLA uses Delegation under the hood). I don’t understand why there is an option to send a call to voicemail when the “queue” has too many calls, and no option for sending a call to voicemail when it’s not answered.

I don’t recommend SLA for handling a main number for an organization that faces the public or paying customers. If you’re considering SLA for other uses, you need to set it up and test, test, test to see if it’s going to meet your needs. My guess is that it won’t.

Main Number Handling- Group Call Pickup vs Team Ring

Call Pickup is one of my least favourite SfB functions. It’s clunk to setup, unnecessarily overlaps other functionality, and seems to be around for those holdouts who want a modern UC system to act like their legacy phone system.

Call pickup is similar to Team Ring, in that it allows your coworkers to answer your phone on your behalf. There are a couple of differences in the implementation, however.

With Call Pickup, only your phone rings. Your coworkers have to be able to hear your phone, and  distinguish that it’s your phone ringing. With Team Ring, your coworkers phones will ring after a configurable delay. They don’t have to be able to hear your phone or distinguish that it’s your phone that’s ringing. This allows you to use Team Ring across floors, buildings, or cities. When your coworkers phones ring with your call, they’ll receive a notification indicating that it’s a call for you, and they can set a distinctive ring.

Group Call Pickup needs to be configured by an administrator, via PowerShell. This makes it a bad choice for an environment with a lot of changes. Team Ring is configured at the user level, meaning administrators aren’t required, and the user can configure and reconfigure their settings to best reflect their immediate requirements. SfB is supposed to be flexible and dynamic, right?

Group Call Pickup works by piggy backing on the call park service. SfB parks the call, and allows any user who knows the call pickup code to answer the call. There is no security here, and I’ve seen post-its on cube with pickup numbers “*300 for Bill, *301 if Sarah’s phone is ringing, *303 for John”. With Team Ring, the user can specify which team members are able to answer calls. The Team Members don’t have to remember any specific code to dial. With Team Ring, users who might answer the call are also presented with information about who the caller is. With Group Call Pickup, they just know there’s a call.

I’ve seen Call Pickup used for main numbers. For scenarios where you have a small group of people who are sitting in an open area near the reception desk, this can work well. To help those users determine if the reception phone is the one that’s ringing, use an indicator light like Blync or Busylight so there’s a visual indication, especially if the office area is noisy.

I prefer Team Ring to Group Call Pickup. It’s more inline with a UC approach where you’re provided information and allowed to make a decision. Users see information about the caller, they can click to answer instead of needing to remember and then dial a specific code, and they don’t need to listen for a specific ringtone or look for a light to know a call is coming in. Group Call Pickup still feels like forcing legacy PBX functionality on top of SfB.

Main Number Handling – Receptionist’s Account vs Standalone/Phantom User

This post is part of my Main Number Handling series, so if you’ve just recently stumbled on to my blog, be sure to check out the earlier posts, including the introduction.

One of the most awkward scenarios I’ve seen for handling a main number is to assign that number to the receptionist. It works well for low call volumes and when the receptionist is at their desk, but it falls apart in several scenarios:

  • When reception is on a break, late, on vacation, or doing one of the million+ task receptionists take on, who answers the phone? If it’s a softclient, this means an PC is left unsecured.
  • Voicemail routes to the receptionist’s Exchange mailbox. When they’re not available (see above!) messages are either not read or the receptionist needs to share their password or voicemail PIN.
  • The receptionists voicemail greeting is either their personal greeting which is inappropriate for corporate messages, or the voicemail greeting is the corporate message and doesn’t reflect the fact that it belongs to a user, when someone is calling directly for that user.

A better solution is to create a standalone or “phantom” user account for the role of the reception phone, so that the receptionist can have their own phone and voicemail and privacy of email, voicemail, and PC.

The approach that I usually see is to have the receptionist use a softclient on their PC, and use a deskphone for the main number. If the deskphone is too clunky for forwarding calls, I’ve seen SimRing and TeamRing used to have the receptionist’s softclient also be able to handle the call.

If the receptionist doesn’t answer the call, voicemails would be left in the main reception voicemail box. Other staff can retrieve voicemails via the phone, or mailbox delegation can be used to allow others access. If someone else is covering the reception desk, they can answer the phone at the desk, or choose to Simring/TeamRing their own SfB account instead.

 

Analog Recommendations

In the past handful of posts, I’ve run through some of the details on how analog devices connect to and work with, SfB. Now that the technical bits are out of the way, I wanted to provide some recommendations on how you can make life with analogs easier.

We’ve seen that analog devices really don’t become Skype for Business devices. They might as well be an extension on a PBX. If you’re not getting SfB functionality and management, and you have to buy gateways and do all kinds of extra configuration, why bother at all?

You should get rid of as many analog lines and devices as you possibly can, including faxes. 141 years of analog telephony is already too long.

There, simple enough? Well no, not really, but that statement sums up what I feel is a realistic and relevant aim for every organization deploying Skype for Business. Exceptions exist in a few cases, but in general analog needs to go.

Analog Trunks

Let’s talk first about analog trunks to the PSTN. The quality is terrible, they’re expensive in comparison to a SIP trunk channel, and they offer very poor flexibility for inbound calls. You can’t have more than one number assigned to each physical line except for when you use the concept of overlines. That means you need one line per direct phone number, and user with a direct number is limited to one call at a time. That forces you to the use of main numbers, auto-attendants, and extensions, and that’s what the 80’s were for.

For outbound calls, you have no flexibility to set caller ID. You get the individual line number, the overline number, or the telco will allow you to use the main number, but this configuration is all static, and all done through the telco.

As for emergency calls, stick a red phone on the wall beside the firstaid kit, AED, and fire extinguisher. Don’t try and use one analog line to handle emergency calls for an entire building of SfB users. In any real emergency, your users will quickly swamp one or two lines. Your Skype for Business deployment should be able to place multiple emergency calls per site, not just one or two.

Faxes and Modems

Faxes and modems work by sending sound over an analog line. The devices on either end whistle at each other. Does it really make sense to stick a piece of paper into a machine, have that machine scan the paper, then whistle over an analog line to a gateway that’s going to now digitize and packetize the audio, transmit it long distances over laggy, jittery, and potentially lossy media, then decode and reassemble that digital information back into an approximation of the original whistle, such that a second machine can listen to it and draw a picture of what is represents?

How is this still a thing that we do?

Faxes

Some organizations still use faxes. It may be a legal requirement, they may have partners that still use fax, or they just might be slow to change. First, do a quick survey of your existing machines and users. Pull some reports from the machines to see how often they’re used. Find out who uses them, and what for. There’s a good chance that they could scan to PDF and email, fax directly from MS Word via an eFax driver, and receive directly to their inbox via an eFax service.

At the very least, you can probably reduce the number of physical fax machines that you have. If you do need to keep a machine around, it doesn’t need to talk to Skype for Business, so move them off your SIP trunks and PRIs to an individual analog line.

Modems

Gone are the days of modems for accessing the Internet. Every modem that I stumble across these days is a rescue – or out of band management – modem. It makes a lot of sense to have a way to reach and administer your gear, that’s independent of that same gear. Independent is the key word.  If you need a rescue modem for anything voice related, it must be a single analog line from the telco.

Better yet, ditch the analog modems. You can use an LTE stick in a device or router, or a consumer-level DSL line to a VPN headend. This approach will also give you enough bandwidth to do more than poke away at a command line.

Alarms and Elevator Phones

These too, are best moved to individual analog lines. They don’t need to talk to Skype for Business. In terms of uptime and reliability, a boring analog line from the Telco will be rock solid. Your users that get stuck in an elevator won’t be using the elevator phone when the UPS powering your SBC or gateway runs out of juice and the call drops. If you need your elevator phone to reach someone at your organization, you can route the call via the PSTN.

When You Have To Integrate Analog

Lurking in many larger conference rooms are standards based video conferencing units. Many of these have analog connections for voice calls. Depending on how old these units are, and if you’re planning to refresh them, you may be in a position to deploy some of the fantastic options that talk natively to Skype for Business for both audio AND video. If refresh/replacement isn’t near, then you may need to go down the path of analog integration into Skype for Business. The good news is that this is the simplest form of a SfB analog device.

Paging and Enterphones

This is a spot where analog in your Skype for Business environment makes sense, especially if they’re already deployed. Many paging and enterphones (“buzzers”) come in analog or SIP versions, but Skype variants don’t exist. You’re also not going to be worried about call quality or downtime due to power outages with these. Financially, these devices likely aren’t used enough to justify analog lines directly to the telco.

Skype for Business Online

If you are planning to move to Skype for Business Online, you should be aware that there is no “CsAnalogDevice” online (there’s also no CsCommonAreaPhone). You won’t be able to take advantage of how CsAnalogDevice simplifies routing, and your analog devices won’t be SfB objects that can be added to your contact list. If your analog device needs PSTN access, you will have to obtain an on-prem PSTN connection, there is no way to use a Cloud PBX with PSTN Calling number.