Every incoming call in Nimbus is considered a task to be distributed via queue. Tasks are handled according to the service they are handled by. Thus, the UI in Nimbus can look differently depending on how the according Nimbus service is configured.
Queue distribution type
The Distribution Type settings in Workflows → Queue Activities determine how incoming tasks are distributed.
Distribution Types
💡Note: Certain “Distribution Type” settings may not be supported in “Queue” activities of your workflows, depending on the modality used.
| 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(1) 🌟
|
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. |
|
Pickup(2) (⌛ Feature will be discontinued, see Note) |
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. ⌛This option will be discontinued in near future. Pickup by itself does not allow call transfers as Nimbus has no further control over the session. |
| Pickup(2) 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. | 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. |
| Pickup(2) Conference(1) | 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(1) is lost. Suitable for scenarios in which the agents can keep an eye on the Nimbus app or to "park" calls in a queue so that other calls can be answered first and retrieve them later from the queue. |
(1) Conference invitations get a “cancelled” result in the Nimbus Reporting Model if a task was aborted (e.g. Hangup by User, Queue left, Max Wait Timeout Reached).
(2) ☝ Contact Center Services generally do not support the "Pickup" option. As calls get automatically distributed, a "Pickup" interaction is undesirable in Contact Center scenarios. 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 queue without a pickup button. → While configuring Workflows > “Queue” activities for your Contact Center service, use "Direct Conference" instead.
RELATED TOPICS
- The Distribution Type settings are configured via Workflows.
- Team owners can switch between workflows at any time using the Service Settings.
- Many Workflow Activities handle task distribution. Refer to "queue" and "task" keywords in the activity.
Call distribution according to opening hours
Depending on the time of day or team size you might want to switch your workflows to adapt to the situation. An effective way to manage your call distribution is to route to various queues via the "Opening Hours" activity in your Workflow.
Here are some examples:
- Allow your team to take tasks via Pickup controls in the Nimbus UI, either with or without adjustable RONA times to flag unresponsive users.
- Improve customer experience by setting a Task Priority and Direct Conference queue which establishes calls in the quickest way possible.
- On holidays with low expected call volume, you can Broadcast calls to all your service users simultaenously.
- During closed hours, you can transfer the overflow to backup services –each with their own optional Opening Hours– or follow up with voice message recordings in Adaptive Cards so that nothing gets lost in queue. This eases team members into the call center concept without having to focus on extra apps in MS Teams.
Applying a workflow configuration
Note that your ready-to-use Workflows and Opening Hours need to be assigned via Service Settings to take effect. Here is an example how to configure it:
- Define Opening Hours in a separate new configuration item.
-
In your Workflows, add a Check Opening Hours activity.
☝ Make sure to handle all exits to get no lost calls when your hours calendar changes! -
Configure the Distribution Type in your Queue Steps as needed by your working hours.
🔍 See the example screenshot above. - Finally, go to your Modality Service Settings and apply the workflow to your service.
Advanced task handling with distribution profiles
Contact Center As your service landscape changes, distribution requirements may do so as well. Advanced Contact Center features allow you to influence ongoing tasks.
When switching to a Contact Center Service Type, you can enable more granular queue handling features by using a Distribution Order algorithm. The configuration steps and concepts behind them are explained in the following example:
Distribution order accordions
Skills/Responsibilities
✅ The first step before using skill and responsibility based-routing should always be a look at your organizational structure. Ask the question: what kind of expertise is important when handling incoming calls? How should our users (agents) be categorized accordingly? Then go ahead and do the following:
- Define skill categories ,such as "Language Skills" or "Product Expertise". You may also define soft skills or adjectives without levels such as "First-Responder".
- Optionally define skill levels according to your chosen category. This allows for escalation levels so that you can require certain skills or widen the user pool by gradually lowering skill requirements of long-waiting calls.
- Optionally define responsibilities to apply to any category of skills. Responsibility levels can be used to distinguish skill importance, e.g. based on on time of day, workload, out-of-office status, or for high-demand situations where users with certain skills are more responsible than others.
- Optionally define responsibility profiles for your users to select from. A profile automatically groups skills and responsibility levels together and lets you define corresponding levels for each profile and user.
➕ In our example, we defined two skill categories with levels. Responsibility is enabled for the "Expertise" skill which will be explained further below.
🔍 Information on this configuration can be found in Skills and Responsibilities.
💡 We recommend you to coordinate this with your (future) service team owners and their respective Organization Units in order to avoid unnecessary duplicates of skills, categories, and profiles within your Nimbus tenant.
User Definition
✅ After setting all your skills and responsibilities, you want to define your individual Contact Center users (agents).
- Optionally assign the additional responsibility profiles for each user where needed. By default, each user has two system profiles: Duty (which considers all skills) and Off Duty. Users will be able to select further responsibility profiles you defined from the Nimbus frontend (based on their respective Organization Units).
- Define skill and responsibility levels for each user. With further profiles, you can define these levels individually for each user.
➕ In our example, we defined two users with varying levels of skill and expertise. A highly skilled user (e.g. a programming expert) may be busy with other tasks during the day, but shall answer questions while being "On Call" at weekends.
💡 Usually you do not change skills on users very often, as they remain consistent. Skill-based responsibility, however, may be different for each user depending on their selected profile. Make sure that the naming and meaning of your profiles is clear and understandable for your users (examples could be: “Night Shift”, "Weekend Duty", "High Load").
Service Configuration
✅ After defining your agents, it's time to apply policies to your services. These policies define how agents are pooled and selected during an incoming call.
Rules for the selection order algorithm
In order to be selected, defined Nimbus Contact Center users must fullfill all the required criteria. These are as follows:
- Users must have all required skills.
- (Of the required skills) one skill level must match for the user to be selectable.
- (When responsibility is enabled for a skill), one of the required responsibility levels must match as well.
- The user must be available (e.g. not in RONA state, or Busy in another call)
-
If multiple available users match the requirements above, the order algorithm defines the priority as follows:
- Best Qualified: Prefers highest skill qualification (even if higher respond time)
- Longest Idle: Prefers longest idle team over both responsibility and skill level.
-
Define a distribution policy with a clear name (e.g. Regular day service policy) and an order algorithm (see info above).
- Define the distribution levels with one or more profiles of escalation.
- Each profile determines the required skills AND their required responsibility range.
- Assign the policy within your Service Settings so that it takes effect immediately on the next call.
➕ In our example, we defined a policy with two levels, both excluding the "Junior" expertise level, but lowering the responsibility and language requirements on the 2nd level at the 30 second mark.
Call Evaluation
✅ Once assigned to your Contact Center service, the call will be distributed according to the order algorithm.
- All skill-defined users are pooled. Users must be available (not in other calls, not busy in meetings, etc.)
- The rules of selection are applied (MUST have all skills, MUST be in any allowed responsibility level)
- On equal match, the users are selected based on the order algorithm setting (Longest Idle, Best Qualified)
➕ In our example, we explain the algorithm via the two levels defined in our distribution profile earlier:
| Level | Selection Criteria |
|---|---|
| 1 |
|
| 2 |
|
Learnings
- Contact Center services can act outside of any given MS Teams framework. You can manually manage your agents to each service and combine this approach with regular MS-Teams.
- Skills and Responsibilities define your users in a more granular fashion. Users can dynamically switch their Duty States (and underlying skills) to react to needs from various services.
- By applying Distribution Policies on your Contact Center services, you determine how these skillsets are applied in level-based call escalation.