Dashboard Supervision

Via the related related "Supervision" type Dashboard Widgets, any user with "Supervisor" permissions can join active call sessions of Services & Users

PRECONDITIONS

  • Contact Center SUPERVISOR Supervision features require both a Contact Center license and either User or Service "SupervisorUser Roles assigned to the user account. This is done via User Administration > Roles Tab. 
  • Note that Supervisors can only see and act on other users 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.

🔍 The Dashboards have several widgets with different user, service and task supevision features. Select one of the tabs below to learn more.

 

Service Supervision

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

Table: Service supervision feature overview

Supervision is performed using the "Service Supervision" Dashboard Widgets.

Details When Supervisor joins ... When Call is parked by User ... Supervision will end 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
  • As you edit the Dashboard you can adjust and filter the widget via various Dashboard Widget Properties .
  • The "Controls" column is used exclusively to engage in Supervision. A 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.

KNOWN LIMITATIONS

  • If the User (Agent) 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.
    • A Supervisor will not be heard in the recording of the user.

💡 We are aware of these limitations and will attempt to remove them in future Nimbus hotfixes.

 
 
 

User Supervision

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

Table: User supervision feature overview

Supervision is performed using the "User Supervisor" Dashboard Widgets.

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.

Duty State / Duty Profile

🔍 You can immediately switch the Profile of any user. However the User State (e.g. Busy or Away presence) 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 deep links 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

For its Reporting Model Nimbusdistinguishes sessions by various user state factors (Teams Presence, Duty State, Task Selectability, Call Status). These factors layer upon each other, meaning that 

Factor Definition / Conditions Nimbus-Tracked User State

Presence in MS Teams

 

Online – including status "Busy" or "Away" –  if defined per Service-individual Distribution Service Settings. Offline Online  
MS-Teams based services will distribute when "Active".
Online and set "Active" 
MS-Teams based services will distribute. 
 

Online and "Active" but Busy/Away 
Can either be selectable or not ⬇️ (determined per each Service's Distribution Service Settings)

Duty State

Contact Center

  OffDuty 
An "OffDuty" responsibility profile prevents any Contact Center participation.
On Duty 
Any "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 selectability

"In Time" available to perform tasks in Nimbus:

  • Online in MS Teams.
  • Set to "Active"  in any Teams-Based  Nimbus service or
  • In a "On Duty" profile for Contact Center services.
  🌟 "Selectable" state 
This includes Busy/Selectable and Away/Selectable
"Non-Selectable" State, either because: 
⬆️ User is not available either due to the Presence state in MS Teams or set "inactive" for all Nimbus teams or 
⬇️ ... any existing or previous Call Status marks the user as "Not Selectable

Call status

 

Reserved and blocked for a Nimbus task.

Any of these status flags occur during or after a call and prevent selection for further tasks until resolved.

  Not Available Reason 
Requested as the user changes MS Teams presence (manually or from idle).
RONA (Redirect on No Answer) 
User flag after not responding to a task, blocked for the next tasks.
Ringing 
User reserved for new task, but has not accepted yet
Connected 
User accepted task, is blocked by it

USER STATE DEPENDENCIES

💡 It is important to note that these user state factors depend on each other. Reading the table vertically from "top to bottom" here are some examples:

  • Offline users are not considered to be in any duty state. Nimbus will not distribute tasks.
  • While "Online" ...
  • For any service: While "online", "active" and "on duty" a user is selectable for tasks. Users can participate types of service simultaneously via their "Active" toggle and Profile selection accordingly.
  • Any Call status (e.g being Not Available, already busy in a task, in ACW or flagged by RONA) will flag the user as "Not selectable"

🔍 Learning: Users have one deterministic state at a time. Combined factors listed above form a "User Session" and are tracked as part of the Nimbus Reporting Model. Detailed user states can be tracked with timestamps for evaluation. This is enabled via Tenant Administration > Data Privacy, and included in Power BI historic reporting.

 
 
 

 
 

External Tasks

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

What are external Tasks?

The Nimbus Task Distribution algorithm can also distribute external tasks 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 transfered or reprioritized. Supervisors can abort a task early by using Dashboard Supervision features

PRECONDITIONS

Contact Center External Tasks are an additionally enabled modality, alongside your Contact Center services.


🔍 FAIR USE POLICY: As external tasks can be created in bulk via external flow loop, they underly a fair-use policy. The maximum allowed limit of concurrent tasks is controlled by Luware on Tenant Administration level. This limit is also in place to ensure that potential erroneous loop conditions don't create a large amount of "stuck" tasks, blocking up service queues.

🔍 Hands-on: Learn how to create external tasks by reading Use Case - Creating an External Task.

 

External tasks can start their lifetime outside any regular Nimbus session. They are also not limited to "classic" call modalities in MS Teams, as they can help coordinate and communicate activities such as: 

  • Booking a hotel room or flights
  • Daily maintenance routines in the office
  • Reminding people of activities outside the typical call center routine
 
 
Table: External task feature overview

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

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 "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 appear from Dashboards and other views without further notice.

 
 

Table of Contents