Distribution Service Settings

Contains settings related to call distribution.

ūüĒć Note that - once applied - these settings affect¬†all¬†current or future users in this service.

Users

Allows to configure settings that affect Nimbus user status handling and call distribution.

User Assignment Type

Shows how (new) users are assigned to this service. → See User assignment types.

ūüí° The default for Nimbus is¬†"Microsoft Teams Based". Users are directly synched to the Teams channel related to the current service.

ūü§Ē Why is this setting locked?¬†The assignment type is determined during¬†Service Provisioning.

Distribution Policy

Contact Center Service Type feature.

ūü§Ē Why is this setting locked?¬†Distribution Policies¬†are managed and changed via the¬†Service Administration, depending on your service type and licsense.

New users immediately active

The " Active"  setting determines if Microsoft Team "Members" are considered as users for Nimbus call distribution. Enabling this feature will automatically add new team members to your Nimbus service team.

An "Active" state has the following effects:

  • Only "Active" users may receive Nimbus distributed calls. Users may still be part of a team but remain inactive for the team's designated Nimbus Service.
  • Team Members that are set "Active" at least once in a month will count into statistics of the Nimbus¬†Administration
  • Active Members are immediately part of the Nimbus task queue distribution according to the set¬†Workflowsand may handle calls for the service team.
  • They also appear as "Active" in the¬†Dashboard¬†for all other team members.

GOOD TO KNOW

  • Both Team Owners and Team Members themselves can¬†toggle¬†their "Active" state at any time within either the¬†My Services¬†tab of the personal¬†Nimbus app or the Team¬†Dashboard¬†>"My State"¬†widget.
  • Toggling this state acts as a quick "gate" to opt-in and -out of multiple Nimbus Services in case you want to balance your personal customer interaction as user and Nimbus capacity per service team.
  • In addition to the "Active" state the "User Presence" (within Teams) also needs to be in a state that allows for call distribution ‚Üí se
 

Conversations Distribution

Determines call distribution based on user presence state as set in their MS Teams client.

✅ Precondition: Regardless of Microsoft Teams IM presence, a user always needs to be "Active" in the service to receive Nimbus distributed calls → See above.

SETTING EFFECTS

On the My Services dashboard a user will be shown in state: "(Not) Available" according to the configuration above:


Notes:

ūüí° When a user is part of multiple teams and already taking a call for one service line, the user is also marked as "¬†Not Available¬†" in all other Nimbus teams.

ūüí° IM presence states considered by Nimbus are:

  • Available
  • Busy¬†
  • Do Not Disturb
  • Away
  • Offline

Whenever you make adjustments to your Distribution we also recommend checking the following:

Workflows - as activities inside - such as "Availability-based Routing" or "Queue" will affect call distribution, reaching more or fewer (active) users respectively. MS Teams presence is also re-evaluated depending on the "Distribution Type" setting in the "Queue" workflow activity:

"Queue / " workflow activity Distribution Type setting Availability Scenario Effective Task distribution

Broadcast When a user turns back to "Available" and a broadcast task is in the queue. During the next distribution iteration (timeout criteria or decline by other users) the user is included for distribution.
Direct When a user turns back to "Available " and a direct distribution task is in the queue. During the next distribution iteration (e.g. RONA criteria or decline by previously selected) this user included for distribution.
Pickup When user is "Not Available" Pickup controls are disabled (e.g. in Dashboard)

During the next distribution iteration (e.g. RONA timeout) this user included for distribution.

ūüí° A message will be shown on mouse-over that the IM presence is preventing task handling.

None, see node exit ‚Ėļ No One Available Currently all users are inactive (or active but set "offline" in MS Teams)
None, see node exit ‚Ėļ In Time Available Currently active users are not immediately available e.g. "DND/Away/Busy" or when occupied by another call.
None, see node exit ‚Ėļ Direct Available Currently at least 1 user is available = MS Teams presence set "available" and also set to "active" in Nimbus).

