INC Gradual Feature rollout
Features described in the following are gradually rolled out on Nimbus clusters. They may not be available on your tenant yet.
INC Public Preview Beta Feature
This feature is in PUBLIC PREVIEW and may not yet be available to all customers. Functionality, scope and design may change considerably.
Task Parallelization enables users to handle multiple tasks simultaneously within the Nimbus platform. This includes e.g. managing Audio/Video (AV) calls and External Tasks without blocking the user from receiving a new Audio/Video task. Task Parallelization introduces a more flexible and scalable approach to task handling, especially for service agents working with multiple modalities.
✅Preconditions:
- Task Parallelization is enabled on user level via General User Settings (per default disabled).
☝Note that enabling this feature will disable After-Call Work (ACW) for the User. We therefore strongly recommend to …- … change this setting outside of working hours, as Users might be confused about the sudden change in their workflow.
- … inform Supervisors concerned with Reporting Data, as ACW time is now absent from Nimbus KPI Calculations and reflected in the User's Nimbus Reporting Session data.
Key Concepts and Features
🔑Key learnings before enabling Task Parallelization
🔎 All concepts are explained in further detail below.
- Only Parked tasks can be handled in parallel – “On Hold” tasks cannot, as Nimbus continues tracking KPIs during this state and the user stays in the task.
- Initial Limitation: Up to two simultaneous tasks can be handled in parallel. → Also refer to the “Known Limitations” chapter below. Allowed modality combinations are:
Audio/Video + Audio/Video Task.
OR
Any Modality Task + Audio/Video Task. - For users with enabled Task parallelization, After-Call Work (ACW) will not apply, regardless of Service Settings.
- Persistent RONA will still flag an (unresponsive) user, regardless if there is already a parked session or not. Resuming a parked task will remove RONA status.
Park vs. Hold Functionality
Before we explain what parallel task handling changes in Nimbus behavior, it is important to explain the “Parking” and “On-Hold” status differences for tasks:
- Parked Tasks: Removes the user from the call and excludes park time from connected time.
- On-Hold Tasks: Keeps the user on the call and includes hold time in connected time.
- Both states block the user from receiving new tasks unless Task Parallelization is enabled.
INC Park and Hold Comparison
As Nimbus creates and monitors Sessions each with their respective KPIs, Parking and Holding of tasks1 is treated differently. It is therefore important to outline the differences between those terms:
| Parking | Holding | |
|---|---|---|
| User Intention | To pause a Nimbus task while being free for other – non-Nimbus related tasks or MS Teams calls. | To temporary mute the customer and clarify something during this call, with the intent to get a timely response. |
| Nimbus User State |
|
|
| MS Teams User Session Status |
|
|
| Nimbus Reporting and Nimbus KPI Calculations |
|
|
| Transcription | The transcription session will be interrupted while Parking. The transcription bot will re-join when session is unparked. | The transcription session persists while Holding. |
| Supervision | An ongoing supervision session will be interrupted while Parking and will NOT restart on unpark. | The supervised session cannot be put on hold. |
| Customer Side | No differences for the customer: Will hear waiting music until the call is resumed. |
|
1 It's worth noting that “task” in this context can be understood synonymously with “call”. A task can technically mean any modality & related interaction between Customer and Service (e.g. a chat, email, call, etc.).
(Non-)Blocking Tasks
Parked tasks are treated as non-blocking, allowing users to accept new Audio/Video task. This is especially useful for handling emergencies or supervisor-assigned tasks without disrupting reporting accuracy.
The following table shows which states apply for tasks to be considered non-blocking:
INC Task blocking states
| Modality ► | |||||||
|---|---|---|---|---|---|---|---|
| Direction ► State Category ▼ |
Inbound |
Outbound |
Outbound |
Outbound with Workflow |
None |
Inbound |
Inbound |
| Incoming | Blocking | Blocking | Blocking | Blocking | Blocking | Blocking | Blocking |
| Dialing Out | N/A | Blocking | Blocking | N/A | N/A | N/A | N/A |
| Connected | Blocking | Blocking | Blocking | Blocking | Blocking | Blocking | Blocking |
| Transferring | Blocking | N/A | N/A | N/A | N/A | N/A | N/A |
| On Hold | Blocking | Blocking | Blocking | Blocking | N/A | N/A | N/A |
| Parked | Non-blocking | Non-blocking | Non-blocking | Non-blocking | Non-blocking | Non-blocking | Non-blocking |
| Unparking1 | Blocking | Blocking | Blocking | Blocking | N/A | N/A | N/A |
| In (Extended) ACW | N/A | N/A | N/A | N/A | N/A | N/A | N/A |
1 Not visible as a dedicated state on the UI. While Nimbus is unparking a session, a “blocking” invitation is ringing in MS Teams, preventing the User from receiving further tasks.
💡As long there is another task in a blocking state, the “Unpark” button will be disabled in the UI.
RONA and other User State flags
Same as single tasks, parallel tasks will cause users to be passively flagged with a persistent RONA state, regardless if there is a parked session or not.
🔎These flags also are part of User States that prevent further tasks to be distributed in parallel.
INC User State Type Table
For Reporting purposes Nimbus tracks User States, which define the ability of a User accept and handle tasks. Below is a table of these tracked states:
Id |
Name |
|---|---|
| 1 | Offline: User offline in MS Teams and thus cannot be selected for Tasks. |
| 2 | Off Duty: User is either in a “Offduty” Duty States or “Inactive” in Nimbus UI. |
| 3 | Selectable: User logged-in MS Teams and available to take Nimbus tasks. → Also see Task Queue and Distribution. |
| 4 | Not Selectable: User is in a MS Teams presence state that blocks task distribution as per Distribution Service Settings. |
| 5 | Ringing: A task has been assigned to an User but not yet been accepted. Can be either incoming calls or when an User is accepting an Outbound Call. Also applies for non-telephony-related modalities like Email, External Task, Instant Messaging etc. |
| 6 | Connected: The User and Customer are in a session together. Also applies when the User is just handling an External Task. |
| 7 | After-Call Work: User is handling After-Call Work (ACW). |
| 9 | RONA: User flagged with RONA state by a non-accepted task. |
| 10 |
Dialing Out: User has accepted an Outbound Call and Nimbus is now ringing the target Customer.
|
| 11 | Task Limit Reached: User has reached max allowed number of tasks assigned. Even if the user state would allow for new tasks, the task limit will prevent further distribution to this User. |
💡Users can reset their RONA state by unparking a task.
Active Task prevention
If users want to actively prevent themselves from getting new tasks (in parallel), they need to either:
- Switch Duty States by selecting one of their available “Off Duty” Responsibility Profiles.
- Set their MS Teams Presence to “DND” (Do not Disturb) to prevent task assignment.
Task distribution to users with “parked” tasks
Nimbus uses a Task Queue and Distribution system that defaults into distributing tasks to the “Longest-Idle” user. A user with a a parked task is still considered “selectable” and thus available to take new tasks.
In this example we focus on just two Users A and B, using Audio Calls as modality:
| Time | Step | Expected Result | User A | User B | ||||
|---|---|---|---|---|---|---|---|---|
| State | Time in State | Number of Tasks | State | Time in State | Number of Tasks | |||
| 11:58 | Pre-requisite | User A is available and idle longer than User B | Available | 10 min | 0 | Available | 5 min | 0 |
| 11:59 | Task 1 enters the queue | User A gets the invitation (longest-idle1) | Not Available | 0 min | 1 | Available | 6 min | 0 |
| 12:00 | User A accepts the call | Time in state keeps counting up | Not Available | 1 min | 1 | Available | 7 min | 0 |
| 12:05 | Call 2 enters the queue | User B gets the invitation (is available) | Not Available | 6 min | 1 | Not Available | 0 min | 1 |
| 12:10 | User A parks the call | User A becomes available | Available | 0 min | 1 | Not Available | 5 min | 1 |
| 12:11 | User B terminates the call | User B becomes available | Available | 1 min | 1 | Available | 0 min | 0 |
| 12:15 | Call 3 enters the queue |
User A gets the invitation (longest-idle1) User A now has the maximum number of parallel tasks |
Not Available | 0 min | 2 | Available | 4 min | 0 |
| 12:20 | Call 4 enters the queue | User B gets the invitation (is available) | Not Available | 5 min | 2 | Not Available | 0 min | 1 |
💡Learnings
- Even if User B has 0 tasks, User A gets 2 tasks because they are the longest-idle, which is the default task distribution method by Nimbus.
- When User A accepts and parks a 2nd task, they still remain “not available” due to the task limit.
- General rule: When a user actively changes their User State to DND, they are immediately “not available”. This takes precedence over the task limit.
☝Keep in mind: Various advanced Contact Center features like changing the Distribution Policies to take Best Qualified users or setting the Task Priority (higher tasks taking precedence) can impact distribution. Users may also actively switch User States at any time, which may prevent further tasks from being distributed in parallel.
Reporting
Task Parallelization currently has no specific or systemic impacts on Nimbus Reporting. Nimbus will always create and track separate sessions for each task, just involving the same user for both user sessions.
💡Keep in mind:
Note that Parking is always required to get tasks handled in parallel. This will result in an overall longer average (Service/User) Session length in the Reporting Data.
✅ Whenever you enable Task Parallelization for a user, make sure to inform both the user and their supervisors that all future tasks and related KPI will be impacted by the parking/holding functional differences, and –of course– the expected “split” of the user's attention.
Known Limitations
INC Parking Limitations
KNOWN PARKING LIMITATIONS
- With Task Parallelization enabled, two simultaneous tasks are allowed in parallel at any time. Nimbus development is working to improve this limit with future updates.
- When a task is already parked, only an Audio/Video task can be taken in parallel.
DESIGN NOTES (not limitations)
Nimbus UI related:
- Call On Behalf and “Pickup” Task Queue and Distribution restrictions: While a user has reached the maximum number of parked sessions, the “Call on Behalf” and “Pickup” buttons on the UI will be disabled to adhere to the task limit.
- After-Call Work (ACW) is disabled for the user whenever Task Parallelization is enabled. This is to prevent conflicts and non-transparent timing constraints between parallel tasks.
- While being “Parked”, External Tasks cannot be removed via Nimbus Power Automate Connector nor Personal Dashboards. This is intentional design as the task is considered as currently being handled within Nimbus.
-
Nimbus Assistant will reflect the (parked) session in a simplified manner. When Task Parallelization is enabled, “Parked" sessions will be shown with a link to My Sessions where unparking and detail work is done. When Task Parallelization is disabled, a simplified “In a call / On Hold” status will be shown.
💡Rationale: Nimbus Assistant will remain an intentionally designed side-view app to notify about pending tasks. It is not purpose-build for full on task management, which is why My Sessions and Attendant Console are created to display handle tasks in parallel, with specific modality needs in mind.
MS Teams limitations (won't fix)
- While being Busy in a call / DND / Offline in MS Teams, users can still unpark existing sessions. Nimbus won't introduce any validation here, leaving it up to users to decide to unpark being in another task.
- While handling Instant Messages and External Tasks, states may not be correctly updated in the UI.
💡Rationale: Nimbus has no active control over MS Teams and cannot prevent a user from working on IM and EXT, even while the task is parked in the UI. When a user switches between two different chats in Teams without using the UI, Nimbus will not learn about this.
☝→ Users should use the Nimbus Portal UI to ensure tasks are parked / put on hold / resumed properly.