If you are completely honest to yourself: You still try to call someone or get in touch via chat or a different phone number if you want to get a hold of a colleague urgently – even if the presence status is set to busy.
What’s more, only colleagues with access or connection to your UCC solution will be able to view your presence status. External callers without this access will not be able to see your presence status.
I [Johannes Nowak] have been working with solutions that provide presence information for over 20 years now. I was already intensively involved with this topic back in the day when I was product manager for a presence server. By the time Skype made it possible to log in "offline" (meaning your status is displayed as offline even though you are online), it was clear to me that presence information can only be a very vague indicator of the actual status.
The significance of working with the presence status varies greatly from country to country. In Scandinavian countries, for example, setting and respecting the presence status and the stated information within the status is much more established than in Germany, also because colleagues are less likely to take on calls directed to others. There are also specific differences between the users: Some do not even think about contacting someone whose status is set to "busy". Others don’t call but send a chat requesting to be contacted. A third colleague simply disregards the status display and calls. The caller from outside the company who does not even see this information naturally behaves in the same way. Especially for callers from outside the company PBX, so-called "spoken presence" solutions can be useful. It will tell them when someone is unavailable and when availability can be expected again.
Currently, there are many efforts to interconnect all presence information from different systems - e.g., the telephone system and Microsoft Teams - and to create an all-encompassing presence status. But: what is the proper presence status for each situation, how is it used sensibly, and what are its implications? Does every employee know how a presence status is generated and how it is to be interpreted? Is there in-house training on this topic?
Let us first figure out how my presence status is created: One the one hand, it is generated by the UCC solution itself, depending on whether I am logged in, logged off, whether I am active or inactive. Does my solution then offer an additional status such as “on the phone”? This may sound simple but there is a catch since many solutions will switch a user to “inactive” or “offline” if the end device or the mouse has not been used for a while (i.e. no activity with the computer mouse or keyboard). The status of the user will be displayed as “offline” even though you are very well at the office, actively discussing things with your colleague, outlining a concept on the whiteboard or testing new product samples. And what about being switched to “inactive” automatically because my computer mouse has not been moved around, even though my client is opened on my smartphone? What should be possible with this “offline” status? Should colleagues be able to call me – or better not?
Having a merged presence status from different original sources is also not always ideal. If I am an active speaker at a Microsoft Teams meeting (e.g. Zoom or WebEx), I may not want to be interrupted during this meeting. Should I only be a passive listener, I may still want to be able to answer calls from customers. How should inbound calls be handled by the telephone system in this situation?
No matter what logic you incorporate, there will always be the one user that defies this logic. The pervious examples show that the coin always has two sides and that one situation will allow for different interpretations.
Presence information will only be enhancing the efficiency if all employees have a unified approach on how to use the presence information and presence status. Users should know when and how to set the personal presence status. Yet, automated processes with a presence status that directly synchronizes with the own calendar while including the state of the end device provide an advantage. Users then also need to know how this presence information is to be used when they want to get in touch with someone. Am I allowed to call if the status simply indicates “busy” or should I just use asynchronous communication channels instead? What about GDPR regulations and how much information do I need to make available since my presence status may very well be used to draw conclusions on my current behavior.
Presence technologies are currently far from being fully exhausted when we are looking at the technical point of view. It is possible to provide even more information with the presence status than typically implemented. Consumer solutions for example already provide functions that show when the user was last online or how long the user has been online. Further, GPS and Bluetooth connectivity to specific end devices or tokens can enable local presence information. This is already common in the healthcare sector, for example. Especially during the pandemic with large numbers of the workforce working from home, it is very convenient to see if a colleague is at the office or working remotely. Again, it is highly recommendable to have a company agreement in place for using such private information since companies are required to protect personal data.
innovaphone myApps provides the presence status across various end devices. The presence information can be set manually directly within the client, extracts information from the Outlook calendar and displays the busy status when the user is in a phone call. All this information is merged to constitute the presence status. Information from other systems such as Microsoft Teams complement the solution. It is also worth emphasizing that presence information can be read and set via our open interfaces (APIs). Therefore, it is possible to adapt to the respective requirements and integrate into the existing environment at any time.