Handling calls in Nimbus leverages MS Teams call features in both Inbound Service Calls and Outbound Call direction. The main difference is that Nimbus is establishing a Conference between you as Team Member (also called Nimbus "Users") and the calling Customer. By inviting a Nimbus bot into Teams conferences Reporting metrics can be tracked in the background and additional participants can be managed in a Conference. To achieve this the Nimbus bot uses Nimbus App Permissions which are usually delegated by an Administrator.
Primary views
As a Service User (Team Member) you can focus on your personal call experience in Nimbus. Within the UI you can steer your Service availability, access reporting features and handle tasks, as explained further below on this page.
To keep your experience as simple as possible, Nimbus has a reduced set of "daily-driver" views, such as:
- My Overview to check your incoming tasks and daily metrics.
- My Sessions to handle your incoming calls and related After-Call Work (ACW).
- Attendant Console – in cases where you act as a front desk operator for call forwarding and consultation.
Call Monitoring and Distribution
As a Service owner you may be more interested in monitoring your team and adjusting your Service parameters as needed. Therefore, your daily call-handling focus should be on the following areas:
- Services Overview to quickly see the incoming load of incoming calls, compared to the availability of your Service Team(s).
- Live View to quickly check on individual Services and their daily KPI trends.
- Personal Dashboards to monitor and supervise specific Services or Users.
- Configuration and Service Settings to optimize the call distribution parameters within your Services.
Learn more about this…
As Service Owner you also want to steer the channels of communication, via specific Workflows that contain Workflow Activities for further customization. Applying these settings is done via the Modalities Service Settings
Nimbus also considers individual User presence status (as set in MS Teams) prior to distributing calls. This allows to even include Users that are - for example - set to "Away" or "Busy". This can be configured in the Distribution Service Settings.
🔍You can also visit and learn more on the User States and Task Queue and Distribution pages.
Handling Incoming calls
While handling calls in Nimbus:
INC Nimbus and MS Teams native functionality
☝ While handling Nimbus tasks, avoid MS Teams-native call controls
During an ongoing session, Nimbus cannot control any functionality engaged in parallel via MS-Teams
(e.g. putting Callers On-Hold, Transfers, adding participants to a Session, Muting of participants).
✅While handling Nimbus tasks:
- Instruct all Service Users NOT to mix the approach between Nimbus and MS Teams.
-
Prefer the available Nimbus UI options for any call handling and -transfer scenarios:
e.g. Attendant Console (Safe/Blind transfer, Consultation call), Hold and Retrieve, Parking.
🤔What are the effects of using MS-Teams in parallel?
When using MS-Teams functionality in parallel during a Nimbus Session, the User / Customer experience cannot be clearly guided or monitored by Nimbus anymore.
Possible effects are:
- Customers may not get clear feedback on certain actions (e.g. no On-Hold Music - just silence).
- Manually added participants in a call conference may not all hear each other as intended.
- The status in Nimbus UIs may not reflect the actual state of a Session anymore.
- Call metrics, KPI and Nimbus Reporting results may not be properly recorded.
Nimbus is designed to not obstruct your daily call handling operation with Microsoft Teams. Most interactions rely on basic MS Teams functionality wherever possible, while extending functionality with rich context and call-related work. Let's explore the typical steps in the following chapters:
Call Distribution
- The Customer locates and calls your Service (discoverable either via Teams search, configured PSTN Number or known SIP Address as configured in the General Service Settings.
-
Nimbus handles the call according to your Workflow configuration. The call is added to a task queue and distributed according to the parameters specified in the workflow "Queue" Activities1.
💡In this example we continue with a "Pickup" type distribution2.
🔍Learn more by reading Distribution Types. -
Nimbus now will show the call in its UI, within multiple views wherever relevant to the involved Service Users. For example…
- … in the “Tasks Widget” in the Dashboard,
- … the Live View or …
- … My Sessions for the Users that actually get the call distributed to them.
1 When enabled in your “Queue” activity, an Adaptive Card chat message will also be sent to your chat channel in MS Teams. All current "Active" Nimbus Users are mentioned individually to be notified of this incoming call.
2 Even while being set "Active" for the respective Nimbus team, Users might still see inactive "Pickup" controls. This is determined by Service Settings > "Conversations Distribution", which defines that Users in "Away" or "Busy" state are also considered for call distribution.
Call Establishment
💡 In this example below we continue with Adaptive Cards enabled as a better visual example.
- Let us assume that a User in your team chooses to accept the call by clicking "Pickup"
🔍 This can be done either in the Dashboard, or the "My Overview" area in the Nimbus Personal App.
💡 The Adaptive Card also offers "Pickup" controls.
- Once "Pickup" is clicked Nimbus will establish a session between Caller and Agent
⮑ The User will get a regular MS Teams incoming call (in the name of the Service).
⮑ Nimbus will remain in control of the session for gathering Reporting KPI metrics. - Eventually, Agent and Caller decide to end the call
⮑ The Nimbus bot remains until both parties have left the call, then concludes the session.
⮑ In the background, a Nimbus Reporting session is concluded.
Call Conclusion
At the end, the call information will be gathered and reported, for example as Statistics and within the Sessions List.
The will also be updated with the Live View, as the Status of the User becomes “Available” again after handling the task.
The Adaptive Cards in your team's chat channel will also update with information about who / when / and if the call was handled.
Duty States & Responsibility Profiles
💡The following content is taken from the Duty States page.
Duty States
Duty State is Nimbus’ tracked availability status for Contact Center users. Every such user is shown as one of three Duty States — Available, Not Available, or Off Duty — derived from two independent inputs:
- which Responsibility Profile the user currently has selected (itself classified as either “On Duty” or “Off Duty” by an Administrator), and the user’s current MS Teams presence.
- Users with no duty concept at all — Teams-based only, without a Contact Center license — show no Duty State; the field is simply blank rather than “Off Duty”.
User State tracking includes the Duty State and is part of the Reporting system within Nimbus.
| Duty State | Meaning |
|---|---|
| Available | An On Duty Responsibility Profile is selected, and the user is currently selectable for tasks. |
| Not Available | An On Duty Responsibility Profile is selected, but the user is currently blocked — busy with a task, at maximum capacity, or their MS Teams presence doesn’t allow distribution. |
| Off Duty | An Off Duty Responsibility Profile is selected. |
| (blank) | Not a state — shown for users with no duty concept (Teams-based only, no Contact Center license). Dashboards and reports show this as an empty value rather than “Off Duty”. |
Primary Use Cases
When using Assistant – either as App or within the UI – all Contact Center users can switch between their assigned Responsibility Profiles, which in turn can be On Duty or Off Duty. Using multiple profiles for either duty state can have use cases, such as:
- Requirements for certain Skills and Responsibilities - e.g. when more experts are needed “on duty” to compensate for unusually large
- High Workload - e.g. switching to a ”on duty" profile to take more calls from multiple services.
- Special situations - e.g. a “off duty” profile e.g. when working abroad, while being online, but unavailable for service calls.
- Controlled absence - e.g. an “On Duty” profile for on-call periods, allowing for emergency calls to get through whenever the user has that profile selected.
🔎 Related: The Responsibility Profiles On/Off Duty state are reflected in Nimbus Reporting.
PREREQUISITES
✅ Users of this feature must be part of a Contact Center service, also Contact Center licensed themselves.
Once enabled:
⮑ The Contact Center Assistant becomes visible in your main menu, adding a User Status color indicator → more on this below.
⮑ By default, Nimbus comes with two predefined “On duty” and “Off Duty” profiles. 💡 The duty profiles also affect the User State.
✅ OPTIONALLY, any Administrator can also create and assign further “On Duty” or “Off Duty” Responsibility Profiles to your user.
Learn more…
- Any Administrator can create Responsibility Profiles. Each Profile can have its individual name – as reflected in the Nimbus UI – be of type “On Duty” or not. Here is an example:
Defining the Profile Name and duty type -
When assigning the profile to a user, this is also indicated next the profile, but also:
- … on listings in the Administration.
- …in Assistant
- …on Non-Personal Dashboards (e.g. listing all users currently having an “On Duty” profil).
💡 Good to know: Custom profiles are treated the same way as the system's default On/Off Duty profiles, meaning that
- … they are tracked equally in live User States and historical Nimbus Reporting.
- … they can all be taken into consideration for skill-based routing within Distribution Policies.
Changing your Duty State with Responsibility Profiles
All users with Responsibility Profiles assigned can freely switch between them (and the underlying On/Off Duty state):
- Login to the Nimbus Frontend portal.
-
Open either:
- "Contact Center Assistant" in the Nimbus main menu.
- Your standalone Nimbus Assistant App.
-
Click the pulldown to change Responsibility Profiles and underlying duty status at any given time.
💡 Duty, availability and readiness: Regardless of Duty State, you can remain fully "Available" in MS Teams to handle calls from other services and non-Nimbus calls. → More on this on status dependencies below.
💡 Status persistence: Your duty status and responsibility profile persists even when restarting your MS Teams client or logging out and back into Nimbus. You keep the last selected status until you either switch to a different one – or until an Admin changes the setting on your user.
Duty and your User Status
Changing your Responsibility Profile and MS Teams Presence affects the user status indicator icon next to the Contact Center Assistant menu entry.
☝️ Note that this icon color does not mirror your MS Teams presence 1:1, but instead aims to convey various User States1. The resulting icon color can be interpreted as follows:
| Color | User State Factors |
|---|---|
| Gray |
|
| Green |
|
| Red |
|
| Orange |
|
1 🔎Status dependencies
Note that this color indicator is a simplification of the User States tracking system of Nimbus. The most important points to take home:
-
Your Responsibility Profile will not affect your MS Teams presence and vice-versa. As a result you can still remain "Available" in MS Teams – e.g. to take internal calls – but get a red indicator, effectively blocking Contact Center related service-tasks.
💡Note that the indicator may still remain green, as you are “Active” in one or several MS-Teams based services. -
Your Active on/off toggle e.g. in Services Overview also affects your readiness for new tasks non-skill-based services.
💡Note that this toggle is not present when you are only part of skill-based services. In that case you will steer participation exclusively via Responsibility Profiles. - Your MS Teams Presence affects the indicator. If no service considers your presence as selectable for new tasks, you will get a “Red” color status.
Troubleshooting
🤔 Is your status "Red" although you are ready for new tasks?
💡 Rule of thumb: Nimbus will distribute calls only when all criteria are met:
- Valid MS Teams Presence
- Not blocked by tasks or calls
- Not at maximum capacity
- In an On Duty Profile
- Not status-flagged by ACW or RONA
Pickup behavior
INC Pickup behavior
🔎Pickup behavior
If your administrator configures the Pickup Distribution Type in the service Workflow (within the Queue / Queue Task activity), you can instead pick up tasks from the queue yourself, deciding when to take on additional work.
| Modality | Audio / Video Calls | External Task / Email / Instant Messaging |
|---|---|---|
| Pickup behavior | Pickup & Accept in two steps: selecting Pickup signals the Nimbus bot to invite you to a Conference call. You can choose to Accept or receive RONA on timeout. | Pickup & Accept in one step: selecting Pickup assigns the task to you immediately — there is no separate Accept action and no RONA timeout. |
| Where | The Pickup button appears wherever the task is listed — My Overview, Services List, Live View and Attendant Console. | |
| Condition1 |
1🔎Also see User States for more details on the conditions how Nimbus considers users as selectable for tasks. |
|
| Picking up while connected | Pressing Pickup while already connected to a non-blocking task automatically parks that connected task, letting you switch straight to the picked-up one. Existing Pickup eligibility rules (skills, responsibility, Distribution Type) and task limits still apply — Pickup remains unavailable once your capacity is used up. → See "Parallel Task Handling" and "Park Task Automatically When Picking Up a Pickup Task" on the Task Parallelization page. | |
| Conflicts |
If several users pick up the same task at once, the first request to reach Nimbus wins. ⮑ A small banner will inform else if the task was already taken. |
|
| Adaptive Cards | Adaptive Cards option supported in MS teams-based services. | No Adaptive Card option supported for this these modalities. |
| Reporting | After clicking “Pickup" the user gets the call invitation. The User Session reports the Ring Time and includes it in the Average Ring Time KPIs. |
Because the task is accepted instantly, it has no ring time — these sessions report a Ring Time of 0 and are excluded from Average Ring Time KPIs. |