The last two posts covered the options available for distributing calls to agents in a call queue. In the first of those, I mentioned that there are some gotchas that can cause you some pain. Let’s cover those, and provide a few tips and tricks to make life easier.
Presence-based routing is a hot-topic for some of my colleagues. One has been bitten by having a Call Queue trigger the timeout action because no agents were available. Why? They were all either in meetings, or had populated their calendars, causing their presence to be “busy” or “in a meeting”. This could be a legitimate scenario and a good use of the overflow options (to another queue or to voicemail, perhaps), but is probably sub-optimal if all of your agents have items populated in their calendars. Perhaps they’re staff at a Microsoft partner and have their time allocated for various projects and tasks throughout the day, but need to be agents in a support queue. Turning presence-based routing off would make sense here. On the other hand, if your agents are less calendar focused, perhaps they’re helpdesk staff, then presence based routing would make sense. There’s no point in ringing a helpdesk agent who’s on a call to take another call!
Round Robin and Serial routing need to have an ordered list of agents. That’s in another spot in the Call Queue configuration in Teams Admin Center, and it gives you three options:
For round robin and serial, you will want to add only users here. There’s no way to prioritize agents in a group, or in multiple groups. (And choosing Team here is an entirely different set of blog posts!)
Call Agent alert time seems straight forward enough. Ring an agent for x seconds, and then move on to the next agent, again for x seconds. If you have a timeout configured for the queue, the timeout action will only take place at the end of a full agent alert time. For example, if your queue timeout is 20 seconds, but the agent alert time is 15 seconds, the first agent will ring for 15 seconds, then the next agent will ring for 15 seconds, then the timeout action will trigger.
When cycling between agents, the caller doesn’t notice anything different in the ringback that they hear. Agents will see the call come and then go. If for some reason an agent is offered the call again – maybe they’re the only ones that are Available and you’re using presence based routing – the ringing will stop briefly and then start again.
If you have an agent alert time that’s less that a queue timeout value and you’re using Attendant mode, all of your agents will ring for the alert time, then ringing will stop, and then it will start again. This is annoying, so sync up those timers to get rid of this.
If you’re coming from the Skype for Business world and are familiar with Response Groups, you’ll notice some similarities with call queues, and a few differences. First off, SfB has an Attendant routing mode. The Teams equivalent to that is “Attendant with presence-based routing off”. SfB has a mode called Parallel, and that is Teams “Attendant mode with presence-based routing on”. You’ll also note that there aren’t any IVR options or schedules in Call Queues. If you need those, you should build an Auto Attendant, and have the auto attendant send calls to the call queue(s). Why this change? I’m not certain, but it likely had to do with Auto Attendants being an Exchange item that SfB (and other systems) could take advantage of, and now Teams has Auto Attendants, not Exchange. It doesn’t make a lot of sense to have schedules and IVR functionality in both Auto Attendants and Call Queues, when you can easily snap them together into whatever combination of objects you’d like.
And finally, the docs article for call queues is FULL of all sorts of different exceptions and limitations and recommendations. Make sure you read through the exceptions and limitations. I don’t put a lot of weight in the recommendations like “use presence based routing” as there’s no explanation as to WHY that is recommended. And as explained above, there are legit reasons to not use it. Similarly, there’s a recommendation to use longest-idle or round robin, and yet I can list out a handful of reasons to use other methods without too much effort. If you’re not sure about these, run a proof of concept and try them out.