Altigen Communications : Tech Talk – CoreAttendant for Microsoft Teams

Attendant Console for Microsoft Teams

Altigen's Tech Talk is a chance for us to dive deeper into the world of telecommunications. Often hosted by our Chief Technical Officer, Mark Allen, these blogs will talk about the future of the modern workplace.

We're here today for our tech talk with Altigen's CTO Mark Allen and we are excited to talk today about attendant consoles.

Q: Attendant consoles have been around for quite a while, and we'll get into that in just a minute here. But to start off, Mark, Altigen is releasing a new solution called CoreAttendant, could you explain what that is?

A: Let's start by equating CoreAttendant to an older technology by name and then we can help fit that into a more modern technology framework which we're doing today. CoreAttendant is a receptionist console, so what does that mean? Receptionist console refers to a back in the day technology, when the receptionist would sit at the front desk and had a physical phone that had, usually referred to as, a sidecar, which was an attachment to the site of the phone that had everybody's extension with light up buttons. As a call came into the company, they could very quickly push a button on the sidecar and transfer the call directly to that individual in the company.
As we know that design, that physical design doesn't happen anymore, it's nothing we do with physical phones anymore. There might be something out there, maybe, but it's an exception.
The new version of that is a software-based sidecar. It's a software-based screen that's optimized for a receptionist or people who are very interested in a live answer situation to answer calls for an enterprise and very easily and quickly disperse that call to the appropriate party. And so that answers the question of, " What is CoreAttendant"? It's a receptionist console for Microsoft Teams.

Q: Why did it take so long for an attendant console to be released for Microsoft Teams? We've had attendant consoles for years. Cisco had an attendant console, there were attendant consoles for Skype for Business, and there's been attendant consoles for other phone systems, but why is it taking so long for Teams?

A: So, this question has two answers. One is a Microsoft philosophy answer. Which is important to know when you're dealing with Microsoft Teams, or coding to Teams, or when you're deciding you want to engage with Microsoft voice. The second part is just technology. So let me answer the first one.
Probably 3-4 years ago I was meeting with the CVP of Microsoft Teams Voice Strategy, and we were talking about what it's going to take to integrate products into the Microsoft Teams Portfolio and he said, Microsoft Teams is going to be the center hub for applications, controls, and experience. Microsoft has strategically not released the ability for companies to take calls from Teams outside of Teams. So, typically when you release admin consoles with a company, you write your own software and your own interface to take that experience and create a nice operator console experience around the call controls to that phone system.
With Teams you can't. You cannot take [calls] out of Teams, just the calling experience, and create a custom interface. Microsoft doesn't allow it, and a lot of people don't know that.
You are narrowed into using the Microsoft Teams experience as the interface, which is fine. However, if you're a company that has written their own solution, their own software based on some other PBX or some other switch and you try to integrate it to Teams, marrying the two together is impossible.
The reason for the delay [in releasing attendant consoles] is everybody's trying to decipher how you programmatically write call controls for Teams when it's not allowed outside of Teams. By design, Microsoft wants you to use the Microsoft Store to purchase your apps to enhance Teams. This means there is not going to be a prolific rate of software that's written outside of Teams for Teams.

Q: We'll get to this in a future discussion, but that kind of harkens to native Teams applications, as opposed to applications that are outside of Teams and using call controls outside of Teams, and so on and Web RTC and other things.

A: Correct.

Q: Could you tell us what makes CoreAttendant different from other Attendant Consoles?

