| Distribution Type1 | Description | When to pick? |
|---|---|---|
Broadcast |
Rings users simultaneously, selected in a batch size of 10 longest-idle users. The first user to pick up the call via Microsoft Teams will handle the task. 💡Does not apply RONA status as it would otherwise flag the entire user batch size. |
Achieves a higher visibility, but the ringing call sets 10 selected agents as "Not Available", not allowing further calls to be distributed to them in the meantime. 👎Makes little sense in high-speed scenarios when the agents are dedicated only to the client to accept calls within a few seconds. Situationally for very large teams where high-volume call handling is more important than equal work distribution. |
Direct |
Will distribute tasks directly to team members, prioritizing the longest idle (active) team member. RONA time is adjustable. No further actions are necessary aside from accepting the call via Microsoft Teams. |
The call with the selected team member is first established via a Teams peer-to-peer call, before it gets escalated to the regular Nimbus conference session. Useful if you have "Busy on Busy" features enabled for your users. 👎Otherwise slower than "Direct Conference" and generally not recommended. |
|
🌟Direct Conference2  |
Same distribution as "Direct", but selected team members are directly invited to the Nimbus conference session, allowing them to join much faster and be able to talk to the original caller sooner. | 🌟 Our general recommendation for most services. Ensures faster handling of calls without blocking too many users at once for the same ringing call. âś… While configuring Workflows > “Queue” activities for your Contact Center service, use Direct Conference when you want Nimbus to push tasks automatically, and Pickup3 when agents should self-select tasks from the queue. Â
|
Pickup3 with Adjustable RONA |
Will show "Pickup" controls in the tasks list of the called team. A call session will be directly established without further intervention, and no further call reporting is possible after this point. A call session that is not accepted (after "Pickup" is clicked) within the given RONA time can be reinserted into the task queue or handled otherwise. | In small teams (e.g. volunteers) where it's acceptable to lose a call and reporting data isn't as important. Adds adjustable RONA time to flag users. |
Pickup2, 3 Conference1Â |
Same as "Pickup with Adjustable RONA", but will directly invite the agent to the Nimbus conference session, allowing them to join much faster and be able to talk to the original caller sooner. |
Best performance of all "Pickup" types. Unanswered calls can be re-inserted into the queue and no reporting data1 is lost. Suitable for scenarios in which the agents can keep an eye on the Nimbus app or to leave calls sitting in queue to retrieve and handle later. |
🔎Footnotes
1 Workflow differences: Depending on the modality used, certain “Distribution Type” settings may not be supported in your Workflow > Queue Activities.
2 Conference reporting: If a Nimbus task gets aborted (e.g. Hangup by User, Queue left, Max Wait Timeout Reached) Conference invitations get a “Cancelled” result in the Nimbus Reporting Model.
3Â Pickup UI behavior: The Pickup button is available for both MS Teams-based and Skill-based routing services, however with behavioral differences.
Learn more…
The main difference is the User Assignment Type behind each service, which steers how Nimbus selects the available users that are currently able (and allowed) to take a task via active “Pickup” button:
- For MS Teams-based services, every user is part of the same team, and thus equally allowed and capable to “Pickup” the task if his User State allows for it (e.g. not blocked by other tasks). This involves “Pickup” within Adaptive Cards, as a dedicated MS Teams channel is available to the same service users.
- For Skill-based services, Nimbus needs to check which users are not just capable, but also “allowed" to “Pickup” the task. This is achieved by using Distribution Policies to check for user-matching Skills and Responsibilities at the current distribution level. Additional layers, just as a Preferred/Last User “Initial Preference Phase” my also affect which user may pick up the task. As these users are manually added to services – and thus do not share a common MS Teams channel – Adaptive Cards are unsupported in this scenario.
Â