💡Example: Let's assume there are 10 Audio/Video, 2 Emails and 1 Instant Messaging (IM) tasks in the queue.
Let's focus on the IM Task, which appeared most recently in the queue.
⮑ When querying the queue position of the IM task, the value returned will be 13.
⮑ When another task enters the queue - regardless of modality - it gets position 14.

With 2 users available to handle all modalities, this setup would work as planned, as every task gets treated equally. However there can be situations when your users can handle only certain modalities within a service that supports several or all modalities. This can create bottlenecks in the task distribution that Nimbus cannot anticipate.

🔎Analysis: For Nimbus, task modality does therefore not matter when retrieving the queue position. The IM Task on position 13 will move up the queue eventually over time, but may get stuck at position 1, as no user is available to handle the chat. Other modality tasks may get handled earlier – e.g. due to users being available that can handle that modality. Another case could be that other tasks (even in the same modality) have a higher Priority set.

🤔Why is it solved like that? The quick answer: simplicity and consistency. The Nimbus UI will always list all pending tasks in the queue equally, matching what “queue” related workflow activities will return. This is assuming the most-popular use case where all your users can handle all modalities.

However, in a use case scenario where users are specialized on handling certain modalities, estimating queue length would depend on additional factors such as…

• … the current availability of “modality-capable” users within your service.
• … being able to gauge the “average” task handling time.

→ Nimbus therefore delivers the actual, “more pessimistic” task position instead of making assumptions on potentially available users. This is done to not mislead customers with a positive queue position that may still result in long waiting times.

🤔How can I improve my queue estimate precision? 

→ Most of our customers prefer using separate services per modality as “task silos”, which also leads to clearer task distribution to a dedicated user pool, separate Nimbus Reporting of sessions, dedicated access with Portal Roles and easier to manage KPI adjustments and other specific Service Settings.

→ If you do not want to split up your services, another approach could be to work with Task Priority by specifically targeting certain modality tasks with a higher or lower priority. This can be achieved with the Nimbus Power Automate Connector.

→ You can also use the Nimbus Power BI Template and OData Feed to draw data and make adjustments to your workforce and service configuration.