Skype For Business with Exchange integration...Specifically, Interactive Response Groups vs. Exchange Auto Attendant

Posted on 2016-09-06
Last Modified: 2016-09-22
We are in the process of deploying Skype for business to our infrastructure.
the question that came up was which method of call processing is preferable and what are the pro's and cons of each or of using both.

in my research i haven't found a definitive reason for one over the other (at least for basic call menus)

specifically this is the question i'm asking.
if anyone has any insight into this that would help.
Question by:masteritlion
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
  • 4
  • 3
  • 2
LVL 58

Expert Comment

by:Cliff Galiher
ID: 41787017
For basic call menus, an autoattendant should be fine. You'd purchase and implement an IVR if you found you needed those advanced features.

Author Comment

ID: 41787067
i thing you misunderstood my question..
we have both the Exchange Auto Attendant and the Interactive response groups (builtin to sfb) as two different ways of implementing call menus. We have the ability to use either or.

my question pertained to the nuances of each option and i guess may also be considered personal preference. however we'd ideally like to see some definitive information on this subject as microsoft documentation is rather ambiguous pertaining to which should be used when.
LVL 58

Expert Comment

by:Cliff Galiher
ID: 41787233
Skype for Business does not have IVR at all. Nor any automated menu creation system. It relies on exchange or third parties for that functionality.

The "Response Groups" feature in Skype for Business (note it is *not* called INTERACTIVE Response Groups) is much more like the "hunt groups" feature in other PBXs. There are no significant menus or interactivity.
Get free NFR key for Veeam Availability Suite 9.5

Veeam is happy to provide a free NFR license (1 year, 2 sockets) to all certified IT Pros. The license allows for the non-production use of Veeam Availability Suite v9.5 in your home lab, without any feature limitations. It works for both VMware and Hyper-V environments


Author Comment

ID: 41787257
i'm not trying to argue with you but clearly these options exist in SFB (at least they do in the latest CU)
LVL 58

Accepted Solution

Cliff Galiher earned 250 total points
ID: 41787315
But they aren't designed for menu systems. If you actually read the documentation instead of relying in screenshots, you'll see that the GUI only allows two levels of questions and only for answers. While you *can* do more complex setups using PowerShell, it becomes quite complex quite quickly. Equally importantly, the responses are sent to the agent in the queue. Important if you have one queue for your help desk, but want each person to see the problem being reported (network, software, hardware.) The choice doesn't necessarily change the call route, but *does* provide information to the agent.

In short, they tackle two very different scenarios. The response group service will eat significant resources on the servers in which it runs (the documentation also has sizing) and enterprise voic servers tend to have high utilization anyways. For menuing, it is almost always better to offload that to exchange UM in organizations that riun both exchange and SfB (a surprising number don't.

With that in mind, it isn't uncommon to see the UM attendants handle most of the menu trees, and then transfer the SIP session back to a response group for final processing. For example, exchange attendants may handle department routing (press 1 for sales, 2 for tech support, 3 for human resources) then shift the call of tech support to a response group with a single queue and a question to identify the type of problem So the agent knows the situation.

In short...It isn't an either/or but a "right tool for the job." For simple menus, offloading to exchange is wise in most circumstances. There will be edge cases, such as only one exchange UM server in a multi-site org with slow WAN interconnects....processong calls locally may be better than shuffling that traffic over a slow WAN link..but those should be exceptions, not the norm.

Author Comment

ID: 41787888
What we were looking for was a simple call menu, which is what i initially stated in the op.
i do fully understand that either solution won't support complex workflows or have crm/erp integration for data lookup etc. but we weren't looking for that.

the second half of the explanation however is more inline with what i was asking. since there isn't any sort of flowchart from microsoft detailing which is preferable in which situation. this kind of in depth knowledge is what we were looking for.

our deployment has been configured according to best practises in an HA cluster. (currently without the menu's) the same as with our exchange deployment.

Expert Comment

ID: 41795161
We are currently moving from AVaya to SFB and are using both Normal and IVR response groups. The IVR response groups have a limitation where if you call the number(or contact) for the IVR, you are limited to 4 responses with each response having 4 options available. This limits things some. Another issue is if you have several Queues selectable from the menu, such as Sales, Support, etc... and have someone who is in multiple queues, the call will only say the name of the main response group as Caller ID. this can be confusing in some aspects. You an get around that by setting queues with empty groups and forwarding the queues to another response group (this has worked for us).
  From reading your initial question, which is preferable, I say both. An Exchange Auto attendant allows you to search for a name. A Response group will act like a Hunt Group, ringing a set of numbers every time (you can decide how) or gives you a "poor mans " menu. I say poor man because compared to full Call Center Suites, or even the Call Center agent functionality built into systems like Avaya and Cisco, it is extremely limited. What you use really depends on what you need.

Author Comment

ID: 41797341
my question mostly refers to the menu options. yes it's not an integrated menu into an erp etc. however for purely menu driven functions, which is optimal. once directed to a sales or other location it can transfer into a response group. i'm not worried about that part.

Assisted Solution

lvjeff earned 250 total points
ID: 41798017
I guess is depends on how you are setup. IF you have one external number and want to have one "interface", then I suppose you could use Exchange AA and have it recognize like "Sales", and then direct it towards a Response Group. To be honest, I never thought of doing that since it would not fit at all in our organization. If you have different external numbers for say Sales and Support (perhaps, a different 800 number for each), then the Exchange AA option would not be optimal.
  In my experience, the Exchange AutoAttendant Voice Recognition does leave a little to be desired. We have only about 60% success rate on the first try.

Featured Post

Office 365 Training for IT Pros

Learn how to provision tenants, synchronize on-premise Active Directory, implement Single Sign-On, customize Office deployment, and protect your organization with eDiscovery and DLP policies.  Only from Platform Scholar.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

This article explains how to install and use the NTBackup utility that comes with Windows Server.
There are times when we need to generate a report on the inbox rules, where users have set up forwarding externally in their mailbox. In this article, I will be sharing a script I wrote to generate the report in CSV format.
To show how to create a transport rule in Exchange 2013. We show this process by using the Exchange Admin Center. Log into Exchange Admin Center.: First we need to log into the Exchange Admin Center. Navigate to the Mail Flow >> Rules tab.:  To cr…
The video tutorial explains the basics of the Exchange server Database Availability groups. The components of this video include: 1. Automatic Failover 2. Failover Clustering 3. Active Manager
Suggested Courses

617 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question