Dashboard Supervision

Users with a “Supervisor” role can leverage "Supervision" widgets on their Personal Dashboards to join or listen into active call sessions of Services & Users

PRECONDITIONS

  • Contact Center Supervision features require both a Contact Center license and either User or Service "SupervisorPortal User Role assigned. This is done via User Administration > Roles Tab.
  • Note that Supervisors can (only) act within within given Organization Unit constraints. If further users need to be supervised, the "Supervisor" role needs to be granted within those extra Organization Units accordingly. More about this can be found on the Role Access Concept page.
  • Nimbus needs to distribute a service call to a (Team member / Agent / Attendant Console) user first before the session become visible in the supervision widget.
  • Also note the “Known Limitations” on the bottom of this page.
 

🔍 Nimbus Dashboards have several Dashboard Widgets with supervision features. Select one of the tabs below to learn more.

 

Inbound / Outbound Service Supervision 

✅ Requires "Service Supervisor" User Roles. → See Preconditions above.

🔍Supervision is performed using the "Service Supervision" Dashboard Widget. Also works for scheduled Outbound Calls and Call On Behalf, as both features refer to a specific service during the call.

 
Mode Details When Supervisor joins ... When User parks … Supervision ends when...
Listen The Supervisor hears both Caller and User, but cannot talk to anyone. Agent and Supervisor will hear 1 beep. Music is played for the Caller
  • Session gets transferred.
  • The User leaves.
  • The Customer leaves.
Whisper The Supervisor hears both Caller and User, can talk to the Agent. Agent and Supervisor hear 2 beeps. Music is played for the Caller
  • Session gets transferred.
  • The User leaves.

💡 The session persists as long as either User or Supervisor remain

Barge In The Supervisor hears both Caller and Agent (Nimbus user), can talk to everyone. Agent and Supervisor will hear 3 beeps. No music is played for the Caller as the Supervisor joined in "Barge In" mode
  • Session gets transferred.

💡 The session persists as long as either User or Caller remain

Usage Notes
  • The "Controls" column is used exclusively to engage in Supervision
  • mode indicator will show the currently active mode. Controls will change states when any Supervisor joins.
  • An escalation of modes is possible from Listen → Whisper → Barge In but not in the other direction.
  • Successfully joining (or failing to join) will also show a quick toast in the Nimbus UI.
  • When you edit your Dashboard you can adjust Widget Properties to filter by certain users or apply colored thresholds. 
Supervision Dashboard Widget with some adjusted color thresholds 
 
 

User Supervision

✅ Requires "User Supervisor" User Roles. → See Preconditions above. 

🔍 Supervision is performed using the "User Supervisor Tabular" Dashboard Widget.

 
Column Details
User Name User Name - as defined in the User Administration
Presence State Presence State (as per MS Teams client). 💡 Read-Only, cannot be changed.
Presence Activity Presence Activity - shows the extended presence (e.g. Out of Office, Busy in a call, etc.) if extended presence tracking is enabled for the tenant.
🔍 Refer to Use Case - Tracking Extended User Presence via Application Permission for more information on how to enable extended user presence tracking for your tenant.
Duty State / Duty Profile

You can immediately change the profile of any user. 

🔍 Notes: 

  • The Duty State relates directly to the Responsibility Profiles currently selected by the user.
  • The list of available profiles depends on the Organization Unit of the corresponding user.
  • A blocking User State (e.g. Busy or Away presence, ACW, RONA) may still prevent calls from being distributed.
ACW

Current ACW (After Call Work) status of the user.

🔍 You can immediately end ACW. However a User State (e.g. Busy or Away presence set by the user) may still prevent calls from being distributed.

🔍 ACW be configured via Distribution Service Settings.

Extended ACW

Extended ACW (After Call Work) of the user.

🔍 ACW be configured via Distribution Service Settings.

RONA

RONA (Return on no answer) status flag when a user did not respond in time.

🔍 You can immediately reset this flag. However, a related User State (e.g. Busy or Away presence which caused this RONA flag) may still prevent calls from being distributed.

Controls

Allows you to directly call or chat with the service user (Agent). 

💡 A click uses MS Teams deeplinks for your browser and may ask you for permissions initially. Note that calls only use the Teams UPN of the user, not Mobile or PSTN.