Reporting Settings  (Settings > General > Reporting ) - as user related distribution and availability changes can directly affect your reporting SLA.

 

Task Priority

Contact Center Service Type feature. The Task Priority determines how incoming calls from this service are handled in sequential order.

Configurable Property Description Behavior What it looks like
Task Priority
  • Strict*
  • Highest
  • Very High
  • High
  • Normal (Default for Services)
  • Low
  • Very Low
  • Lowest
  • Nothing Else*

*¬†see ūü§Ē

When a new task enters the to the queue, it gets a priority according to the service setting:

  • Tasks are distributed according to your currently applied¬†Distribution Policy¬†(e.g. "Longest Idle" or "Most qualified"¬†users first).
  • The order of Tasks is¬†handled by priority, meaning:¬†
    • A new task of higher priority over existing tasks will take precedence and be handled as soon as possible.
    • A new task of equal priority will be sorted in below already existing tasks of the same priority, as it entered the queue at a later point of time.
    • A new task of lower priority will be sorted "in-between" higher priority task rounds, using a weighted round robin method. ‚Üí See chapter below.

ūü§Ē When should I select "Strict" or "Nothing Else" as my priority?

  • "Strict Tasks" will always be put on top of your queue.¬†Use this for Emergency services and important VIP hotlines that always should get precedence over anything else in your queue.
  • "Nothing Else" Tasks will only get distributed when your service queue is empty.

‚ėĚ Note that selecting either "Strict" and "Nothing Else" will ignore round-robin distribution. Tasks get lost due to potentially long queue times.

In views with a task list (e.g. My Overview or Personal Dashboards with "Task" widgets) a "Priority" column indicates how high this task is ranked in the queue. With this setting, tasks may now "displace" existing tasks to a new rank.

Weighted Round Robin Task Distribution

Due to the rules above, task may "starve" for very long in a queue. An example would be a "Lowest" priority task getting outranked by higher priority tasks. To avoid this, a weighted round robin method is in place to mix in lower-priority tasks, equally distributed amonst available users:

Learn more...

Q: Calls in Queue | H: Handled | R: Remaining

Priority Q H R H R H R H R H R H R H R H R H R H R H R H R H R H R H R
1 (high) 12 2 10     2 8         2 6     2 4         2 2     2 0        
2 (med) 6     1 5     1 4         1 3     1 2         1 1     1 0    
3 (low) 3                 1 2                 1 1                 1 0
Round Counter Round 1 Round 2 Round 3 Round 4 Round 5 Round 6
Time (t) t1
tn

WEIGHTED ROUND ROBIN

The Round Robin procedure distributes the calls in such a way that the ratio between the individual priority levels is always 2:1. Each time another "Round" is started, that round counter is applied to the "weight" of the remaining tasks.

The example above assumes a configuration with 3 priority levels. There are 21 calls in the queue, with the following priority:

  • 12 calls with priority 1
  • ¬†¬†6 calls with priority 2
  • ¬†¬†3 calls with priority 3

Following the 2:1 rule, the calls are queue over time t as follows:

  1. Round 1: High Med tasks added in 2:1 ratio.  No "Low" priority tasks in Round 1 as "Medium" task count outweighs the low task count.
  2. Round 2: High Med Low tasks added in 2:1 ratio. The "Low" priority  tasks get a round-multiplier added to their weight, now outweighing "Medium" tasks and thus are added in a 2:1 ratio.
  3. Round 3: Same as Round 1.

ūüĒć Sources:¬†Weighted Round Robin (Wikipedia Article).¬†Please note that this example only works as long as no new calls are being processed. Calls with strict or no priority are not considered in this rule.

 
 

Task Priority in "Queue" workflow activites

In a multi-service environment, the "Priority" setting effects your "Distribution Type" setting within a Queue Workflow Activity:

Scenario
Setup
Outcome
Learnings

