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.
- Exception: After-Call Work will still start automatically when an active (non-parked) Audio/Video session ends. This applies to all Audio/Video task types and directions, including consultation calls to services. Parked sessions and other modalities are excluded.
☝Also be aware:
- Changing this setting alters the user’s task‑handling workflow and should be communicated to users and supervisors in advance.
- 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.
- Both general and modality-specific task limits can be set in the General User Settings. You may use these limits to account for user experience in handling multiple tasks of certain modality.
Key Concepts and Features
🔑Key learnings before enabling Task Parallelization
🔎 All concepts are explained in further detail below.
- Parallel task handling is only possible for explicitly “Parked” tasks. – “On Hold” tasks are not parallelized, as Nimbus continues tracking KPIs during this state and the user stays in the task. → More on this in the comparison below.
- Initial Limitation: Up to four tasks can be handled in parallel. → Also refer to the “Known Limitations” chapter below.
- After-Call Work (ACW) will not apply for users with Task Parallelization enabled, except for non-parked (ongoing) A/V tasks. In such cases ACW-related Modality Service Settings will not apply for the user.
- Persistent RONA will still flag an (unresponsive) user, regardless if there is already a parked session or not. Task Parallelization and configurable task limits do not change how RONA is triggered. Resuming a parked task will remove RONA status.
- Note that Task Parallelization does not change Task Queue and Distribution concepts. Nimbus does not “prefer” users with higher parallel task capacity, but adheres to the given concepts such as “longest-idle" user or specific Skills and Responsibilities for distribution.
Comparison: “Park” and “Hold”
INC Park and Hold Comparison
To understand Parallel Task handling in Nimbus requires a clear distinction between a “Parked” and “On-Hold” task1 status:
-
Parked Tasks remove the user from the call and exclude
park timefromconnected time. -
On-Hold Tasks keep the user on the call and include
hold timeinconnected time. - Both states block the user from receiving new Nimbus tasks unless Task Parallelization is enabled in the General User Settings for the respective modality.
- Both overall task limits and modality-specific limits can be configured per user. When either limit is reached, no more parallel tasks are distributed, even if all other tasks are “parked”.
🔎As Nimbus creates Reporting Sessions for each task, Parking and Holding actions affect the reported KPIs and User States differently. The following table outlines some key aspect differences, using an Audio/Video call as example:
| Aspect | Parking | Holding |
|---|---|---|
| User Intention | To pause a Nimbus task while being free for other – non-Nimbus related tasks or MS Teams calls. | To get a timely response and temporary mute the customer, e.g. to clarify something during a call. |
| 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. an IM chat, email, call, external task). A lot of the MS Teams specific UI interactions are skipped in this case and the parked task can resume immediately.
(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 ▼ |
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 ACW2 | Blocking | Blocking | Blocking | Blocking | n/a | n/a | n/a |
1 Not a visible state on the UI. While Nimbus is unparking a session, a “blocking” invitation in MS Teams prevents the user from receiving further tasks.
2 Also includes extended ACW. In general, the ACW timer will not start when a parked session is being terminated.
💡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 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.
💡For other presence states, Distribution Service Settings apply.
Task distribution among multiple 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. A maximum task limit of 2 is set for simplicity:
| 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 (idle time starts) | 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 on (parallel) Task distribution
- Longest-idle1 first remains: 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.
- Tasks limit: When User A accepts and parks a 2nd task, they still remain “not available” due to the maximum task limit.
- General rule: When a user actively changes their User State to DND, they are immediately “not available”. This takes precedence over any maximum task limit set.
1 ☝Keep in mind: Instead of the longest-idle, Services can different Distribution Policies to target the Last, Preferred or Most Qualified users first. In general, any “not selectable” User State (either caused by the user or Nimbus) can prevent further task distribution. A higher task-limit on any user does not steer nor impact Nimbus task distribution preferences between users.
Reporting
While definitely affecting KPIs Task Parallelization has no specific or systemic reflection on Nimbus Reporting. Nimbus will always create and track separate Service / User sessions for each task, of course with an overlap of session timestamps to be expected.
💡Keep in mind: Task Parallelization for any user will result in an overall longer average (Service/User) Session length in the Reporting Data. The removal of After-Call Work (ACW) for users handling multiple tasks in parallel will also be notable in reporting.
✅ Admin best-practice: 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
We are actively working on further improvements for the following items:
- With Task Parallelization enabled, four (4) simultaneous tasks are allowed in parallel at any time. Nimbus development plans to actively increase this limit, ensuring that the UI is capable to handle more tasks in parallel.
- Audio/Video modality only: While being at the maximum limit of parked tasks a user is still shown as “Available” in MS Teams, leading to the assumption that they can receive further calls. Nimbus will not distribute any tasks, but any incoming (blind / safe) transfers to those users will not succeed.
🔎DESIGN NOTES
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. Note that this does not apply for active Audio/Video tasks - if an active (non-parked) call is terminated, the ACW will start.
- 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 actively handled.
-
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.
General technical limitations (wont fix):
- While being Busy in a call / DND / Offline in MS Teams, users can still unpark existing sessions. However, MS Teams may then not send an invite back into the (call) session. → Nimbus won't introduce any validation here, leaving it up to users to decide when to unpark.
- While handling Instant Messages and External Tasks, MS Teams presence is not updated, but Nimbus tasks are active.
💡Rationale:- Nimbus has no active control over MS Teams presence (read only) and cannot prevent a user from working on IM and EXT, even while the tasks are parked in the UI.
- Also, when a user switches between two different chats or external tasks outside the My Sessions or Attendant Console UI, Nimbus will not automatically learn about this task update.
☝General recommendation: Instruct users to use the Nimbus Portal UI to ensure tasks are parked / put on hold / resumed properly, e.g. to reflect correct reporting on connected time for each parallel task.