Usage Notes
  • As you edit the Dashboard you can adjust and filter the widget via various Dashboard Widget Properties .
  • The "Controls" column is using default MS Teams functionality. Direct calls or chats with Agents are not reflected in your service Reporting.
  • The columns for Duty Profile, (Extended) ACW and RONA will update in accordance to what the supervised user (Agent) will see. Switching profiles or ending a user status immediately reflects back on the user's side and UI.

🔍 Note that a User State (e.g. Busy or Away presence) outside your control may still prevent Nimbus from distributing calls.

Learn more about "User States" in Nimbus

User States

For its Reporting Model, Nimbus distinguishes sessions by various user state factors: Teams Presence, Duty State, Task Selectability, and User Status flags. A change in either factor has influence on the others, either in being a requirement or in a co-dependency.

Factor Precondition(s) Tracked User State relevant to Nimbus
  Teams Layer
Presence in MS Teams ✅ Online – including status "Busy" or "Away"    
(individually defined per Distribution Service Settings)
Online
MS-Teams based services will distribute when "Active".
Online and set "Active" in Nimbus     
MS-Teams based services will distribute. 
Online but Busy/Away in Teams and set "Active" in Nimbus
Conditional: Determined per each service's Distribution Service Settings aser can either be selectable ↓ or not.
  Nimbus Layer

✅User is online and has any "On Duty" responsibility profile selected.  
✅User is assigned to the Service as “Agent”

Off Duty     
Being in an "Off Duty" profile pre­vents any Contact Center participation.
On Duty       
Any "On Duty" type responsibility profile allows Contact Center participation. Skills and Responsibilities in that profile must match the service to be "Selectable"  . This is determined by the individual Distribution Policies assigned to the respective services.
Task selectable

“In Time available” to perform tasks in Nimbus:

✅Online in MS Teams.   
✅Set to "Active"  in any MS Teams-based service .
✅In "On Duty" profile for Contact Center services.

  "Selectable"   
This includes Busy/Selectable and Away/Selectable
"Non-Selectable" state, either because:       
User is not available either due to the MS Teams Presence ↑ OR …
set "inactive" for all Nimbus teams OR …
... any existing or previous Status Flag ↓ marks the user as “Not Selectable”
User Status flags

✅ User is currently reserved and blocked by a Nimbus task.

 

  Not Available Reason   
Requested from “Idle / Away” users during a task distribution.
RONA   
User flag after not responding to a task, blocked for the next tasks.
Ringing   
User is reserved for new task, but has not accepted yet.
Connected       
User has accepted and is now blocked by a task. 
ACW   
User-extensible timespan to complete work after a call.

USER STATE FACTORS ARE CO-DEPENDENT

💡 It is important to note that these user state factors depend on each other. The table above should be read vertically from “top to bottom and back". 

Multiple factors can influence the User Status - and in extension - the Task distribution within Nimbus: MS Teams Presence, Service Settings, Active State OR Duty Profile selection

🔎 In the following we're explaining each factor and its related co-depencenies:

Factor 1: MS Teams Presence

This factor is considered by all Nimbus services. Every user in MS Teams can be considered for Nimbus when part of a service.

  • The MS Teams presence must meet the criteria of the Distribution Service Settings. This can be individually configured per service.
  • Offline users are not considered to be in any Duty State. Nimbus will not distribute tasks.
  • Online users are considered for Nimbus tasks depending on:
    • … the services they are part of and
    • … the Nimbus features (e.g. licenses, modalities settings for the user.)

🔎It is noteworthy that “MS Teams presence” marks only the first layer of consideration for Nimbus. When users participate in multiple services, each service can individually regard them as “selectable” or not. Learn more about this below.

 
 

Factors 2 & 3: In Nimbus Duty State / Task selectability

These are shared criteria among services. Task Selectability in Nimbus is steered based depending on the Types of Service the user participates in.

Advanced Routing and Enterprise Routing   Contact Center
MS-Teams "Team”-based services with a fixed pool of team members.  Nimbus standalone services with a dynamically assigned user base

Advanced Routing and Enterprise Routing consider users selectable once they are set “Active” in the Nimbus UI.

💡The Duty State is a Contact Center exclusive feature and not considered for these services.

Contact Center services replace the “Active” state with a Duty State as a conditional “is selectable” check

Evaluating that profile, Nimbus evaluates user responsibility and distributes calls conditionally based on Skills and Responsibilities. These criteria are defined in each service's Distribution Policy.

