Have you already noticed that there are big differences with regard to architecture in current attendant solutions? This article highlights the key differences of the various architectures and the resulting possibilities for companies who make use of them and for their attendants.

Attendant Solutions without Servers

Attendant solutions without servers are solutions which – as the name indicates – operate without servers. These are installed directly on the attendants' computers. They offer users much more convenient options of accepting and handling incoming calls than conventional softphones or desk phones. There are two variants: those which require a conventional set or softphone and control it remotely, and those which contain the telephony features, e.g. which are themselves in principle softphones.

What these solutions have in common is that they cannot contain their own call assignment mechanisms because they do not have a server which they can use for this. For this reason they are based on corresponding features of the connected telephony systems, such as the "response groups" of Lync or Skype for Business or, to name an older system, the "automatic call distribution" feature (ACD) of the Avaya CS1000 PBX.

This fact makes them dependent on individual manufacturers as the call assignment mechanisms function differently and have to be operated differently from one system to another. Admittedly, while this is restrictive for the manufacturers of the solutions, it is of little consequence for most customers.

But there are also restrictions for customers. As the call distribution features of the telephony system are used, the attendant solutions cannot implement any further features than those provided by call distribution. For example, it is often not possible to view the data of individual calls in the queue or to pick calls directly from the queue. And in the case of recalls, you have to rely on the telephony system supporting this correctly.

A further problem area in a configuration without an associated server is undoubtedly the exchange of data between the individual attendant consoles. Questions such as "Which operators are currently logged in?" and "Which main numbers are handled by the others?" are certainly a primary concern here. Depending on the possibilities of the telephony system, problems also arise with regard to operating hours and automatic transfer of calls outside operating hours, as well as visualization of the current statuses of the main numbers (for example "Is the main number currently diverted and where to?").

But that is not all. As call assignment is carried out on the connected telephony systems, the related configuration options can mainly be found there.

And one more thing: In attendant solutions without servers, the connected telephony systems are also responsible for the provision of statistics data on the load of the queues. If they do not provide this data, the clients have no chance of accessing such data unless they have their own server. At the end of the month good statistics depend on what is provided by the telephony system.

Clearly, solutions without a dedicated server also offer advantages, such as high availability. Precisely because they make use of the distribution mechanisms of the telephony systems, they are less susceptible to system failures; if the telephony system is working, the attendant system will also be working.

Server Based Attendant Solutions

In contrast to the above-mentioned solutions, server-based attendant solutions have their own server (or several servers) as well as clients, which have to be installed at each workstation. The clients function in exactly the same way as described above: they are either softphones themselves or, if necessary, they control connected telephones.

The clients also have the option of communicating with their own server. When an operator logs into a client, the latter informs the server. The server can then maintain a list of available clients and it also knows their statuses. The server is therefore able to inform its clients about the statuses of other clients at all times. The clients can now in turn display this information to their operators, whereby, theoretically (if implemented), these can see at any time who is currently logged on.

However, server-based attendant solutions primarily manage the calls themselves. Incoming calls to their main numbers are put through by the telephony system. This is usually done via SIP communication, but is not necessarily the case. Depending on the manufacturer, proprietary APIs can also be used, e.g. JTAPI with Cisco.

Whenever a call comes in, the server has to decide what to do with it. If an operator is available, it puts the call though to him. Or it places the call in a queue. Or it forwards the call to a forwarding destination, e.g. outside operating times. The server thus implements call distribution itself, in contrast to the scenarios mentioned above. And this "proprietary" call distribution offers many advantages, which have a direct impact on features on the customer side.

In this way, the server not only has full control of the logged-in operators but also knows the status of the queue at all times. It can distribute this information to the clients, which in turn can display it to the operators. And in this way it offers the operators customized functions which may not be provided by the connected telephony system. Rejecting calls, for example. Or handling recalls. Or visualization of the queue. Or picking calls from the queue. And in general anything else which customers would like to do with calls in the queue. Wallboards can also be easily managed, as well as customized attendant statistics and sophisticated call distribution with special features and related configuration options.

These solutions therefore offer much more potential than pure client solutions as the "own application" is fully aware of the statuses of queues and logged-in operators and because it implements call distribution itself. And this is directly reflected in the host of features offered by these solutions in contrast to solutions without servers.

Web-based Attendant Solutions

Recently, web-based attendant solutions have introduced other forms of attendant consoles onto the highly competitive market. They are introducing a technological change to attendant solutions, by moving the user interfaces to the web browsers. In view of this, manufacturers have to use state-of-the-art technologies; for after all, attendant consoles are relatively complex real-time applications. HTML5, CSS3, WebSockets and REST are therefore used, for example.

Telephony in particular may present a major challenge for these solutions as the client-side connection to the telephony cannot be used (as they are web-based, they cannot install programs on the clients). These solutions must therefore be able to control the telephony on the client side from the server, and in general two approaches can be considered: either control of client telephones via TAPI or JTAPI, or using the browsers themselves for communication, namely with WebRTC, or ORTC.

With web-based attendant solutions, no software is installed on the client. This is a major advantage. It not only does away with the need for the initial installation, but also means that updates do not have to be installed on the client at a later date.

However, web-based applications always require a server; the browser application has to come from somewhere. With web-based applications, this server usually also controls call distribution itself, which means that all the advantages of server-based solutions also automatically apply for web-based attendant solutions.

And, if the solution is based on WebRTC, there are once again three major advantages: desk phones are not required, the clients are not tied to a location and thanks to WebRTC, the attendant solution can also be used from outside the company without special firewall rules having to be adapted.

The above-mentioned categories of attendant solutions are certainly the most important ones. There are, however, also mixed forms which were not mentioned here. Each solution has advantages and disadvantages, and it is not possible to make a general comparison when evaluating the various architectures.

It seems important to me when evaluating attendant solutions to not only scrutinize individual features, but also the architectures, so that you can also see the potential of the solution and whether, if need be, it would also be able to cover any future customer requirements.

You may also be interested in this blog: "What is an operator console?".