A: I'll give a very specific example. Let's start with a very basic scenario. Let's say you have 100 calls coming into your main line with one receptionist, and you decide you want to queue those calls. You must use Microsoft API's (call control APIs) to call their queuing mechanism to queue those calls and then decipher which of those calls is ready to be handed to the receptionist. That's the limits of what Microsoft has released in that space. The features and the APIs are just not there for that type of scenario.
The differences with CoreInteract, is that we've gone in using the BOT framework to receive that call, we've written our own queuing engine that works natively in Azure, and we're using the Microsoft call controls to deliver the call.
Using CoreInteract on the back end for the queuing mechanism, allows us to perform functions that aren't available yet. So, we're able to compensate for some of the shortcomings using CoreInteract to be able to route calls now.
The biggest hold up is some of the technology between transferring from a resource account or a bot to another bot. That's where there's a big gap in what's available from Microsoft today and what we're accomplishing through CoreInteract. That's evident in the same example of the queuing. So, the reason we're unique is because we have written some of our own functionality and controls on the back end natively in Azure to perform some functions that we don't need to wait or rely on Microsoft to release.

Q: When I speak to other developers, I hear them say that we can't release an attendant console yet because the APIs are not there for us. How is Altigen doing this differently?

A: Microsoft released APIs for answering and handing off a call. Seems basic, but as I've mentioned, that only works in one scenario where it's a one-to-one call. The minute there's more than one call and you need to transfer that to somebody, it requires two more API's. So, when people say they don't have the APIs, they mean, the very specific API for a use case scenario, isn't available yet. They have the capability to make a receptionist console that could do one person at a time, but they couldn't do one that's more complex. We're not relying on APIs for those pieces. The APIs we rely on are for calls and those were released early on.
Q: How does CoreInteract enhance that experience for CoreAttendant?

A: To overcome some of the shortcomings for the API's that are not released by Microsoft. We've been able to release an attendant console because we can perform these functions by calling CoreInteract instead of calling Teams APIs.
We have leveraged the minimum pieces of CoreInteract to deliver CoreAttendant out to the market space, and so for every CoreAttendant deployment we do it's making some Azure calls in the back end to some of our CoreInteract cloud infrastructure.
It's only using the basic functions. You don't need all the advanced functions we use for CoreInteract, but some of the basic queuing and controls. There's always a light version of CoreInteract involved in a CoreAttendant deployment.

Q: Can you talk about CoreAttendant and CoreInteract in an Enterprise environment, that has complex routing rules and queuing rules, how our solutions are a perfect combination for customers.

A: Well, one of the biggest limitations to attendant consoles and APIs from Microsoft is the ability to transfer calls to a resource group through an application. Why is that relevant? Let's say as an operator receives a call and someone says "Hey, can I talk to Bob" and you look up Bob who is part of sales and Bob is busy and say "Hey, do you want to talk to somebody else in sales?" A very common use case.
At that point, from a technology standpoint, you would want to transfer that call as an operator to sales, which in Microsoft world is a resource group and it's not allowed, programmatically. The advantage of having both CoreInteract and CoreAttendant playing in the same pool is we can do that natively in Teams.

Q: I want to make sure everyone is clear that we are using Teams' native call controls. We're not removing the call from Teams in any way. I just want to be careful that our readers understand that the call is still in Teams. We're not removing it from the Teams Environment.

A: Correct, and without giving too much of the secret sauce away, our application receives the call from Teams on the Teams provider, and instead of transferring it to a Microsoft call queue. We hold the call, and we work the magic in the background pretending the calls been queued. And then when it's time to disperse the call, we used the transfer APIs.
But we're not leveraging the Microsoft's APIs to send that to a queue, we take care of that which has allowed us to open all these features without the dependency. The call never once leaves the Microsoft provider.

Q: I think it's important to note that the application itself is a native Teams application. We're not going out to some Web App or iframe.

A: Yes, correct, and that's the same with using our CoreAttendant. The user interface is within Teams, so you have all the capabilities of Teams in one place as opposed to separate applications.
Another key point is there are no limitation on using Microsoft Calling Plans, Direct Routing or Operator Connect with our applications. The customer is free to use what makes the most sense for them.

Q: Great! Well Mark, thank you for your time today.

A: No, thank you. I was personally taken back by the interest level of an attendant console, it's a huge need in the Teams space. So, we're excited.