The entire “Online” and ”Active" pool of users with in an “MS Teams” Team is considered. Any “Online” Nimbus user can be considered depending on the factors above, regardless of “MS Teams” membership.

🔎When users participate in multiple services, each service can “flag” users with a blocking status as they handle tasks. Learn more about this below.

 
 

Factor 4: User Status (Flags) and Reporting

These are shared criteria among services. 

  • While “online” in Teams and “Active” and "On Duty" in Nimbus, a user is in principle “Selectable” for tasks by any service, in any modality, unless they are in a blocking status in Nimbus.
  • The “online” status in combination with “Busy” or “Away” in Teams may be reported as either “Selectable” or “Not selectable” state, depending on the configuration set under “Conversation Distribution” for the specific service.
  • Blocking status in Nimbus always takes precedence over any "Selectable" state; therefore, while being in any blocking status (e.g. Not Available, already busy when connected or in a task, in ACW or flagged by RONA), no new task will be distributed to the user.  ACW, Connected and Ringing are reported as dedicated states, all other blocking statuses are reported as “Not selectable”.
  • “Offline” in Teams or “Off Duty” in Nimbus are reported as dedicated user states. 

User State Reporting and Data Privacy

Each time a user changes from one status to another a user state, a record is completed and written into the database. Only completed states are tracked in the Nimbus Reporting, therefore the current user state (e.g. “as of now”) will not appear in the database until the user has switched to the next user status. 

Considering that a user status can change frequently throughout the working day, the User States data can become very large when looking at multiple dates. 

💡GDPR Data Privacy Setting: detailed user states data allows for time-based analysis of the states of each user, e.g. in Power BI. Tracking of this data must be explicitly enabled via Tenant Administration > Data Privacy in order to be recorded in the historic reporting.

 
 
 
 
 

 

 
 

External Tasks

✅ Requires "Service Supervisor" or "Service Owner" User Roles. → See Preconditions above.

🔍Task handling is performed using the "Service External Tasks" Dashboard Widgets.

What are external Tasks?

The Nimbus Task Distribution algorithm can also distribute External Task to users. Such tasks can be created using the Microsoft Power Automate Connector and added to the service queue along any regular task. By the use of Workflows an external task is fed into the queue of any service and can also be transferred or reprioritized. 

💡As Supervisor you can abort External Tasks via the "Service External Tasks" Dashboard Widgets.


✅ Note that External Task have additional preconditions and require technical setup by an Administrator. Refer to Use Case - Creating an External Task. Our chapter External Task Handling shows where and how these tasks can be handled within the Nimbus UI.

 
 
 
Column Details
Source Shows the origin / creator of the external task. Tasks are created using the Microsoft Power Automate Connector > "AddExternalTask" Flow Action.
Service Name Service which will handle the External Tasks via it's queue according to the "External Task" Workflow configured in the Modality Service Settings.
State

Shows the state in which the task is in:

  • In IVR, In IVR After Queue, In Queue, Parked, Connected, Transferring
Time in State Time since the task has remained in this state.
Connected to User to which the task has been distributed.
Level Level of distribution on which the task-receiving user got the task. 🔍 Service-applied Distribution Policies determine the levels and user pool. 
Priority

Task Priority, set when the task was created.

💡 Tasks with higher priority get moved up ihn the Workflows "Queue" activity and prioritized for distribution accordingly.

Controls

Allows to remove the task, as long as it is not shown "Connected" to a user already.

💡 A confirmation pop-up will ask you to confirm the removal.

🔍 Note that Tasks can also be removed via Microsoft Power Automate Connector > "RemoveExternalTask" Flow Action, making them immediately disappear from Dashboards and other views without further notice.

 
 

Known Limitations

INC Supervision Limitations

KNOWN SUPERVISION LIMITATIONS

  • If the Nimbus User adds any other participant via Microsoft Teams UI, the Supervisor will not hear the new participant.
  • Only one Supervisor can join a session at the same time. The UI will indicate when there is already a Supervisor in the session.
  • A Supervisor can join sessions with 1:1 Caller / User active mode. Joining of consulting / merged / expert sessions (mainly used in Attendant Console call scenarios) is not supported at the moment.
    • After a Supervisor joined ...
      • ... the Agent cannot make consultations anymore until the Supervisor leaves.
      • ... the Agent cannot join experts anymore until the Supervisor will leave.
    • The Supervisor will not be heard in the recording of the user.
 

 

 

Table of Contents