2 Services A&B using a "Broadcast" Queue Activity setting in their Workflows.

 

  • Service A¬†: Broadcast, Calling Timeout - 30, priority "Low"
  • Service B: Broadcast, Calling Timeout - 30,¬†priority "High"
  • Both services pool the same 10 users, Active and Available
  1. A first (low) call to Service A will block all 10 users with the call invitation.
  2. A second (high) call to Service B enteres the queue. All users are still blocked for the 30s timeout.
  3. The first (low) call is declined by 1 user, which then immediately gets the second (high) call distributed. 
  4. All 9 users are still blocked by the (low) call engagement until it is handled.
  5. Only the 1 user finishing the (high) engagement may take the next (high) priority call.
ūüí° The¬†"Broadcast"¬†Queue setting is fixed to a 10-user batch. In a Priority scenario the first call entering ‚Äď even if lower priority ‚Äď may block higher priority tasks.

After Call Work (ACW)

Contact Center Service Type feature. ACW time (in seconds) is added to the end of a call session until the user is considered available again to take the next task.

Option Description ACW in Portal UI View
Enable ACW Time

When enabled, shows ACW in both My Sessions and Assistant in the Nimbus portal.

ūüí° Once enabled the default ACW time (02:30 mm:ss) is granted. Can optionally be extended or stopped with the additional options below.

Allow Early End

Enables all Nimbus users of that service to stop the ACW counter at any time.

‚Üí Stopping ACW will free up the user to become "Available" within Nimbus and receive the next task / call.

Allow Time Extension

Enables all Nimbus users of that service to extend ACW by the amount specified in the " Maximum ACW Extension Time ".

ūüí° This time is granted as flat "new" value to the user,¬†not¬†added to any remaining ACW time.

NOTES ON AFTER CALL WORK (ACW)

  • When a user goes offline in Microsoft Teams it will terminate the remaining ACW time for that user.
  • Changing the ACW Toggle / Time in settings during productive hours will have an impact on new (incoming) Tasks only.
  • Users are blocked from all other Nimbus service calls during ACW.
  • ACW is also tracked in¬†Power BI¬†for reporting purposes. Reports ACW time in seconds or "Null" if disabled.¬†Total ACW time in a single service session is summed up from all involved user sessions.
 

RONA

Contact Center Service Type feature. RONA (Redirect On No Answer) is a "not selectable / available" User State for all type of services. A Nimbus user in MS Teams is given RONA status if they ignore a service call or do not answer it within a set period of time seconds.

ūüí° The RONA status ensures that the call doesn't get lost and is instead redirected back to the queue (or handled otherwise via the¬†Workflow). RONA is also tracked in the¬†Nimbus Reporting Model, and can be evaluated via¬†Power BI¬†OData interface.

ūüĒć This status does¬†not¬†apply when the¬†Distribution Type¬†in your¬†Queue Workflow Activity¬†is set to¬†"Broadcast", as it would otherwise flag entire batches of users with RONA status when a call doesn't reach them.

You can configure RONA as follows

Element Description
Persistent RONA 
(toggle, default: disabled)

Adds a persistent RONA state to any Contact Center licensed users of that service when they fullfill either of the following criteria:

  • Decline a call from that service
  • Ignore a call invitation from that service

ūüĒć While in RONA status the user is considered as "Not selectable / Available" by Nimbus and will not receive further call invitations. ‚Üí See note below.

RONA Reset Time

RONA Reset Time (must to be specified)

  • ¬†
    • hh:mm:ss format
    • Default 10min
    • Min 10 sec to Max 320 min (8h)

RONA RESET CONDITIONS

An already active RONA state can be reset as follows:

  • Automatically, after the specified¬†"RONA Reset Time"
  • Manually by the user via¬†Assistant¬†(both portal and standalone). An count-up timer shown next to a manual reset button.
  • When the user goes Offline in MS¬†Teams.
  • When the user switches to an¬†"Off Duty"¬†Profile.

ūüí° Changing the persistent RONA flag to false or changing the reset time will not have an impact on already set RONA states.

 

Table of Contents