Distribution Types

Distribution Type 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 Conference šŸŒŸ

Ā 

Same distribution as "Direct", butĀ in this mode, the selected team member is 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.

šŸ” Conference invitations get cancelled if a task was aborted (e.g.Ā Hangup by User, Queue left, Max Wait Timeout ReachedĀ ). ā†’ SeeĀ Nimbus Reporting Model.

Pickup ā˜ Will show extra "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. If the Nimbus user is unavailable or the session is otherwise ended the call will be lost.

In small teams (e.g. volunteers) where it's acceptable to lose a callĀ andĀ reportingĀ data isn't as important.

ā˜ Pickup by itself does not allow call transfers as Nimbus has no further control over the session.ā†’ If you want to use Pickup with transfer, use "Pickup with Adjustable RONA" or "Pickup Conference" instead.

ā˜ KNOWN ISSUE: In a Contact CenterĀ Service TypeĀ scenario the "Pickup" option is an unsupportedĀ Nimbus Feature. Any "Pickup" interaction is undesirable in Contact Center scenarios, asĀ Distribution PoliciesĀ automatically handle call distribution with minimal UI interaction. When Contact Center service workflows still have theĀ "Pickup"Ā distribution type configured, calls are shown in the queue, but without the pickup button. ā†’ While configuring your Contact Center service, use theĀ "Direct Conference"Ā option in your workflows instead.

Pickup with Adjustable RONA Same as Pickup, but with adjustable RONA.Ā A call session that is not accepted (after "Pickup" is clicked) within the given RONA time can be re-inserted into the task queue or handled otherwise.
Pickup Conference 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Ā data is lost. Suitable for scenarios in which the agents can keep an eye on the app. Or to "park" calls in a queue so that other calls can be answered first and then the parked call can be retrieved from the waiting queue.

šŸ” Conference invitations get cancelled if a task was aborted (e.g.Ā Hangup by User, Queue left, Max Wait Timeout ReachedĀ ). ā†’ SeeĀ Nimbus Reporting Model.

Table of Contents